Iron triangle project management – and the 2024 Autumn Budget

The UK government’s 2024 Autumn Budget got me thinking about the ‘iron triangle’ project management rule, i.e. a compromise between:

• Cost/resources (money, people, equipment)
• Time (releases, milestones)
• Scope (functionality)

(But before I continue, I must point out I’m not trying to make any political points and am happy to leave that type of commentary to others.)

Iron triangle project management

The key point about the iron triangle rule is that, at most, only two of these objectives can be fixed. At least one will have to vary to allow for the inevitable uncertainty present in a project (whether that uncertainty is accepted or not). Equally, while in theory you could change any of these, in practice only two could have unlimited values because resources are usually fixed or at least finite.

In IT, the approach can be an introductory lesson for suppliers in how to talk to their customers. At its most virtuous, this can be seen as a way to ensure projects succeed, and so could be a good test for government projects.

But while the lesson is certainly based on hard-won experience of customers expecting too much – and too quickly – from too few resources, the success it predicts is very much from the perspective of the supplier rather than the customer.

Too often it can be a slightly cynical way for a supplier to ensure an engagement with a customer can be described as successful, while limiting their own risks.

And while suppliers may face uncertainty in implementing a project, it’s also true that customers’ budgets have finite limits. Their requirements tend to be based on necessities, and their timescales aren’t entirely flexible.

So, related to government, does this method envisage taxpayers being lulled into accepting lower service levels for their taxes? Or is it just a reminder they should be more realistic about what’s possible?

That said, I was also conscious of our company’s engagement in research and development. At Quantiv, we’re always working to develop our services. But, of course, there’s a risk with any R&D that it won’t bring in the results we seek.

Research and development – and why it matters

To their credit, successive UK governments have encouraged research and development activities through targeted tax reliefs.

Interestingly, the qualification criteria set for these reliefs takes a slightly different view of the criteria around IT (and indeed other) projects. In short, to qualify for the tax relief, a project must seek an ‘advance’ in a field of science or technology. Or, to put it another way, to change or adapt the characteristics of something to the point where it’s ‘better’ than the original.

The improvements may include:

• Creating a process, material, device, product or service that increases overall knowledge or capability in a field of science or technology
• Appreciably improving an existing process, material, device, product or service, for example to save costs or reduce waste
• Using science or technology to copy the effect of a current process, material, device, product or service in a new or improved way

I view the above as much more ambitious, or even idealistic, criteria – and it’s certainly how I’d prefer the Government to be thinking.

Inspired by the above, we use an ‘improved’ iron triangle rule in our own R&D at Quantiv, so we aim to keep two of the criteria fixed, while improving the third.

Time, resources, and quality

But how do you know if you’ve improved the quality of something?

It’s usually easy to know whether more time or resources have been used.

But increased scope – better quality – is often much more difficult to quantify. Without metrics to show how an existing system or process was already performing, it can be difficult to know whether changes made by a project have resulted in improvements.

In turn, just being able to identify those metrics depends on a good understanding of the processing being performed.

Neither can be taken for granted.

Textual descriptions are useful in providing an overview of any new or changed processing to be implemented by a project, but they’re rarely enough to quantify its effects. Instead, more formal measurements are needed. Key performance indicators (KPIs) can be a start but often these are too high level to show where real improvements have or haven’t been made.

And without an understanding of the overall processes performed, it’s hard to know whether the metrics identified cover all steps in the process. Knowing that 90% of a process is working well doesn’t provide reassurance if the other 10% is invisible and might be going seriously wrong.

Getting process analysis right

Being able to analyse your processes – and your whole organisation – from the perspective of the activities performed can help provide that reassurance. It can also form a basis for scrutinising the benefits of future changes. In particular, the detail can be provided by understanding the inputs required by the activities within the process, and from those the outputs that should result.

Quantiv’s NumberWorks method is inspired by this approach, using a simple pattern of analysis based on:

• What’s done
• What’s used
• What’s produced

Working in this way means your processes are described not just in terms of the ‘state’ that results from the processing, but rather in terms of the steps that led to that state. So, instead of just knowing the values of your metrics at a point in time, it’s possible to explain how those values came about.

Why use NumberWorks?

Our approach allows your organisational processes to be classified, qualified and most importantly quantified, and therefore show how they’ve improved over time.

And if applied in a project context, the method can be used to judge whether changes have managed to break out of the iron triangle.

To find out more, talk to our team on 0161 927 4000 or email: info@quantiv.com