If you’re at all familiar with Project Management, be it in an IT context or otherwise, or have the great fortune to have a Project Manager in your family or circle of friends, you may have heard of the ‘Triple Constraint’. Sometimes also referred to as the ‘Iron Triangle’ of Project Management, the Triple Constraint has been the de facto framework to illustrate the tradeoffs faced by Project Managers since the dawn of time.
With ‘scope’, ‘time’ and ‘cost’ as the 3 ‘constraints’, (with ‘quality’ often shown in the middle), the triangle metaphor is used to illustrate that a change on any one of these items will invariably result in an impact on one or more of the others. A couple of examples might include:
- Adding a new feature or additional complexity to an existing feature (an addition to ‘scope’) will result in additional time and/or costs.
- Delivering to an accelerated schedule (a change in ‘time’), you may need to add additional resources which will drive additional ‘costs’ (or require you to figure out areas of ‘scope’ that can be cut).
- And on and on it goes.
While the traditional triple constraint/iron triangle provides the basic, ‘Project Management 101’ framework for managing projects, it of course doesn’t tell the whole story. What about risks and issues? What about client and stakeholder expectations? What about resource management and communications? And more…
Further to this – and thinking more broadly – what about things like ‘time to market’ of the product or service you are developing, or ‘adoption rate’ of the product or service. Do these things matter? Ultimately, the question is – in today’s environment, does delivering a project ‘on time’, ‘on schedule’, ‘on scope’, with an acceptable level of ‘quality’, make it a successful project?
As you might expect, there is some level of debate and discussion around this in the Project Management community. As such, the traditional Iron Triangle has given way to a number of derivatives of the original to try and incorporate some of the above noted shortcomings. Some of the many ‘shapes’ out there include hexagons, stars, parallelograms (the ‘Iron Parallelogram’ doesn’t roll off the tongue quite as easily as triangle) and more, but the one that seems to have gained the most traction is the ‘Project Management Diamond’ where ‘quality’ has been upgraded to an equal to the others and ‘expectations’ now sits in the middle.
While the intention isn’t that the particular ‘shape’ capture every single thing that a Project Manager needs to balance (as that would certainly be an ugly shape), there are still a few factors that I would propose might be worthy of inclusion from my perspective.
Keeping with the triangle shape, I might propose an inverted triangle that overlays the original triangle, to augment what’s already in place in order to add some ‘real-life’ factors that tend to also factor into projects, since as most Project Managers would probably agree, if all they had to manage were ‘scope’, ‘time’ and ‘cost’ – what a wonderful world it would be!
Before proceeding further I should note that the facets of this model are not ‘constraints’ on their own (in case that much wasn’t obvious), but rather, important and interrelated elements in project engagements; the constraint lies in the challenge Project Managers and teams have in managing all of the trade-offs, considering all of the interrelations at play.
When it comes to delivering ‘successful’ projects, there are a number of client factors that tend to not get reflected in the models and metaphors that we see in Project Management literature. A few of these things include – how well a client understands their own business process, in order to be able to articulate them to your team during the requirements phases, or how well resourced the client team is in order to meet deadlines that are dependencies for the success of your project (i.e. securing environments, performing user acceptance testing etc.).
Other important client factors include a client’s understanding and adherence to processes (that should be) outlined in project SOWs and charters that relate to scope and change management, as well as how well they plan and execute internal change management activities to ensure organizational and user buy-in and adoption.
Similar to the client factors noted above, there many team factors that are not often spelled out in detail in the PMBOK and other Project Management resources. A few such examples include – whether or not the team put forth to deliver the project has the necessary skillsets and experience on the platforms and technologies being used, or whether the team members have been allocated at a high enough percentage to actually deliver to the agreed upon schedule.
Another important team factor (quite arguably the most important factor) relates to the individuals that make up the team and what makes each of them tick. What tools and technologies do they prefer to work on? How do they like to work? Are they an introvert or an extravert? Are they motivated more by intrinsic or extrinsic factors? And how much control do Project Managers have over being able to provide the conditions to optimize the team’s performance and experience on the project?
When it comes to processes, how much is enough? How much is too much? What is the best way to ensure team members have autonomy over their work, while also providing them with a sufficient amount of support and resources to succeed?
Also, how best to balance the need to shelter the team from distractions so they can focus on their deliverables, with ensuring that they have had sufficient inputs into plans that they will be held accountable to, and with ensuring the Project Manager is armed with the inputs he or she needs to represent the team for status reporting and communications?
Other things to consider in the realm of process might be: how well does your process adapt to different project types, different technologies, cross-business unit engagements and remote/distributed team scenarios? There are no answers that will be right all of the time in all situations (but chime in if you have them and would like to share), but figuring out the right processes and right amount of rigor will always be a factor in your ability to deliver.
I’ll close with a quote from Alistair Cockburn – one of the founders of the Agile movement – related to process. ‘Process is indeed important. While a good process can’t assure delivery, and a good team can deliver despite an unwieldy process, a poor process can get in the way quite neatly’.