September 15, 2008 – Back to the Basic: Competing Project Constraints

Following last week’s edition, one of my project management co-conspirators dropped me a note informing me that the triple constraint (see The Troubling Triangle) is officially dead. The upcoming release of the PMBOK Guide 4th edition has killed it.

In lieu of the binding, restricting, tri-legged barer of logic, PMI has opted for “Competing Project Constraints.” The new PMBOK includes Scope, Quality, Schedule, Budget, Resources and Risk as a representative list of the numerous constraints that a Project Manager faces.

Without reading the text directly I can not make a fully informed decision about the wisdom of creating a multisided polygon constraint. For one thing it doesn’t have quite the same ring as a triangle (I’m sure there’s a bad musical percussion joke in there somewhere). However, here are my initial thoughts.

1. I whole heartedly agree that Project Managers have more to worry about than Scope, Schedule and Budget. I don’t think there was ever any real misunderstanding of that fact.
2. By removing the Triple Constraint and accompanying triangular image, we loose the visual used to explain the impact of changing one of the legs.
3. Of the examples given as other constraints, Quality is easily represented by the size of the area encompassed by the leg segments of the triangle. Although not originally part of the image, it fits.
4. Another, Resources is generally a factor of the cost (or budget) of the project. If money is no object you can get better and more resources. The New York Yankees and Real Madrid sports franchises, with their ability to buy talent, come to mind. Generally speaking, projects run out of time or money before they experience a lack in available resources.
5. For the other, Risks, I need more explanation for the use of the term “constraint.” If the term means “factors that may adversely impact your project” then I would agree.

Perhaps that is the basis of the change in the terms used. PMI may believe that it is doing us a favor by widening the term to show the myriad of chainsaws and knives we need to keep juggling. My fear is that it opens the door for management to defy the simple logic that if they increase scope, schedule or budget, one or both of the other legs have to adjust.

If we are expanding the number of constraints, maybe we just need a different image:
Picket Fence – Each of the slats represents a constraint holding the project level.
Suspension Bridge – All of the cables adjusted to keep the path safe for passage.
Multi-legged Table – Legs adjusting together to support the project.

Whatever the symbol, I will miss the triangle.

April 7, 2008 – Scope Creep in Tent City

The city of Ontario, California had a problem: a large number of homeless people. To address this, the council decided to create “Tent City” using the land around the airport. They supplied tents, water and toilets. Government agencies supplied other goods and services. Everyone felt good about themselves and life was looking grand.

Unfortunately, this solution just created a bigger problem: more homeless people. The total number of residents quickly rose to over 400. People from out of state were showing up to take advantage of the generosity. With the situation officially out of control, the city gave notice to everyone and brought in bulldozers to level the area. The new plan is to place a fence around the area and issue 90 day registration tickets to set a limit of 170 residents.

I see three warnings for project managers from this well intentioned public image problem.

First, even the best intentioned additions to your project need to be planned, estimated and agreed to. We all want to exceed our client’s expectations. The temptation is strong to add things to the project and eat the cost. After all, it’s a simple change and we are a bit ahead of schedule anyway.

The problem is that little things add up. Even if you are giving it away, use a change management process to assess and communicate the impact to the project in time, cost, resources, etc. Once the value is understood you can give it away. If you hide the value it will be appear as if it was in scope already and not really an addition. It becomes just one more homeless person entering Tent City.

Second, consider the risks involved in the actions you take. Tent City seemed like a good idea at the time but it exploded into something ugly. The council thought far enough in advance to provide facilities and fresh water but failed to mitigate the influx of non-Ontario residents. Get your team to perform a Risk Assessment early and often. You should set aside time as a team to brainstorm potential risks minimally monthly and whenever something significant changes (see topic: Risky Business).

Finally, sometimes you have to admit your mistake and bring in the bulldozers. Had the city of Ontario continued to ignore the problem eventually someone would have died. In addition to the tragedy of loosing a human life, it would likely result in lawsuits and even more bad press. If additions to your project are bringing down the property value, it may be time to plow it under and put a fence up to control the scope.

November 19, 2007 – Automotive Sponsor Problems

It is never good when your mechanic calls and asks, "How attached are you to this vehicle?" Friday was not one of my better days from that perspective. I drive a ten-year old Plymouth Neon and normally it gets me where I need to be. Sure it leaks oil and steering fluid but the AM radio still works and three of the four door locks are still automatic. But Friday it decided to die on the way to work.

The mechanic said it would take about $900 to get it back up and running. Then there was the list of things that "need" to be done totaling another $1000. I just checked and my car is only worth about $2500. I felt like the sponsor of a project that has gone bad. Actually there were three things that drove that feeling home.

Return on Investment. The mechanic was the first to bring it up with his opening question about my love for the Neon. He could tell the cost of fixing it wasn’t going to be cheap. Prior to undertaking a project, a company needs to understand the ROI, both the costs and the returns. The projected costs are more than the expenses to complete the project. Don’t forget to include training, maintenance, licensing and other life cycle pieces.

These costs should be balanced by the expected returns from the endeavor. Savings are usual the first thing considered. How many people will I replace? How much time and money will it save. Add to these benefits forecasted increases in projected sales because staff can spend less time fiddling with the system and more time with customers. Consider that the new online experience may lead to more purchases. Customer satisfaction may net more repeat business. Think through the project purpose and project the positive results of success.

Lack of Information. Friday morning I certainly didn’t have enough information to decide whether or not to give up on my car. I needed a multiple choice question and was handed only a true / false option. How much was my car actually worth? What would it cost to get an comparable vehicle? Was it worth more as scrap metal? What could I really afford? Would there be additional expenses I didn’t anticipate? If I bought a different car, would it have more problems than this one?

When deviating from or adding to the project scope, a Change Request documents the final decision, but the discussion starts by answering questions. Sponsors expect project manager to supply them with the information to answer those questions. Why wasn’t it in scope to begin with? What are the consequences of not doing it? How much is it going to cost? What other options are there? If the answers aren’t readily available, you may need to request funding to research and find them.

Risk Management. Among the "other" items my car needs are new front brakes, brake fluid flushed and replaced, and my back breaks aligned. Total cost an additional $450. The risk of not fixing them is obvious. If you can’t stop your car, something else will have to. Whatever you use to stop it (another car, a brick wall, etc.) will probably cost more than $450. As with any risk I could Avoid, Transfer, Mitigate or Accept it. Buying a new car would avoid the problem. Making sure my collision insurance is up to date would transfer the risk. Getting the brakes fixed would mitigate the issue. I opted to accept the risk and postpone the brake fix to a future phase of the project. You may want to stay off Beach Boulevard for the next week or so.

It could have been worse, though. Had the car continued to run it would have completely overheated and destroyed the engine. I wouldn’t have had any choices at that point and my next blog would have been about purchasing a new car. Don’t hide project problems from your sponsor until things overheat and there are not choice left.

April 30, 2007 – So What?

Anyone who has teenagers or has had to deal with them will inevitably run into one with a bad attitude. Even their body language says “SO WHAT?” As project managers we deal with a lot of issues, risks, problems and people. Some times it makes you want to throw your hands up and say, “So what?!?!” Actually, that might not be a bad idea. How would that look for issues, risks, budget or schedule problems and politics?

Issues. My natural inclination when someone raises an issue is to try and solve it. The next time you are confronted with one make sure to ask “so what?” So what is the impact to the project? Is it severe? Does it need to be address immediately? Is it something we can live with? Can it be addressed in future releases? Some times the impact is small enough that it isn’t worth the effort to address the issue.

Risks. Applying the “so what?” question to risks is easier since you aren’t feeling the immediate pain you do with an issue. Not all identified risks are dealt with the same way. In addition to Avoidance (sidestepping it), Mitigation (reducing the probability or impact) and Transference (making it someone else’s problem) there is the ultimate “so what” attitude: Acceptance. In Risk Acceptance you look at the probability of it becoming an issue and the impact to the project and decide it isn’t worth the effort to take action against it.

Budget or Schedule Problems. Budgets and schedules usually are scrutinized highly on projects, but sometime even they get trumped. There are times when a project has to get done. People may be willing to pay whatever it takes and wait longer to get it. I was managing on project where new requirements were requested toward the end of the testing phase. When we said it couldn’t be done the response was, “Would more money help?” Unfortunately money wasn’t the issue, time was.

Politics. I can’t stand politics. It is probably because my straight forward approach to life and management causes me to inadvertently step on toes I don’t see. The question can work here, too. I would suggest you let the voices inside your head ask the “so what?” question rather than blurting it out. So what if that person or group isn’t happy with the product? Does it meet the specs? Are they the ones paying for it? So what if they aren’t going to like the status I need to give? Is it better they hear it now before the project fails? So what…do I have to do now that I offended the boss?!

The answer to this question will help you gauge what your response should be. Sometimes you will luck out and be able to ignore the problem. Other times the answer will be to take action. Either way, you will be working from an informed position, not reacting blindly.

April 9 – Avoiding Hindsight Management

This article was originally published at http://projectmanagementlearningcenter.com/.

Growing up in rural western New York we had cold, long winters. Natural gas wasn’t cheap even then. With 4 sons and a chain saw, my dad would cut enough firewood to heat a big, four-bedroom, 2-story home from October to April.

Cutting firewood has its dangers, though. Those large oak and beech trees don’t fall quietly to the ground and stack themselves into neat, tidy rows. This manly job sparks famous last words like:

“I wonder how close I can drop this to the truck.”
“The ground looks solid enough to drive on today, doesn’t it?”
“Why is that tree hung up like that? Maybe if I pull on this…”
“What does poison ivy look like again?”

In hindsight these are all great questions but they should have been answered before taking another step. Risk Management begins with asking questions about what could possibly go wrong and then determining what to do with the answers.

Once you have identified your risks, there are 4 ways to deal with them: avoid, transfer, mitigate or accept. We will take a brief look at each of these and weigh them against their cost.

Avoid. The best way to keep from dying from a shark bite is to never go near the ocean. To the best of my knowledge, no one vacationing in Bolivia has ever been killed by a shark. On your project there are simple things that will help avoid risks. Developing detailed specifications will help reduce the risk of creating the wrong product. Choosing a known, stable development platform will lower the time expended on the learning curve and potential technical hang ups.

The down side to avoiding risks is that you limit your options. Detailed specifications limit flexibility during development. Using existing platforms will take you off the cutting edge.

Transfer. By finding someone else to take the responsibility of the risk you can transfer it to them. This is usually done for financial purposes. One way is to contract with a 3rd party vendor to fix bid a portion or the entire project. This transfers the risk of going over budget to them. Insurance is another form of risk transfer that we are familiar with. We buy insurance against the risk that our house might burn or our new gadget might break.

The problem is that this doesn’t really reduce the risk. It simply passes ownership of it to someone else. Because they won’t take it on without some reward it will probably cost you more to transfer your risks.

Mitigate. Mitigation is a proactive approach to reduce the probability of a risk occurring or the impact to the project should it happen. Documenting, assigning and tracking specific actions that will reduce the risk’s probability or impact allows you to manage risks effectively. If there is a risk that IT Architect Committee may not approve your approach, you should work with members of the committee from the beginning of the design to incorporate their ideas early.

For more information on Risk Mitigation refer to the Risky Business series at http://www.cuttingsedgepm.blogspot.com/.

Accept. Sometimes the best way to handle a risk is to not take action. It may be that the cost of avoiding, transferring or mitigating the risk is too high. The probability or impact of some risks is not worth the effort to deal with them. You may want to develop steps to take if the risk turns into an issue (i.e. contingency plan), but action other than keeping an eye on it isn’t necessary.

You will never completely eliminate risks, but by taking one of the options above you can lower the impact of it to your project. With better foresight you won’t need as much hindsight.

March 8, 2007 – Project Definition Trio

[NOTE: If you have not taken the opportunity, please register in the Guest Book to receive updates from the Cutting's Edge.]

Project definition is a tricky part of the project. If your environment is like most, you need to nail down the scope, the responsibilities and the approach as quickly as possible because the team has already started working. Given the limited time it may sound counterproductive but ideally you should create the preliminary list of risks and the project schedule at the same time.

As the image above illustrates, the Project Plan* (Scope, Management Plans, etc.), Schedule and Risks feed off each other as they are created. As the Scope Statement is defined and activities are defined they are added to the schedule. When an item is determined to be someone else’s responsibility there is a risk that it won’t be done.

While developing the Work Breakdown Structure (WBS) and Project Schedule you will uncover activities and perhaps deliverables that need to be added to the scope. Thinking through the implications of the tasks involved may trigger a thought for the Quality Plan or identify a new role to add to the Human Resource Management Plan. Risks are a natural result of drilling into the details.

Identifying Risks may expose the need for additional communication channels, tasks in the schedule or clarifications on the scope.

Working these three tools together will set your project on the right track from the beginning.

* Per PMI definition the Project Plan includes the Scope Statement, Risk Management Plan, Quality Plan, etc. The Project Plan could also be replaced with the Statement of Work (SOW).

November 21, 2006 - Risky Business Bonus: Think Positive

Based on what we have discusses so far, Risk Management seems to be about keeping bad things from happening. If you really want to throw your management for a loop, start actively managing beneficial risks.

Think Positive. The same steps we identified for keep risks from becoming issues can be used to focus on brighter outcomes. This is more than rewording your risks to have a positive flavor. Suppose you recognize that the project could be a real showcase for your company and could earn well deserved attention for your team. "Promoting team recognition" could be treated as a risk. Mitigation steps might include documenting the anticipated benefits and publicizing them to upper management. Obviously this is not a traditional risk and would never end up being an issue, but it can have a big impact on success of the project.

November 20, 2006 - Risk Management Bonus: Contingency Planning

Most risks never actually become issues. We face hundreds every day without panicking. Every time I merge into traffic from the 605 to the 405 near Seal Beach I run the risk of getting stuck in traffic for hours. Actively managing my daily commute involves checking the news or Internet before leaving and listening to the traffic reports en route. If I wait until traffic stops in front of me I may be a mile from the next exit. But sometimes my best efforts fail and I need the fall back plan.

Contingency Planning. Contingency plans are preplanned actions that can be taken when a risk meets a trigger point that identifies it as an issue. By predefining the steps to be taken there is no need to panic. People know what to do when the manager tells them what has happened.

The trap some organizations fall into is relying heavily on their contingency plans instead of actively managing their risks. By waiting until the risk becomes an issue to take action on it, projects spend more time and effort dealing with the problem.

The key is to plan for the worst but work for the best.

November 17, 2006 - Risky Business Part 5

So far we have identified, prioritized and defined mitigation steps. We have moved from a list of excuses for failure to a list of things that could save our project. But if we stopped there nothing will get accomplished and we will still get bit.

Assign an Owner. Without ownership being assigned to the mitigation steps, no one will do them. It’s like walking into your messy living room and saying, "someone really ought to clean this up." Chances are it will be messy the next time you walk in, too. It is important that the responsibility of the action be given to a single individual. If 2 or more are assigned they will either talk it to death or assume the other has it covered.

Two quick notes. First, a risk can have more than one mitigation step. Either assign an individual to each step or make one person responsible for ensuring it gets done. Second, the person assigned does have to be the one that does the work. Don't try to micromanage a separate group’s resources, assign it to the team lead.

Set a Due Date. Determine when each mitigation step needs to be completed. If possible allow the individual assigned the step to set the date. A date imposed is "unrealistic" but one that is self-selected carries a subconscious commitment with it. Granted, dates that are too far in the future will need to be negotiated.

Track it. Give things a chance to happen. Although risks can be discussed during status meetings, ideally a separate meeting should be scheduled on a monthly basis to rework the list to:
* Check status on mitigation steps
* Identify new risks
* Re-assess the probability and impact levels
* Modify mitigation steps and dates

By actively pursuing risks you can eliminate potential issues before they even start.

November 16, 2006 - Risky Business Part 4

In the first part of this series I mentioned the risk of being bit as you walk down the street. As you see the dog you identified the risk and automatically begin assessing the probability and impact of getting hurt. The value you assign to each of these depends on the answers to questions like: Is it a full-grown pit bull or a Chihuahua puppy? Is there a fence between you and it? Does the sign on the fence say “beware of dog?”

Assuming it is a pit bull with no fence and he staring intently at you while growling, several options form in your mind on how to avoid being bit and seriously hurt.

Mitigate. Those ideas are mitigation steps. They are actions you can take now to reduce either the probability of being bit or the impact of the bite. To lower the probability you could slowly backup and turn onto another street. Wearing protective gear with thick padding could lower the impact of the big, sharp teeth.

Review the top 3-5 risks on your list and document action steps that can be taken to either lower the probability or the impact. Make sure the steps are specific and able to be performed. It must be more than “watch it to see if it gets worse.”

As simple as it sounds, this is the first step away from a list of pre-recorded excuses for failure and actively eliminating risks before they kill your project.

November 15, 2006 - Risky Business Part 3

Risks spell danger for projects. There are potential problems lurking everywhere, waiting to become issues and trip up your progress. Identify was the first step in managing risks. The next step involves determining which ones to focus on.

Prioritize. Not all risks are created equal. If you spend your time pursuing those with very little impact on your project or are unlikely to happen, you won’t have time to manage anything else. The key to prioritizing them is to identify a Probability and an Impact for each identified risk.

This is not rocket science so a lot of time should not be spent on each risk. Simply ask the group how they would classify the likelihood of the risk becoming reality on a scale of 1 to 3 where 3 means that it is “very likely to occur” and 1 equals “might possibly happen.” Number 2 naturally falls in the middle.

Once you have agreed on a probability, determine the impact to the project. On a scale of 1 to 5, how bad will things get if the risk becomes an issue? Here a 5 is a major impact and 1 is very little impact with 2 to 4 filling in the difference.

By multiplying the Probability by the Impact you can calculate the PIF or Probability Impact Factor. This is a range of 1 to 15 that quickly ranks your project risks where those with a higher PIF value being the ones to focus on.

The group should then review the numbers to ensure that the risks they think are the most important show up at the top of the list. If not, discuss why and adjust the probability and impact if they don’t make sense. Don’t just change the PIF as we will discuss in the next section.
This step may seem simplistic but it is very effective in helping your team focus on the important risks.

November 14, 2006 - Risky Business Part 2

Yesterday we began a discussion on risk by defining the difference between a risk and an issue. Our ultimate goal is to document, actively work and track progress against the risks until they are no longer a threat. The steps for accomplishing this are Identify, Prioritize, Define Mitigate Steps, Assign Owners and Track.

In some environments project managers identify risks at the beginning of the project and do nothing with them afterward. There is a section in the Statement of Work or Charter that requires them to fill in the project risks and dutifully they put in the standard ones: resource availability, aggressive time frame, etc. These risks are simply there as excuses in case the project fails. The PM can go back and say, “See? I told you we didn’t have enough resources.” The PM failed to take actions to prevent the risks from becoming issues.

Identify. The process for identifying risks is quite simple: write down anything that could go wrong or have an impact on your project. Avoid the temptation to do this in a vacuum. For technical risks, schedule a 90 minute meeting and pull the technical team into a conference room with a white board and brainstorm potential problems. Do the same for the Business. Limit the time to 15 – 20 minutes so you have time for the other steps in the process. Initially there are no dumb ideas and all should be captured as quickly as possible. This is not the time for discussion. Make sure everyone understands what the premise of the risk is, jot down a brief description and move on.

November 13, 2006 - Risky Business Part 1

The picture to the right is of a Joshua tree in the desert of Joshua Tree National Park, California. When you look at the image, what risks come to mind? Your answers probably include:
* Becoming stranded.
* Getting pricked.
* Dehydration.

The answers really depend on your purpose for being there. If you are trying to cross the desert, the answers above may be your key risks. If, however, your purpose is to take pictures of the natural beauty your other risks would include running out of film, over exposure and good angles shots. Suppose your goal was to convince people to preserve the area from development? Or come live there? Each perspective carries its own individual concerns.
Risks are different from issues. The PMI Project Management Body of Knowledge (PMBOK) defines them as follows.

Risk – An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.

Issue – A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.
I would add to the issue definition that it has some impact on your project. Otherwise no one would be overly concerned about it.

To help illustrate the different between the two, picture yourself walking down the street. On the lawn up the street you see a dog and identify the risk of being bit. If you don’t take some mitigating steps and the dog bits you, it becomes an issue.

So a risk is something that has a potential impact on your project and an issue is a current event or condition. Issues you have to deal with, but risks are generally overlooked.

Whatever your project, there will be risks involved. In this series I want to lay out some simple steps you can follow to identify risks, prioritize them and either reduce the potential of them occurring or lessen their impact to the project.