Breaking the Law of Triple Constraints

In classical project management methodology, there is a concept called the Law of Triple Constraints:




The law states that as two of the constraints are changed, there must be an equal change on the third constraint while still maintaining the same level of quality.

For example, if scope is increased and schedule decreased, this MUST have an impact on the number of resources required. If resources are decreased, this MUST have an impact on either scope decreasing or schedule increasing.

However, in practice, this law is not really a law at all, or rather it is based on idealistic assumptions.

These assumptions are as follows:

1. The process for running the project has been 100% optimized.

2. The process for running the project is 100% known and not subject to any possible innovation to improve the picture.

3. Talent on the project is not changeable or all talent is the same.

4. The amount of management is precisely what is required to manage the project.


The reality is that in most projects these assumptions are simply not true. In addition, this model promotes a mechanistic, deterministic approach to managing projects that lacks an hope for innovation, efficiency or reduction in management.

Here are ways you as a stakeholder or project manager can "break" the Law of Triple Constraints without sacrificing quality:

1. Re-examine your estimates and make sure they are not overly padded. Some contingency is always required in order to handle unexpected events. However, on a $1 million project, the difference between 10% contingency and 30% contingency is $200K - is it really necessary?

2. Challenge the team to be innovative about process, documentation, testing, builds, etc. There are better ways to doing any project - no team is 100% optimized. I've seen simple changes such as using automated unit testing that makes massive differences in effort and actually improves quality. Depending on the type of project, there is innovation to be had.

3. Do you really need to build something or can it be bought?

4. Be ruthless about gold-plating on all sides. Developers, stakeholders, creative directors, etc. all like to add changes, rounds of revisions, additional documents, new features, etc. and that extra 10-20% makes a difference over the course of a large project.

5. Improve communication and lower documentation overhead. For every 300 page use case document you have to write, edit, review and then update make sure they are necessary artifacts and they have value. I was on a project once where the wire frame document cost $100K to produce!

6. Make sure you have the right talent for the job. For hard problems, you may think that having your junior flash developer be your technical architect will save you some money but in my experience the opposite is true - get the best talent you can possibly afford because they pay for themselves in much higher value than the additional cost in salary. For easy jobs, don't take your technical architect and make him your excel macro monkey - it will frustrate him/her and is a waste of their talent.

7. Get Creative! On every project, there are ways to innovate. It may be in the implementation of a particular module. It may be that you re-examine the problem you're solving and come up with something more elegant than when you originally built your plan.

8. Make your team entrepreneurial. Encourage open communication, risk taking, fast decision making, and low document overhead. Have the right level of process and no more than necessary. Give everyone ownership in the project and let them understand the big picture.

9. A simple tip: make sure your team members know deadlines! It sounds really dumb, but I have noticed a big difference in teams where they can see the entire plan and understand the context of deadlines than if a person is just handed a task piecemeal and told to complete it blind.

I've seen project plans that are bloated and I have seen some that are way too lean. Starting with bloat and cutting down I find is easier to manage than starting lean and trying to increase to handle the bare minimum requirements. Start with a robust, conservative and full process plan and then take a good look at it and see if there are some trimmings to be had.

One final note - this is not a panacea and in my experience, you can achieve a savings of somewhere between 0-20%. Don't expect that you can cut your project timeline in half. However, on a $1 million dollar project that's still $100-200K and on a 6 month timeline that's still a month of time saved.

As a project manager, you can choose what you do in terms of managing stakeholders' expectations. Typically, I use a conservative estimate to start and then I try to get innovative once I'm executing. If the risks of being creative and entrepreneurial pay off, then I look like a rock star with a project ahead of schedule, a happy team and satisfied customers.

But if you are a project manager who simply adheres to a conservative approach and obeys the Law of Triple Constraints like dogma, then you will be missing opportunities to innovate!