Beyond the Triple Constraint

I comment this week about the extra elements which complement the Triple Constraint: Risk, Quality, and Resources. One of the reasons while it is often said that the Triple Constraint is not really triple. 

-o- 

In my last post I commented about the Triple Constraint of Scope, Time and Cost, which is one of the basic building blocks of Project Management: how to align and make sound decisions around (highly) competing demands. Whereas there is general consensus that other critical factors also compete against these three; there is not always agreement on which ones are those elements. This week I will elaborate around some of them: Risk, Quality and Resources. Some authors like Rita Mulcahy use for example Customer Satisfaction instead of Resources. Others may use other factors.

Risk – from the Arabic term “rizq” which means “what the providence brings”, risk management is one of the most challenging demands in a project, always impacting at least one or more of the other components of the triple constraint. Whereas most of the time it is associated with events that can make the things go wrong, it can also refer to events that can make things go well. In summary is like having your radar on at all times, trying to catch as early as possible what could go wrong and try to make something about it; and  also catch what could make things go well, and try to make that happen. It often requires a pragmatic mindset depending on the context of the project. 

Quality – another concept which is not very easily achieved, it deals with how well specific requirements, standards, parameters or guidelines are met. In the most desirable scenario, quality is preferred to be built in, than to be inspected in. In plain terms it tells that if you are doing something, it is worth it to do it right from the beginning; instead of waiting until the end to check how good is it, and find that you need to fix lots of things or do it all over again. It requires clarity, discipline, but also a realistic approach. 

Resources – this is what you have available to complete the project (people and resources). Depending on these elements the other components of the Constraint will be likely impacted. It is not the same to tackle a project with a junior team than with a team of seasoned colleagues. The availability of specific resources or their characteristics would likely affect the outcomes of your project. 

At the end of the day the Triple Constraint is a conceptual model to help us understand the nature of the project, its purpose and the several elements that need to be aligned, balanced and prioritized to get it right. 

No matter the specific framework that you choose to approach your work, it should be systematic, consistent, and disciplined; otherwise you may find yourself lost instead of finding yourself managing the project.

Have a rewarding week!
- Sergio Calvo

The Triple Constraint

I leave you today with one of the core concepts in Project Management. The triple constraint of Scope, Time and Cost. They are at the core of the discipline and anyone interested in achieving success in a project should stay tuned with the basics of their relationship. 

-o- 

You can’t have everything you want all the time. This is as true in Project Management as it is in life itself. The more you deny it, the more you are likely to suffer it. It is perfectly fine to try to get as much as you can with whatever you have. But it is also wise to assess when you can’t push it any further to avoid jeopardizing the  goals of the project you pursue. 

That’s what the triple constraint reminds us. 

There is the scope - the product, result, or service that you want to achieve. Everything that you want to get done; and not less important, what you don’t want to get done. 

There is the time - how much time do you have to get the product, result, or service that you want. 

There is the cost - how much it is going to cost you get the product, result, or service that you want by the time that you want it. 

These three are constrained with one another. The more you want to get done is almost certainly to increase your cost and likely to demand more time. The less time you have to get the things done is likely to increase your cost for it or would demand to decrease eventually what you want done. An increase in your costs for whatever reason is likely to force you to reduce what you want done or the time to do it or both. 

That’s just how they work. Your role as a leader is to be aware of that inherent relationship, to monitor and properly document how a change in one of them impacts the others, to stay grounded to the earth about them and to use your skills and those of your Project Team to get done as much as you can, for the best possible cost and in as less time as suitable. 

That’s easier said than done. 

In fact you may choose to look the other way instead of doing it. However reality is going to come back at you the hard way. You may end up working for free. You may fall short on your commitments with your customer. Your customer may end up paying more than expected or getting less than expected. Your project would be at risk and eventually your reputation would suffer.  

All the frameworks and the theory in Project Management are developed to help those involved in the discipline to manage these three things as effectively as possible. 

The following questions may come handy when you are dealing with these three:

- When is the final deadline for the project?

- Have you broken the product, service or result pursued down to its more basic packages?

- Have all the involved costs being calculated? Could there be any hidden costs so far?

- Are we going to work holidays, weekends, extra hours? How would that affect cost?

- What does the contract say about scope, time and costs?

- Are there any penalties for being late, for leaving a feature behind, for additional fees?

- Is any of the elements more tightly restricted than the others? 

- How this change in one of them would impact the other two?

There are other factors pretty closely related: quality, resources and risk. This is why some people say that the triple constraint is not really triple. We shall come with these ones at a later time. 

Have a nice week! 

- Sergio Calvo

Pragmatic Risk Management

Risk is one of those things that we really don’t like but that we have no choice but to live with. In Joe Black’s words it is as certain as death and taxes. This level of certainty when you are at the program level should mean that teams are very good at dealing with it. However it is often not the case. Some teams take an extreme approach when managing risks. Either they do nothing to manage them, considering any issue as an unpredictable event, putting the endeavor and potentially the organization in an irremediable path for failure; or they attempt to develop true rocket science before they step up to manage them, causing an overhead which rests the speed and agility required for successful program outcomes. 

From my perspective, effective teams develop a pragmatic balance among those extremes. They keep in mind that the ultimate goal behind Risk Management is no other but to determine what may play against the project, so they can prevent it or at least decrease its impact; and at the same time determine what could play in its favor and try to make that happen.  A few principles can help the team to develop that pragmatic, balanced approach  for  dealing effectively with risks. 

Making it Visible – this is probably the most important principle that lies behind managing risk. It is all about visibility. It is all about making visible something that could go wrong. If it is not visible for the team, then no one will be able to do anything about it. 

Managing the Log – Team needs a single consolidated log of risks for the program or the project; it is the responsibility of the program/project manager to provide it, and to facilitate its management to the team members. The log should allow all team members to track the basics about a risk, as well as the response actions taken to solve it through time. A common practice is to develop a more holistic list called the D.A.I.R. log, which records not only risks but decisions, actions, and issues. Sometimes the differences among those are clear, sometimes they are blurry. What’s most important is to describe the situation in specific terms so the proper responses can be created and developed. If something is described too vaguely, you know something is coming, but you don´t really know what that is.  It can’t be resolved effectively. 

Community Input – several things can be considered risky for a project and they can come from virtually everywhere. This is why you do not want a risk log biased just by your single perspective or that of a sponsor. You want as many perspectives as possible, so you have the best line of sight possible around the endeavor. You will worry about prioritizing the risks later. Yes, this means you will have lots of risks in the log; there is no magic number, just keep in mind that more is better. To give you an idea about it, our current 2 year program for a Data Center Migration is arriving at 700 D.A.I.R Log items these days. This is an average of 29 items identified per month. 

First things first – the same level of attention can’t be devoted to every risk. It actually shouldn't. Risks with greatest chance of occurrence and with the worst impact should be thrown all the way up to the top. A simple way to do this is to have a scale (i.e. 1 to 10) for each variable (chance of occurrence and impact) and multiply both of them. Someone can probably say that there are more sophisticated approaches to risk rating. True, but most projects and industries won’t require a heavily statistical or elaborated approach, just a fair way to combine both variables to prioritize all risks.

Another useful tool is a flag to indicate if a risk must be reviewed at P.M.O. level or not. This allows Project Managers to record risks they can manage on their own, and also labeling for attention of the Program Management Office a few ones requiring attention from upper management. Periodic meetings will be hold by the Program Manager to review every item flagged for attention at that level. These flags can of course be changed as necessity arises or no longer exists. 

Keep walking – Risk Management is an ongoing effort through the entire life cycle of the Project. This is why periodic review meetings are a must. Risks need to be monitored. It is responsibility of every person opening a risk to keep it up to date, as circumstances change and responses are developed and executed. New risks should be logged as they appear; the ones solved or with no chance of occurrence anymore can be closed and kept for the records and lessons learned. 

Doing all this stuff sounds a bit annoying when you have a product, result, or service to deliver, but these tasks are one of the main reasons to have you as a Project Manager. If you fail to do so, you will pay a very high price. You may end up with nothing to deliver. And so the entire organization 

“Only what is monitored, can be prevented”                              

– Sergio Calvo.