Posts Tagged ‘project reality check’

Students from around the world list starting the project without clear requirements as their #1 problem. Last week, in a workshop addressing this issue an interesting response surfaced in about a third of the students. In a word, discomfort. Why would this happen when something that benefits the PM and team is being developed? Let’s explore.

Some background about the method will help. It teaches simultaneous development of a scope of work and determination of a possible political path providing a high probability of successful implementation of the proposed scope of work. No small feat, just ask any project manager!

Scope and Politics

Developing scope in a no-scope environment entails using a method developed by the astrophysicist Fritz Zwicky. It is called Morphological Analysis. The short version of how to use it goes something like this: using the variables associated with the project think of all possible scopes in the situation. Go through and eliminate those that have contradictory requirements, e.g., simultaneously tall and short. This will reduce the list of possible scopes dramatically.

Now, switch to game theory. List the stakeholders (players) who can impact the development of the project and its execution. By stakeholder, list the way they are playing their particular game (strategy), and the reward (payoff) they want. Generate a 3 dimensional grid, comprising player, strategy, and payoff. Now the fun begins!

Map the list of possible scopes into the strategies and payoffs.  List the scopes that have the highest probability of surviving the games being played. This typically leaves a very short list of possible scopes. Pick one and start promoting it. Keep the other scopes as possible backups should a shift in plans be needed.

Seems straightforward enough and, for many it was. So why would some attendees experience discomfort?

Fear and Honesty

In her classic book, When Things Fall Apart, Pema Chodron states:

“Fear is a natural reaction to getting closer to the truth.”

In the workshop confusion, discomfort, fear, and some anger arose. The class was paused and a chart session was used to find out what was happening. Students gave a range of responses. Here are a few:

“Looking at gamesmanship so directly pushes on me. I have to go into my unconscious incompetencies and decide what to do about the politics. This is good.”

I made a career-altering decision 8 months ago and things have been tough ever since. This class, though, is validating I made the right decision and will continue implementing it.”

“I work with a nice guy who isn’t pulling his weight. We have the same boss, whom I like, and she wants him to do better but nothing gets done. I am feeling a lot of pressure. This class is getting confusing!”

“Why this game stuff? We have technical work to get done and I just don’t see where politics applies.”

“I don’t see where any of this is relevant! Just how am I supposed to use this?”

That first respondent is very self-aware. She stayed with her discomfort and did quite well with the material. Prima fascia, she would make a good team member. The last respondent left in anger at the next break.

But the other respondents, what about them? There isn’t enough space to go into them right now. Instead, it would be better to close with a list showing a few responses people may choose in a no-scope situation. Having this list may help you profile your own situation and determine how far you could get with a given scope based on the stakeholder population, time, money, and resources present. Here are a few of the possible positions people can take:

  1. Is a natural in this situation and is on board;
  2. Has a fear of dealing with politics and reacts by actively work against the project;
  3. Can see benefit but is afraid to go to those uncomfortable spaces where politics is addressed and stalls;
  4. Is afraid but sees the benefit of pushing on themselves and working through the difficulties and is willing to push through;
  5. Only likes working in defined situations and goes blank in no-scope environments.

Maybe by keeping the above in mind and looking at your own power, authority, time, and resources you can gauge just how far to push with which scope. Ideally, you’ll do reasonably well and live to see another day and manage another project.

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!

Two key computers crashed irreversibly last week and an unobservant driver hit my car. Business deadlines can’t be moved. The next 3 weeks are on the road. What to do? Pause, breathe, think and act. It’s just another project, one that is rather personal but still a project just the same.

Pause and Ask The Right Questions

A series of questions helped steer through this project ask:

  • Even if it is unrelated, did these events occur while pursuing what is best (to do)?
  • Separate from personal feelings and desires can I accept myself, the situation, and the people involved?
  • Can an adequate list of the principles and constraints be listed by a stakeholder? This list started at the moment of the accident and computer crashes and includes the policeman, other driver, insurance agents, computer repairman, clients, etc.
  • Can personal limits along with available resources be listed?
  • Is there a risk management plan in place for dealing with loss of time, money, and resources?
  • Can an adequate plan be built to get back on track and stay on track? Can that plan adapt to new information?

Breathe and Think

Before getting on to using the questions it is worth pointing out the saving grace to all this is the “what ifs” thought through over the years along with implementation of associated strategies. It is in line with an earlier blog regarding the  “Titanic,” i.e., instead of trying to design a ship that wouldn’t sink it would have been better to design in response to the question, “What do we do if the ship does sink?” Applied here it’s translated into saying well in advance, “It could happen, lean into it, generate a plan,” instead of just reacting to problems by saying, “This shouldn’t be happening to me because…!”

Take Action

Actions comprise weaving the results of pursuing the questions with the risk response strategies. Centeredness has taken shape in the midst of the anger, disappointment, frustration, etc., This centeredness surfaced the question,

Do I stay with what can be done or get lost in reacting?

One example of staying with what CAN be done involves some key databases and revolves around asking, “What if the hourly backups that should never corrupt actually do?” The worst-case costs led to additional backups on separate equipment for especially important files beyond the imaged external hard drives. THAT strategy paid off handsomely. Somehow the hourly files were corrupted and there has been no time to explore. The additional belts-and-suspenders backups saved the day. They are running well with the new compute. The jury is still out on the second computer, which is being fixed under warranty.

The gods of blogging must have been watching all this. When going into the computer shop a conversation was under way. It went something like this, “We couldn’t recover any data. You can send them to a recovery specialist. Prices start at $700/hard drive and go up from there. Since you have several hard drives that need recovered…well you can see where the math is going.”

Pause, breathe, think, and act. The more it is done when everything is okay the better it will be when things go south.

Did I mention my car was hit? With that there is repair, a rental, insurance adjusters, claim adjusters …whoa!…got to get packing! Plane to catch. It looks like more pausing, breathing, and thinking while on the road. Sleep will be sometime in May.

Project Reality Check #16: The Folly of Audits

by Gary Monti on April 5, 2011

“No good deed shall go unpunished,” is crazy but commonly experienced. Why is that? Why would an audit trigger punitive measures? After all, when doing one’s best it would seem safe to assume the value of the work would be recognized and would show in the numbers. This could be considered especially true with this series of blogs since earned value has been trumpeted as the heart of project management. So what is the problem? The purpose and value of reports is a good place to start.

Reports And The Meaning of Numbers

Why have reports? Simple, they sustain communications in a relationship especially when everyone can’t be together at the same time. Consequently, numbers are abstracts – distillates – of a relationship. And now the plot thickens! Communications are complex, multi-channeled, multi-contextual activities. Look at the simple joke:

Take my wife…please!

How many layers (contexts) does that joke have? It has at least two. The joke is in the collision of those contexts. Unfortunately, when that collision of contexts occurs on the job it is more of a tragedy than a comedy. The folly occurs in this collision. It puts very sharp teeth in the bite of “no good deed shall go unpunished.” So, what does this have to do with audits and reports? Plenty. It has to do with context and expectations.

Context and Expectations

So when do audits and reports go haywire?

Audits and reports go haywire when they are laden with expectations that fail to map to the reality of what it takes to get the job done or the reports project an inaccurate balance between all the contexts present.

Looking at the cause of all this will help.

The Devil Is In The Dynamics

There’s an old saying, “The devil is in the details.” There is truth in it. However, it doesn’t cover all situations.

For complex projects the devil is in the dynamics. The failures and flaws are not with the individual person or component. Rather, they exist in the dynamics between the organization and operations.

Most reports are designed to address what senior management believes are the policies and procedures, which are based on management’s expectations. Typically, this is all laid out at the concept and design phase. When a system goes into operations, though, a new element comes into play – reality. Think of the Mars rovers and all that has been done to keep them operational. Unforeseen problems had to be solved. This has led to a much longer life expectancy for the rovers than was ever anticipated. No one is going around blaming scientists and engineers for the problems encountered per the original plan. Instead they are being recognized for throwing themselves into the problems and coming up with solutions. Some work, some don’t. Looks like one rover is down for the count. Overall, though, the program has been a great success.

Listen For The Solution

A chapter can be taken from the Mars situation in generating a solution to poor audits.

The solution to poor audits is in listening; listening for how people work to get things done in spite of the system.

Again, reports are distillates of relationships. This means communication, which is a two-way street. Yes, senior management needs to determine the direction the company needs to go but this should be tempered by and informed from the wisdom and experience of those in the trenches, unless, of course, the managers are clairvoyant. My recollection, though, is years ago Madam Cleo tried that on her cable channel and went bankrupt.

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 Reality Check #14: Death of a Project

by Gary Monti on March 22, 2011

The death of a promising project is jarring. It may open the door to opportunity. It may also lead to more problems. Which path is illuminated depends upon what the stakeholders, including team members, choose to do with the pain.


The stages of grief – denial, anger, bargaining, depression, and acceptance – are known by many. What isn’t commonly known is individuals have the ability to refuse to go through them and simply stay stuck at one stage. This can be seen at funerals and wakes.

There are those who lack any significant response and their turn in the pit of unfairness of life will come with some other event. Others are shattered and will need time to put the pieces back together in a way that puts the loved one’s death in perspective by incorporating something of the deceased’s spirit in moving forward in a significant, positive way. Still others who experience grief simply want to go “back to sleep,” get through the situation, and return to a monotonous sense of security that can be shortsighted, numb, and insensitive causing a walling off to occur along with stunted growth.

Keep the somber images above in mind when doing lessons-learned on a promising project that somehow failed, and failed dramatically to everyone’s surprise. There is nothing magical about lessons learned. If they are to be beneficial each stakeholder and team member involved must put some piece of themselves into the process and risk being transformed.

Robust Lessons Learned

What can help is changing the way lessons learned are performed. This can be done through resilience engineering (RE), steeped heavily in chaos and complexity theory. Two concepts from RE that help are “robust” and “resilient.” They can be used as lens for placing value on contributions to lessons learned.

Traditionally, a robust approach is used. Here “robust” means the ability for the system, as it is, to respond to change, especially threatening change. The overall structure of the system does not necessarily change. As is, the system changes tactics based on the threat being projected. This sounds pretty good. There is a trap present, though. An example may help.

Imagine a downsized company with resources stretched thinner and thinner having avoided major catastrophes on the last few projects. It is natural for phrases such as “best of breed, lean-and-mean, etc.” to start getting bandied around. With the lessons learned from each project a growing sense of false confidence can develop, one that leads to a “going to sleep” as to how close to the edge the team actually is. Suddenly – BANG! –  a high profile project starts falling apart and a chain reaction of failure sets in moving at the speed of sound. What makes matters worse is nothing turns up when doing root cause analysis to determine where a fix is needed. No matter how hard everyone tries, workarounds have no impact or the workarounds make matters worse.

A Paradoxical Approach: Resilient Lessons Learned Ahead of Time

A better approach to lessons learned on the previously successful projects would be through resilience. As used here, resilience asks and answers the questions, “What is the nature of success? How can we sustain it? How close to the edge are we? Can we adapt? If we do, how must we change our structure and the way we do work?” Done properly, this approach to lessons learned helps puncture the false confidence and leads to a more sober, positive approach to building for sustained success. In the example this would lead to addressing human capital well in advance of the catastrophe. The paradox, then, is lesson learned would be performed BEFORE the next high profile project began in an attempt to avoid the catastrophe.

In closing, there is one key difference between the robust and resilient approach. Rather than root cause analysis the resilient approach examines the socio-technical complex present in the organization. It looks to see where everyone is “drinking the Kool-Aid” and a collective march towards the edge is occurring while everyone believes success is just understood to occur.

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!

Powerlessness brings its own power.  A word of caution is needed, though. Using the power that comes with powerlessness can stir up a hornet’s nest. Having said that, let’s dive in.

“One Question” Revisited: The Short Version

In the previous blog, Frame of Mind, one question was mentioned as being central, “What happens when you follow the rules?” A variation of that question applies here.

What rules apply to this project, how do you see them used, and what is your part?

Ask this of the stakeholder population from client(s) to team members. Look at what is required for the project to succeed. Perform a gap analysis and, voila, you will have a picture of just how far the project can or can’t go. Publish the picture. Do what you can.

There, that was easy. Or was it?

“One Question” Revisited: The Long Version

An important character trait was left out of the mix, one that turns things on their collective head – Expectations. People want what they want when they want it. This includes expecting underfunded, understaffed, underspecified, time-pressured sows ears (contracts) being turned into silk purses (deliverables).

What to do? If the project manager has enough authority then that is sufficient to create the necessary change orders. Without that authority the project manager needs substantial power from another source – himself. The necessary character traits include:

  • Acceptance which answers the question, “What can we do with the committed resources we have? If you listen hard you’ll hear earned value in the background;
  • Willingness to speak honestly without being judgmental is delivering that picture mentioned above. The project is as it is;
  • Humility is very important. It simply is – stating personal, team, and project limits. It also has another aspect, which shows up when combined with the next character trait;
  • Courage is the ability to stick with all of the above in the face of expectations. Humility comes into play with courage when the bombardment of expectations starts raining down. The PM can speak something like this, “You seem very confident this can be accomplished and have stated the team SHOULD be able to do it. Why do you believe that? Who has succeeded at this before? I need to seek them out and learn.”

There is a responsibility with this last approach, i.e., efforts to do the ear-purse conversion have been tested and legitimate barriers have been reached or there is credible lessons-learned available that bring into doubt the probability of success. At the very least a good resource assessment has been performed and comes up wanting.

What To Do

Stay with the humility by avoiding saying, “No.” Simply state what is needed to achieve the goals.  Approach from a humble position. It shows respect and empathy. Keep the focus on the gap. Whatever you do, keep the conversation open and stay with trying to make things work. But also stay humble and avoid turning away from the limits of the situation.

Caution: Avoid Magical Thinking

I want to close this blog with words from one of my mentors from long ago, “When there is no project let go of the situation BEFORE you get the ulcer. No amount of badgering, whining, aggression, or anxiety can magically multiply commitments. Others have to pony up. As PM you are one person who can work maybe 50 or more hours for brief periods.”

It’s simple. Stay in touch with the real limits and don’t flinch. Now, that is hard!

Project Reality Check #11: Frame of Mind

by Gary Monti on March 1, 2011

“Everything is simple,” is one of my mantras. To hold true it depends upon two things. The first is greed, fear, rage, and ignorance are absent. The second is the right perspective, one’s frame of mind or point of view, is appropriate for the situation. Let’s take a look at the latter and how to establish a realistic point of view.

One Question

In line with “everything is simple,” one question is sufficient to determine what frame-of-mind or perspective is appropriate for a project. The question is,

“What happens when you follow the rules?”

There is a whole plethora of answers. They tend to fall into the following patterns:

  1. Things run like clockwork! When everyone in my group sticks to the rules and does what they are supposed to do then the work gets done and we can feel good at the end of the day.
  2. Reasonably well as long as our boss makes the right connections with the other bosses. We’ve been at this for a while and over time have accumulated a range of customers and products with different demands and requirements. We work it out, though, and keep the customer happy.
  3. It depends since some groups cooperate with us and others go their own way. We spend a lot of time “greasing the wheels” around here working to keep people connected to the project and stay on-task.
  4. Which rules are you talking about? The rules change from day-to-day and situation-to-situation. Oh, wait! They also change with who is in charge at any given time!  It puts a lot of stress on us in the trenches but we take pride in making things work out. Don’t get me wrong; it’s anything but perfect. We’ve had our share of snafus and paid dearly for them. But we learn and work to do better the next time.
  5. I honestly don’t know. This place is different now. I stick to the policies and procedures in our department and get along with those around me but we can’t predict how things will turn out. Some days are good, others aren’t. It’s wearing. You just can’t depend on things going like they used to.
  6. What rules? This place is a free-for-all. I am surprised we are still in business.


The frames-of-mind present are:

Simple for “1.” The rules are clear and concise and results are predictable. The methods work so a top-down approach to projects fits. The project needs primarily to be managed.

Complicated for “2.” There are multiple sets of rules present based on the history of the organization and adjustments are needed from product-to-product and client–to-client. Overall, though, no new demands are being made. A top-down approach still works.

Complex for “3.” And “4.” Work increasingly is getting done from the bottom-up. Solutions emerge from team members working across boundaries to establish day-to-day tactical connections that they hope will yield the desired strategic results. Facilitation would work here. Turn the workers loose to create the solution but hold them to the acceptance criteria. Failures are simply experiments that yielded unexpected results.

Chaotic applies to “5.” This is a dangerous situation since ups-and-downs occur for the organization but are unpredictable. People are putting in way too much effort in an attempt to get daily activities complete. Empowerment of employees to (re)build the organization works here. The leader’s focus is pointing to the goals that must be attained to survive and succeed. Honest, open feedback is critical and the encouragement of trust and building bonds among stakeholders and team members.

Random is at play with “6.” All signs of business intelligence have disappeared. It is just a matter of time before going out of business.  Do ANYTHING to get out of this state or just cancel the project and move on.

The Reality and the Challenge

The reality and challenge are the fact that all 6 frames-of-mind or some subset can be present on a given project. The goal, then, is to make sure the project terrain is gauged accordingly and the style(s) adapted are appropriate. In other words, you might be using top-down with a part of the project that is truly simple. A hands-off approach could be used with a part that has yet to have a solution emerge. Finally, scope may need to be cut with a third part of the project that is currently unrecoverable.

Remember, everything is simple (if you have the right frame of mind)

Watching how change orders flow is one of the simplest ways to determine the adequacy of relationships and the project management system being used.  The degree of realism present can also be assessed.

Why Change?

Over the years, PMI® has shown in the Guide to the Project Management Body of Knowledge® more and more acceptance of the need to address change as the project progresses. Why? Stakeholders rarely understand everything needed to address their needs. Frequently, they don’t have a clear set of needs or have a poor understanding of their situation and go looking for something that isn’t going to be all that valuable in the end. On top of this, the vendor does not always know what they will run into and has to shift their approach accordingly. Consequently, change orders are a “must” for almost all projects.

Shall We Dance?

Up front, the vendor and client will do best defining the change order process. The choreography is laid out ahead of time. You can imagine, then, what it must look like if there is no change order methodology in place and the need for a change surfaces. Imagine a couple on the dance floor, everyone watching, the lights focused on them. Also imagine no dance step has been chosen and the orchestra is waiting for the music.

Just like good dancers, three major considerations will drive the client-vendor relationship when it comes to planning and performance:

  • Appropriate principles and approach
  • Organization
  • Discipline

Appropriate principles and approach. Each dance has a context, a history, and framework from which it flows and which also provides meaning. It can vary dramatically from dance to dance. Think of Flamenco and then compare it to Thai classic dance.

The same is true for project contracts. Is it design-build, time and materials, fixed fee, etc.? The framework for the dance (project plan/execution) is defined based on the contract. In turn, the boundaries for the change order process are also defined, e.g., the vendor will have to absorb any change orders associated with their own design flaws if the contract is fixed fee.

The vendor COULD ask the client to absorb the cost and go outside the established framework but this could get very confusing and prove to be impractical. Imagine dancers switching from Flamenco to Thai classic dance in the middle of the performance.

Organization. The contract selects what dance will be performed. The choreography puts detailed structure to the dance. Think network diagram and RACI charts.

Discipline. Now comes an even harder part – practice, practice, practice. Just like a dance pair, stakeholders from both sides of the contract must commit and engage at a very detailed level if the performance is going to be smooth and appear effortless.

The Importance of Change Orders: Performance not Perfection

For the uninitiated one might think a strong enough focus on principles, organization, and discipline would be sufficient. Rarely is that the case. Regardless of the level of detail and planning brought to a situation there always is some variance in performance present. This is where change orders come into play and why they are so important. Imagine one dancer leaping and being caught by the other. The ability to gauge and adjust to shifts in centers of gravity is extremely important. One or both dancers could be hurt seriously if that ability were missing.

Change orders provide flexibility to keep performance successful.

You can see how this makes sense when in the framework of principles, organization, and discipline. If no dance has been chosen, the dancers have yet to meet and the musicians have yet to work together let alone have no idea of what they are going to play – no amount of wiggle room to make it up as they go will help.

It is dangerous to believe enough change orders will compensate for vague contracting, lack of planning, and little or no discipline.

In other words, the more time spent defining the product along with relationships and mapping these into the appropriate contract format the better. It supports clear, frank discussions as to what the best change order process is and inclusion of such in the contract language