The Iron Triangle

I’m sure that you’ve heard a version of the phrase “fast, good, or cheap. Pick two.” In terms of getting a piece of work done, mostly by an external paid contractor, it holds true. If you want something good and fast, it’ll be expensive. If you want something good and cheap, it’ll be slow. If you want something fast and cheap, it’ll be poor quality. This is applicable from dry cleaning to engineering. These are the levers you can pull.

In the world of knowledge work, this is often called the Project Management Triangle, the Iron Triangle and the Triple Constraint. Typically when using this model the “cheap” part refers to the amount of cash being spent; i.e. the choice between a renowned agency to complete the work (expensive, predictable) versus an unknown independent party (cheap, unpredictable). Similarly, it could represent the decision as whether to offshore work to a country with lower labour rates (cheap, unpredictable*) or use specialist contractors from, say, the Bay Area (expensive, presumably predictable). I’m sure you can think of other examples too.

Work on the horizon

How does the Iron Triangle relate to projects that you are running with your own teams?

We’ll be limiting the scope of this article to delivering software that you are developing in-house. You will have a finite number of engineers at any given time, and you will routinely find yourself juggling your ongoing projects with the need to forge ahead with the next great thing that you should be building.

As touched upon in a previous post, you will be wanting to make sure that your current projects are delivering as fast as you can and that you are being transparent about their progress. But for new projects that are in the planning stages, how should you be justifying your decisions to other parts of the business to ensure that the next thing is going to come out as expected with the least number of surprises?

Everything, all of the time

When discussing upcoming projects, you may face conflicting opinions from different departments, including your own. These particular examples are taken to an extreme, and in reality people are more pragmatic, but for the sake of discussion we present the following:

• Commercial want it now! Your salespeople are finding it difficult to pitch against your competitors because of features that are lacking in your application. This next feature can’t come soon enough, because their confidence in you is paramount to their success.
• Product want it all! Your product manager has a grand vision for the roadmap for the next year. The designs look beautiful and the offering compelling, but you can see that it represents a huge amount of work. Probably too much work.
• Engineering want it right! Your engineers see this new roadmap as the key trigger to redesign a large part of the system. Building it around what already exists will introduce a lot of technical debt that will cause serious pain in the future.

Three different opinions that are all equally valid. A healthy tension exists between them: where do you begin the discussion?

Your levers

Now it goes without saying that you would not want to compromise on quality. I would argue that if you are happy with shipping poor quality software, then you are probably in the wrong job.

Instead, you have three levers that you can adjust in order to find the right compromise with new projects. They are scope, resources, and time. Sometimes you have flexibility over all of them, and sometimes you won’t.

1. Scope: The definition of what the project is going to deliver.
2. Resources: The number of engineers that you are going to assign.
3. Time: The duration that you have to work on it.

Imagine that you are beginning to explore a new project. How do you frame it amongst everything else that is going on?

Scope

Let’s dig into scope. Your engagement point is to have your team work with your product owner to break the product or feature into epics and stories that each deliver tangible added value to your application. This is your project backlog. Then, from there, work together to prioritize it.

With your prioritized backlog created you can probe more:

• Launch methodology: Is there going to be a marketing launch for this feature? If so, where in the backlog would the project need to get to for that to occur? Or is it all going to roll out with no fanfare at all?
• Shipping frequency: Is it shippable to users as each individual chunk of functionality is finished? If not, can it be shipped to production behind a feature toggle instead? Who makes the call on when users should see the new functionality?
• Criticality of scope: Do we absolutely need every single piece of functionality to be done in the project to consider it a success? Can any of it be considered suitable for stretch goals and/or incremental releases after launch?

Deciding these up-front can save a lot of future stress and panic by giving you buffers to work with.

Talking to marketing right at the beginning of a project can help them prepare way ahead of time, and show you how they’re getting along as they progress. It’s exciting to see a launch develop! Being able to ship frequently, even if it’s hidden behind feature toggles, can prevent high-risk big-bang changes and allows you to decouple the release date of the software from the date that it ships to production. You are given more flexibility to test on real data and real load. Knowing which parts of the scope can be dropped in case of delays and technical issues gives a safety net for when things go awry.

A little extra thought up front can make projects run much more smoothly.

Resources

What size of team are going to be required to get this work done? It can be tempting to throw the proverbial kitchen sink at an important new project, but there are a number of considerations:

• Parallelism: How much of the work in the scope is sequential and how much can be done in parallel? Two separate services can be developed independently, but iterations of the same service or component cannot.
• Code vicinity: The last thing you want is multiple engineers all working on top of each other in the same part of the code, causing nasty merge conflicts with their commits. You don’t need four spanners scrabbling over the same nut.
• Technical difficulty: Is this looking like a business-as-usual increment of functionality in your existing application, or is this a new innovative piece of architecture? This drives decisions about which of your staff might be required to work on it, or at least offer their time to oversee it.
• Relative importance to other projects: Is this new feature the number one business priority and therefore it needs to ship yesterday, or can it arrive more calmly with a smaller team, as there are other projects providing steady cadence to your overall delivery?

Everything is always a trade-off.

Time

You cannot bend time. However, how much control do you have over the timing of the delivery?

• Be clear about priority: Each project cannot be considered to have equally immediate urgency, as the reality is a more subtle balance of many concurrently active initiatives for different people with differing priorities.
• Identify projects that could slip: Is it the case that you have an immovable date such as an unveiling at an event or a client-imposed deadline where money is on the line? Allowing flexibility with timing of other projects allows you to be more inflexible with the critical ones when necessary. If your inflexible projects become unstuck, then resources for your flexible ones give a buffer to regroup staff to address problems. Try to identify which projects are flexible and which aren’t.

You can’t create more time, but you can use it wisely in decisions. Knowing which projects can slip if necessary and those which can’t can contribute to making sensible and pragmatic judgement calls.

Making your levers transparent

If you have a considered approach to your new and ongoing projects using the levers of scope, resources and time, then you can make clear choices that are easy to explain when questioned about your priorities. Making your decisions and their reasoning visible internally to your department can also help teams see how their projects fit into the bigger picture.

The trade-offs of scope, resources and time guide debate around pragmatic concepts that you can discuss openly and honestly, shifting the conversation towards how further trade-offs can be made when under pressure, rather than inviting ungrounded criticism about how hard you and your teams should be working instead.

Visibility of these trade-offs also empowers your teams to help each other too: one team may offer to lend some resource because they know another team’s project is critical and immovable, and their own more flexible.

How many projects are you running that have been considered fully as part of the whole?

*Not always unpredictable depending if you have good contacts with offshoring partners. However, the cost of offshore development is being driven up by demand from areas with the highest average salaries to begin with, such as the Bay Area and NYC. If you are hunting for a good offshoring partner from a company with less extreme salaries, you may be surprised at the comparative cost.