Posts Tagged ‘triple constraints’

Everything is simple but one has to learn to deal with complexity: that is an apparent paradox that may have struck you as you read this and previous entries in this and other blog series. So where does the truth lie? The answer might be found in a word: Universe.

The first thing to notice is the word itself is universe, not duoverse, or trioverse. The implication with “uni” is the existence of one underlying set of principles, matter, you name it. The second part “verse” comes from the Latin word “versare” meaning to stir or churn. This gets to the diversity on your project, the mix of personalities, technologies, business models, and life in general.

So where does this leave you? How is the craziness of your project addressed so that the goal is reached within the triple constraint? Here is a possible solution:

Imagine your project’s universe is a bazaar with all the different vendors, people, attitudes, etc. Step back and look at it from a distance and ask yourself, “What do I see?” Then ask yourself, “How does the bazaar thrive and stay alive?” Then ask, “How do I weave through all the diversity on my project to achieve the goal with the given constraints?”

This can be daunting with all the different vendors and individuals with whom you have to deal. But let’s turn back to the first part of the word universe, “uni-.” Underneath all the apparent chaos and confusion the bazaar continues. It is this underneath part that holds the key to finding simplicity. People are people, business is business, technology is technology, and the bazaar is the bazaar. If you can put together a team that masters the core principles within those arenas a picture will start unfolding. It will be a clear picture. It will be a fluid picture. The bazaar called, “my project,” will stop being a noisy, chaotic, headache-producing mess and will become a kaleidoscope of all the variability present within the one set of rules underpinning the situation. The motives of others will become clearer along with the capabilities and limits within the technologies and business case. The extent to which a path exists will show itself.

So, how does one see their universe? How does one get to that point, that place where things can be seen as they are along with the reality of whether or not their is a path to success? The answer was given in the last blog. Be still and finish THE sentence…

Project Reality Check #18: Humility

by Gary Monti on April 19, 2011

All the responsibility and none of the authority,” is the motto of project management, or so it seems. Can anything be done to improve the situation? Yes. If one goes back to 12th century Italy, sound advice was given by Francis of Assisi. The purpose of looking at Francis is to see what wisdom is present rather than espousing a particular religious view. With that disclaimer, let’s move on!

How Much CAN You Do?

I had a client once who demanded all sorts of things. He was pretty much over the top at the time. In exasperation I responded to his demands by simply asking, “If I could do all you are asking would we be sitting here having this conversation? No, I’d be so rich I wouldn’t know what to do with myself!” We had a good laugh.

Inside that tense, humorous situation is a core truth project manager’s need to address.  It has to do with humility, limits, and the generation of abundance.

How Are You With The Basics?

Francis of Assisi wondered what it meant to live a good life. Specifically, he was concerned about how it reflected in community. What he stated rings true to this day:

“First do what is necessary, then do what is possible, and you will awaken to doing the impossible.”

In project management terms he would be saying, “Stick with the nine areas of project management. Learn them well and practice them repeatedly in all project work. Beware of shortcuts. Keep things as simple as possible. By doing that something will be created which can be built upon.” He was talking about being humble and avoiding over-reaching.

Build a Mosaic

It goes further, though. When one gets the reputation of sticking to the knitting, being respectful and doing a good job consistently others who want to build are attracted to that person because they see something of substance being done. This is the payoff and the paradox of working humbly and staying within one’s limits. What do I mean?

A sense of being trustworthy develops. This leads to building a team. The positive energy present pushes the team to leverage its capabilities. The team can’t sit still! At this point a synergy sets in which leads to calculated risk taking. This is a foundation from which abundance develops. It is much like a mosaic. With a few basic shapes and colors plus the flow of ideas from the team awe-inspiring works can be created.

It is important to close with pointing out that being humble is different than being a wallflower or having false modesty. On the contrary, a humble person simply moves based on the principles present and really isn’t looking for approval nor trying to be rebellious. There is strength of character present adding to the attractiveness of the person. People want what they have. If they are willing to work on the team they have a shot at getting it. And the abundance continues to grow!

Project Reality Check #15: The Requirements Game

by Gary Monti on March 29, 2011

Nailing down requirements is the number one complaint of project managers. Addressing this requires two skills: political adroitness and finding a balance point between exploring solutions and exploiting what is known and available. I’d like to share some from a workshop I provide on decision-making in uncertainty.

Political Adroitness

A mantra regarding project requirements goes something like this,

“Requirements are stated needs, expectations are unstated needs. Clients tend to judge based on expectations.”

For example, a common retail experience is a customer picking a $20 pan from a display that includes $200 triple-clad pans. The expectation frequently is quality-by-association. As you might guess, the customer ends up disappointed because food cooks unevenly, burns, and sticks to the pan. They return to the store angry that misrepresentation occurred and they want their money back, at a minimum, or demand the $200 pan at no extra charge, at the extreme.

When something similar occurs on a project the best way to deal with it is by leaning into the situation as quickly as possible. The longer the expectation is held, the greater potential for damage in the relationship. Do this is by offering possible “straw” scopes. These are scopes that fit within the time and money parameters established and meant as much for example as anything else. This can take several iterations.

Initially, the goal is getting the client to see the expectations just don’t match the time, money, and resource limits established. In other words, see if they will shift their view and do it in such a way the relationship stays intact. When acceptance of the need to shift sets in, then drive towards THE scope that appears to work.

The reason “appears” is used is simple. The scope has yet to be drilled down to clear requirements that can be turned into specifications. Which leads to another aspect of political adroitness – working with the team.

The team needs to be involved in creating the scoping alternatives because they are the ones ultimately shouldering the responsibility. As you might have already guessed, having a good working relationship with team leads and subject matter experts is critical. If these relationships are absent team members can simply say the requirements aren’t clear, take a passive-aggressive position, and leave the project manager hanging.

The Explore/Exploit Balance

In complexity theory the above falls under the “explore/exploit balance.” This is where the risk comes into play. Typically, there is insufficient time to explore all options. On the flip side, the team may run into conflict and severe limitations if they dive in based on using what has worked in the past. The solution is best when the customer, project manager, and the team all share the risk. In other words a balance is needed; one that is optimal and spreads the benefits equally with the difficulties.

To recap, it isn’t enough to simply say the client should be realistic and not expect a $20 pan to perform like a $200 one. The PM and team need to push as far as they can working with the client in developing a realistic solution – one that will save reputations, relationships, and pocket books as well as produce the desired deliverable.

Project fogs are maddening. They are:

  • Pervasive;
  • Sensed by all;
  • Capable of frustrating excellent plans;
  • Have broad impact on project performance;
  • Complex and, like all things complex, require reams and reams of reports to define thoroughly making it virtually impossible to understand on paper. Nothing specific jumps out;
  • Unable to be resolved with a quick fix;

What does a project manager do? The answer is simple and can be stated in a paradox, “Embrace the project fog.” To do this the fog must first be understood.

When a project starts “things happen” and the fog begins to roll in. It shows up at boundaries taking the form of technical problems along with the environment and key stakeholders being confused, undirected, uncooperative, unsupportive or even antagonistic. The project manager is faced with the challenge of getting the project moving again while staying within the triple constraint of scope, time, and budget.

Brittle Plans

Usually, no plan is perfect. The reason is the plan is an abstract and a distillate of the planning process. It contains what the team thinks will work based on certain assumptions and is drawn from a larger universe of possible solutions.

Within project constraints the wisdom of the team is forged into the knowledge-based plan.

There can be alternatives built in but no plan is omniscient. So, things happen and the plan can become brittle and break. This is why toy makers have children play with the final product. A two year old can quickly find limits and defects in a product developed by a room full of engineers.

The Solution: Embrace the Fog

To disperse project fogs the project manager and team must embrace it. Embracing the project fog means dealing with it on its own terms. It means finding something that is equally pervasive, can be felt by all, and has a broad, positive impact across the difficult boundary. The solution has some other characteristics. It is:

  • Readily implementable;
  • Truly simple, i.e., dispels most or all of the fog by resolving all the conflicts and uncertainties;
  • Ultimately easily documented, and;
  • Seen by all as being a realistic solution;

The solution is the fog’s equal in terms of appearance and a countermanding positive performance. It is the team’s wisdom focused into a new or modified deliverable and/or process commonly called the workaround.

Yes, the word that gets beaten and abused – viewed as something just about anyone can do so, hop to it and git ‘er done. The fact is a truly good workaround that satisfies everyone from conceptual engineer to maintenance technician could be quite sophisticated and frequently a work of art.

The workaround’s simplicity can be viewed by the uninitiated as simple-minded.

I doubt anything could be further from the truth. Why? There is no linear, detailed, step-by-step path to the solution. The successful workaround reflects a power arising from and distributed across the diverse team, not resident in any one person or thing. Changing the team members or distracting them with too much work can disrupt the dynamic and turn off the ability to embrace the project fog.

So, when confronted with project fog embrace it! Pull your nose out of the details, put the team in charge, turn them loose, buy the coffee, soda, and pizza. Let them create the simple, documentable, durable solution. Watch them work their magic!

“Hangman” is a game having a lot in common with project management. The goals are identical, i.e., figure out what the stakeholder(s) in control wants/means without them telling the project manager (PM) directly. The noose of the triple constraint tightens as the PM and team try to decipher just what is needed and they miss the mark.

There IS a substantial difference between Hangman and managing a project. In Hangman determining the word or phrase (scope) the controlling player has in mind is all that is required. With a project there is a chance for triple jeopardy since the PM and team must not only get the scope correct, they must also make sure there are sufficient resources left in terms of time and money to actually implement the scope. There is a way to not only survive but also succeed in such situations.

Terminology – Constraints vs. Principles

The first thing needed is a distinction between what is desired and what actually works. The term itself, “triple constraint,” implies boundaries of some sort. There is value in taking this term apart.

Rather than say, “The triple constraint means scope, time, and budget” stakeholders would be better served by stating, “There is a scope constraint, a time constraint, and a budget constraint placed on the project.” Why? Simple. Scope, time and budget refer to three of the nine principle sets in project management with the other six being communications, human resources, procurement, quality, risk, and integration.

“Principles” means there is a balanced interplay among all the variables and stakeholders in the project. Constraint means an arbitrary limit being placed on the project. It is called arbitrary because it is made in isolation with the responsibility for integrating being passed along illegitimately to others usually down the power chain.

That sounds like a pretty strong use of “illegitimately.” However, it does apply since the responsibility for a constraint stays with the person who makes it especially if he is the power broker.

Wishes and Business Cases

A constraint, then, is essentially a wish to make something so. What works better is examining what is realistic based on the business case. That business case needs to be grounded in reality. For example, if the project is to open a low-risk savings account then having a “budget” constraint of 1-3% interest rate is reasonable. On the flip side, if I am demanding 12% return with the same low risk then I am working from a wish list. The demand will be illegitimate if a PM in charge of investing the money is punished for failing to find a secure 12% savings account. It gets even worse if the wish of having the high return investment includes being able to withdraw any time without penalty (schedule constraint).

Stated more positively:

When needs are derived from realistic business cases rather than wishes, a bridge can be built between the business case and associated project principles comprising scope, time, and budget.

Going back to the previous blog, Rainmaker, building that bridge requires incorporation of other principle sets. In the next blog we will explore those principles with the goal being generation of a balanced relationship with realistic boundaries between scope, time, and budget. It involves the creation of something far more elegant than a triple constraint.

Project Reality Check #2: Being a Rainmaker

by Gary Monti on December 28, 2010

“Rainmaker” is a title that fits with a lot of project managers. It sets the bar high requiring a great deal of skill and political savvy to bring about the deliverable as if almost by magic. The reality is quite different. In fact, there are several realities that must be juggled to be a successful rainmaker ranging from the very concrete to the intangible. This can be seen when looked at through the nine areas of project management: scope, time, budget, human resources, procurement, quality management, risk management, communications, and integration.

Nested Easter Eggs, Projects, and the Truth

Imagine a project as a nested Russian Easter egg. At the core is the candy, the measurable deliverable – the client’s main focus. Surrounding it is the smallest Easter egg – the triple constraint. The painting on this egg is an orthogonal latticework of scope, time, and budget with one axis just a little wavy. Time and money can be measured, as can portions of the scope. The scope, however, starts bringing in the intangible because it is driven by client needs, each one of which can be multilayered itself. This is why the one axis is a little wavy.

The language of the triple constraint reflects the deliverable but is different since it includes the time and money aspect. It also is more complicated because there are three dialects; one each for scope, time, and budget.  The language gets more complicated because there is a change in the truth system being used. That is how different languages develop, i.e., attempts to describe different realities.

In other words, when we talk “deliverable” one language is used which is different from when we talk “scope, time, and budget.” For example, imagine a soccer player who can put an amazing curve on a kick. Talking about the beauty of the kick is one thing. Talking about everything that went into that player to get to the point where the kick could be made is another. (Many a beer or other beverage has been drunk enjoying going back and forth between these two languages. It’s all very human and very much a part of any project.)

The next egg (layer) has a supply chain network drawn upon it. It comprises procurement and human resources. People, equipment, facilities, etc., are needed so the project can be completed. The intangibility increases. There are more, varied conversations occurring all of which need orchestrated and harmonized. The discussion around this orchestration and harmonization creates another language with two dialects.

This brings us to the next larger egg, which has a swirling pattern of two distinct colors representing quality- and risk management. Imagine it being drawn by a pointillist. Each dot represents a specific test of a component or system (quality) or a specific threat or opportunity (risk) that must be addressed. Holding the egg at a distance the swirls can be seen representing the interaction between quality and risk and how together they influence the inner components of project management and the creation of an acceptable deliverable. And, you may have guessed it, yet another language with two dialects is created.

And what about the conversation itself? This is where communications comes into play. This egg has a nervous system painted on it. Actually it is more like an LCD display where the flow of information through the nerves can be seen. This flow represents the even greater level of intangibility. Why? The message is in the flow between the various parts of the project.

Finally, the largest most intangible egg of them all – project integration. It is invisible. This egg can be felt but can’t be seen. Imagine a magnetic bottle. There is a very real force field present containing the other eight areas of the project along with the specific project components, stakeholders, and the energy that flows between them. This egg can be experienced, it can be discussed, it can be influenced but it remains invisible. Its language is one of connection and interdependence.  It reflects the achievement of acceptable balance among all stakeholders, components, and their performance. The integration exists in that balance rather than inside any one thing or person.

The deliverable only comes alive and is acceptable when integration has occurred and is sustainable.

What does this mean? An intuitive example of connection and interdependence is the relationship between an aircraft wing, the engine, and the payload. The engine must generate sufficient thrust to propel the wing forward and generate lift. However, if a large enough engine is too heavy then the design is pointless because there is insufficient lift left for the payload.

What makes a project manager a rainmaker is the ability to achieve that integration. It is reflected in commitments within the stakeholder community. Those commitments are then mapped into the design and creation of the deliverable through the project plan and execution of the schedule. Oh, did I mention there might be some magic involved?