Breaking the Project
Management Triangle

If you've been in technology long enough, you're probably familiar with the project management triangle. There are a few variants but it generally stipulates that a project cannot fix resources, scope, and quality. At best, you can maintain only two of the three. This is often used to justify a product-oriented approach to development. This allows a team to focus on maintaining productivity and quality at the same time. It's sound advice that I also give as much as I can. But it doesn't always work…

Projects vs Products

Products have the potential to scale (or drive growth) which means they can be financially fruitful. In turn, this allows a team to maintain focus and iterate long enough to do great quality work. Additionally, it’s not much fun to engage in protracted planning sessions which are often necessary for projects. But some types of work don’t naturally fit into a product mold. In those cases, projects may provide better structure. Here are a few motivating examples:

1. Platform or hardware migrations
2. System-wide refactoring, rebuilds, or redesigns
3. Innovation initiatives (ie. testing new technologies on familiar problems)

Or more generally, anything that involves a high cost of change might be better as a project. This happens when you have logistical constraints, organizational change initiatives, new policy adoption, joint ventures, and so on. Projects provide a better structure in these scenarios for the following reasons:

1. There is a desirable end state that can be defined up front
2. Business deals, contracts, and other business plans may be conditioned on the successful execution of the work done in the project
3. A return on investment can be calculated to justify a (high) cost for the endeavor

NOTE: It’s worth calling attention to situations in which projects are unlikely to be delivered reliably. If your team doesn’t have experience in the problem domain and/or you must depend upon independent 3rd parties then those issues need to be resolved first. Consider hiring domain expertise and changing the nature of the 3rd party relationships before starting a project.

Managing Agile Projects

The purpose of management is to produce a predictable outcomes. It is a financial control that allows executives to operate with transparency and confidence in their own operations. From an executives perspective, an ideal project looks like this:

This is the central point of contention. About sixty years of empirical evidence suggests that this doesn’t work, because…

Sadly, it’s 2018 and I still meet people who don’t know this. Usually they don’t have a background in software development but some still work at tech companies. As the graph above illustrates, the traditional approach to managing projects is distinctly non-agile.

Yet this approach is pretty logical when the project involves low complexity, low uncertainty, and very well defined business processes. But in the world of technology, very few of the above conditions are met which is why technology projects can be so painful. I’ve seen projects derailed because of mergers, international politics, and natural disasters. Some factors simply cannot be accounted for in advance.

To make matters worse, many of the traditional IT project management approaches do not account for modern development contexts. More specifically, they do not capture the dynamic relationships between team member activities that occur throughout a project.

I have extensive experience working with iterative teams on projects. What I’ve found is that agile management tools (JIRA, Pivotal Tracker, Trello, etc) are good at capturing scope and structuring it as a Kanban board or in Scrum sprints. Project management tools (Monday, Basecamp, Wrike, etc) are good at tracking deadlines, dependencies, and budgets. But neither of these alone provide a good framework for agile project management and combining them together is non-trivial.

Furthermore, most solutions implicitly produce an availability bias for managers. There is a great wealth of intelligence trapped in the hearts and minds of team members regarding their progress and hidden risk factors. If that intelligence isn’t captured explicitly, then it often goes ignored. I’ll describe how to extract that intelligence from the team in this post.

Let’s get started!

Develop a Project Mission

Define why the project is necessary and what kind of opportunity it represents. If the project is important, then make sure the mission statement clearly communicates it. Without a mission statement defined up front, the project can easily fall into a cycle of mission creep. Once you have a mission statement, you can use it to find the people who want to accomplish the mission with you.

Build a Great Team

It probably goes without saying, but by far the most important thing to get right is the people. Sadly, it’s also probably the hardest. But even if you have great people, they don’t automatically become a great team when they start working together. That’s because great teams consist of great teamwork which does not spontaneously happen. If the teamwork stinks, fix that before you do anything else. I will write about how I go about creating teams in a future post. Until then, keep this in mind:

Representing Stakeholders

The project stakeholders should at least represent the customers (and users if they’re not customers), the business sponsors, and the team members. It may also include other representatives but only to a limited extent. All external stakeholders who do not have direct authority over the project must interface with a project manager, product owner, or scrum master in order to have their interests represented in the project. If needed, a responsibility assignment chart may be created to organize a project with many stakeholders. As we shall see later in this post, it’s useful to identify project stakeholders early in order to determine who will evaluate project quality.

Develop a Project Scope

The people who have the best information on how to execute a project are the people who will actually do it. As such, the project team must work together to define the scope required to accomplish the mission. The scope can be defined in any way you choose. But it’s often useful to draft a scope in terms of the workstreams (or activities), artifacts, and tasks that the team will work on during the project. The level of fidelity will vary depending upon the team, the objectives, and the project size.

This exercise may also require a significant amount of learning and information gathering depending on the complexity of the project. Keep in mind that an agile project scope may change during the project as the team learns new information or faces shifting priorities. Don’t fret if the scope definition isn’t perfect, shoot for 80% accuracy.

• Workstreams: also known as activities. These could be broken down by discipline (DevOps, Design, etc) or by functional module. For small projects, the workstreams might be the same as the artifacts.
• Artifacts: also known as deliverables. These may be programs, wireframes, style guides, or API endpoints. This merely reflects a “chunking” of the work so that it can be monitored at a high level.
• Tasks: any plain language description of things that must be done to finish the project. These could be user stories or even user journeys depending upon the desired level of fidelity.

Without a project scope defined in advance of the project, it will likely suffer from scope creep. As I’ll demonstrate later in this post, it’s possible to absorb changes as the team gains new information but these changes can be handled in a controlled fashion that will be carefully considered in tandem with the remaining time and budget.

Develop a Project Plan

The project plan includes the resources, deadlines (or milestones), and dependencies for the project. The team should not only identify how long they think each artifact will take, they should also identify all 3rd party dependencies and when those must be satisfied.

Resource estimates turn into target budgets for each workstream. So, all estimates for workstreams need to be risk-adjusted. Estimating and identifying risks requires experience and practice. Ideally, estimates could be produced based upon how long similar tasks have taken in the past. If the team has never done the activities within the scope before (which is common), then I recommend that the estimates incorporate some or all of the following:

1. An error margin multiplier for each unfamiliar activity
2. An added budget for learning how to do unfamiliar activities
3. An added buffer of time for unforeseen challenges

Don’t worry if the plan might be wrong. You’ll update the plan as you execute the project and iteratively gain new information and face changes. It’s also critical to recognize that all deadlines outlined in the plan are estimated projections and not quotes In the agile project reporting section, I’ll describe how missed deadlines and budget overages should be handled.

So far, what I’ve described sounds kinda like a regular project. What makes it an agile project? It’s agile because the team will execute it iteratively. As my personal rule of thumb, the budget and timeline should allow the team to carry out the project at least a few times over, assuming they maintain peak productivity.

Execute the Project, Several Times

If the project timeline is 8 months, attempt to complete the full scope in 2 months. The first pass is the prototype version. You’ll probably throw it out. The objective of the prototype is to uncover the unknowns and unknown unknowns. In the process, the team will likely sharpen their tactical skills. With each subsequent iteration, the scope fidelity and quality should increase. My motto is, “Make it fast, then make it great.”

Define a Project Process Model

A process model is simply a description of how an article of work gets accomplished. It’s normally treated as a boxes and arrows diagram, but a list of workstreams with inputs and outputs might suffice. If the team can understand it’s own process, then it can optimize it!

As part of each sprint retrospective, review the process model in order to search for improvements, bubbles, or bottlenecks. Optimizing team workflow only works if the project team has total internal control of the entire process, from end-to-end. If there are external 3rd parties that become choke points in this process they should be removed from the project or they should become internal team members.

In my experience, there is often a dynamic relationship between what output team members expect from each other and how much time is required from one another. I will touch on this in greater detail in a future post. But for now, what about those sprints?

Use Scrum

All progress should be organized in iterative sprints (ie. Scrum). It’s possible that Kanban approach could also be used for agile projects but in my experience, it doesn’t work as well. The key reason is that you must make iterative commitments and have regularly reviewed milestones that can also track against the project objectives. If scrum is unfamiliar to you, I would recommend reading the SCRUM resources from Atlassian before you start engaging in agile projects.

Report on Project Progress

Once per sprint (or at least once a month), update the following project reporting to track the team’s progress against the project scope. Then review the reporting with the team and the project sponsors. The purpose of this review is to spread awareness and decision-making context to the entire team to enable the most effective issue resolution.

Track Progress Against the Project Scope

Track the project artifacts, scope, and dependencies. All of the internal project structure is established in order to create visibility for the team and for decision makers. By reviewing the scope with the team on a regular basis, you avoid having things slip through the cracks. By reviewing with the decision makers, avoid having to deal with inaccurate perceptions.

Where possible, use tests to evaluate progress. Where tests are infeasible, solicit gut check estimates from the team on the level of completeness for each artifact and activity in the scope. Gut check estimates probably sounds like noisy information and that’s true. However, in my experience it’s better than no information and it does help capture previously undocumented issues that may be brewing behind the scenes. This can be a powerful tool for avoiding preventable problems!

Review Budget and Timeline

Track the project budget and project timeline for each element of scope. Regular review of milestones and budgets is central to keeping a project on track.

NOTE: Not all internal project deadlines will be met. And not all internal project budgets will be met. This continuous review cycle serves an early warning signal to help managers determine when and how to adjust the project parameters to deal with issues and risks. When deadlines or budgets are missed, you can capture the potential impact by creating a new issue or risk in the RAID Log.

Review and Maintain a RAID Log

RAID is an acronym for Risks, Accomplishments, Issues, and Decisions. To some extent, all software development is a chaotic adventure. As you reduce the size of the cone of uncertainty, you will find that assumptions are violated, deadlines are missed, or new constraints are uncovered. As these events occur, something must be done to account for their impact to the project. The RAID log serves as the primary tool to avoid scope creep and to impose change control.

The key idea is that when a risk or an issue is identified, it is captured in a project log where it becomes a to-do list item for the team to resolve. This should happen anytime someone suspects that a milestone deadline might be missed, a budget may be exceeded, or any other event that may impact the project outcomes.

Accomplishments related to the project scope are logged as they are achieved. This removes the need to revisit finished work and demonstrates value delivery. Finally, any decisions that are made (to address new risks, accommodate change requests, etc) are also logged to provide traceability and accountability.

Systematic Review of Quality

Any project output will have a level of quality that is perceived by the project stakeholders (the users, customers, and the team). Though there are techniques to quantify quality in order to manage it explicitly, I’ve always found them to be a little cumbersome. Instead I recommend controlling quality through the systematic review by the stakeholders. This can be done by evaluating the quality of individual contributions, evaluating the quality of the entire process, or both.

Cross Cutting Concerns

One of the most nebulous aspects of agile project management is mapping agile development tasks (user stories, requirements, tickets) to project management line items (workstreams, deliverables, budgets). This is challenging because there is usually a many-to-many relationship between tasks in an agile development tracking tool (like JIRA) and project management tool (like Basecamp).

To this day, I have not found a tool or solution that solves this problem well. In my opinion, the reason is because they are two very different ways of looking at the same work that do not naturally mesh together. This is why agile project management may need to exist as a separate process or using separate tools from product ownership or scrum master-ing. Correspondences can be made on a case-by-case basis as long as it serves a purpose.

A Dashboard for the Iron Triangle

Technically, this system does not “break” the project management triangle but instead, I suppose, it escapes it. Using this system, there is no need to rigidly define a fixed scope, budget, and quality level. By establishing visibility and traceability for the development process, all of the project stakeholders get a common view of what progress has been made, how much more work has to be done, and how much budget is left to complete the project. Accordingly, managers can dynamically control resources, scope, and quality by frequently revising the project plan based upon real-world conditions.

Maintaining Quality

Having just indicated that quality can be dynamically adjusted, I can imagine my former colleagues shouting, “High quality is a constraint!” But if you ask ten different people to define what high quality means, you will likely get ten different answers. IMHO, there is no absolute definition — only a relative one. Furthermore, any definition that is sufficiently specific will also become a value judgement. Values differ between people, teams, and companies.

It is also critical to recognize that quality is a complex, multi-faceted issue. For instance, high quality in one discipline (say, DevOps) may impose constraints on another discipline (Engineering). From the perspective of the business, the optimal level of quality is the one that is sufficient for the business to succeed. Unfortunately, even defining what “sufficient quality” means is tough. But that topic will be the subject of my next post.

Stay tuned!