1. Extend the schedule to allow for the inevitable slippage that will occur in any schedule.
2. Develop plan A based on an absolute, must have, date.  Develop a plan B with tighter dates and manage to plan B.
3. Over budget the plan.  If there is slippage add resources to make up for lost time.

At best these plans hide the real issues and at worst they are disingenuous.  We all know how difficult it is to get one plan approved, where and how are you going to find the time and support to get a plan B developed and approved? 

Here is what has worked for me.  Whether we like it or not, success is as much about perception as it is about what was delivered.  Assuming the basics have been covered:  you have clear concise requirements; roles and responsibilities have been established and agreed to; proper resources have been allocated to the project; a good plan has been developed and agreed to; the estimates are in and the schedule has been developed.  All that is left are the milestones.  This is where we need to “set the stage” for plan B.

I start by having the stakeholders divide the features and functions of the system into must have, need to have, want to have, and like to have. I commit only to delivering the must haves and need to haves.  Keep the want to haves and the like to haves on the table but make it clear that these are not part of the initial delivery.  These will only be included if time permits.  Estimates should be based on delivering everything.  The want to haves and the like to haves are cargo that can be thrown overboard should it become necessary to lighten the load. 

Ok, this is about the time someone says “Oh, but we eliminated all of the frills, no bells or whistles in this project.”  Look again, there are always options and tradeoffs.  The tradeoffs may not be ideal but can still be used in the event problems arise.  Agree to deliver the project in phases.  Much like pictures transmitted over the internet where the original picture is blurry and lacks detail but as more data is delivered the picture looks better and better until the final rendering is a clear and complete picture.  Just as with the Internet pictures, a project can be delivered in phases.  The first delivery is barely acceptable but each subsequent delivery provides more and better functionality.  Be sure the stakeholders are in agreement as to the order and priority of the functionality to be included in each phase. 

Once agreement has been reached on what will be delivered, it is important to keep reminding people of the agreement.  Again, one of the functions of the Project Manager is to manage user expectations.  When reviewing screens, reports, specifications or other design documents don’t include the want to haves and the like to haves, or functionality not included in this delivery.  Better to have two documents one with and one without.  Gain acceptance for the agreed upon deliverables then, after an agreement has been reached, bring out the document with all the want to haves and the like to haves and subsequent functionality.  If it is not practical to have two design documents, gray out the functionality that may not be included in this delivery or have the designs for the later delivery in a separate section of the same document.

 If the project dates slip, we have something that can be forfeited without compromising the completion of the project.  Conversely if everything goes as planned you just may be hailed as a hero because you gave the client everything they needed and everything they wanted.

Do you have any suggestions for a plan B?  If so I would like to hear them.

 To your success

 Steve

As stated in the No Special Glasses Required post:  Process is a systematic series of actions performed to achieve a goal, the key word being systematic.  Taking a formal approach to project management requires process.  Let’s take a look at some of the elements involved in the process.

Project Plan,
Let’s be clear, that list of tasks, dates, resources etc. is, at best, a schedule.  Schedules lack key ingredients necessary for planning a project, two of them being the objectives, and a list of stakeholders.   If you don’t have clear objectives then you don’t know where you are going.  If you don’t know where you are going how will you know when you get there?  Objectives should be stated in quantifiable terms, vague terms lead to disappointment.  Good objective should be easily converted to a checklist.  When everything has been checked off the project is done.   A list of stakeholders is necessary to know who is driving the project and who will be making project related decisions.  Know your audience.                                                                                                                       

Project Scope,
What’s in, what’s out, how big is the project?  An initial scope is necessary even if the full extent of the project has not yet been defined.  Often the scope will continue to be refined as the project progresses.  Usually the project’s success will rest on the ability of the PM to manage the scope of the project.  Without a clear understanding of what that scope is there is nothing to manage to and ultimately time and costs spiral out of control. 

 Communication Plan,
Who gets to know what, when, and under what circumstances?  This is often not an issue for small projects but even if the project is small if it is a critical project, or a project of high visibility a formal communication plan may be necessary.    A good communication plan ensures everyone is kept informed.  It also ensures a consistent message to all parties and alleviates the interruptions for “a quick status” while respecting the chain of command.      

Assumptions and Constraints,
Seldom does a project come without assumptions.  If they are not evident at the start of the project they will crop up when the estimating process begins.  It is often necessary to reexamine the assumptions as a project progresses to ensure they are still valid.  This can be difficult if there is no record of the assumptions.  Know and understand the assumptions then document them and periodically review them.

Risk Management process,
“Risk is like fire: If controlled it will help you; if uncontrolled it will rise up and destroy you” – Theodore Roosevelt.  A risk is an issue that has not yet happened.  It is not enough to identify the risks, the risks must be managed.  Managing risks means making a determination on the likelihood of the risk becoming an issue, being able to identify the issue at the earliest possible moment, and having an escalation plan.   Risk Management will be covered in the Risky Business post coming in a few weeks so, stay tuned.

Issues process,
Project Managers are paid to manage.  That means you need to manage issues not just report them.  When a risk becomes an issue someone must take ownership, the issue must be tracked, and there should be an action plan along with regular review dates.   Managing Issues also means tracking the progress toward resolution, or lack thereof and taking action.  Many projects fail due to the inability to resolve the issues.   When the issue has been resolved the resolution should be documented and the issue closed.  I don’t have a crystal ball either so there are often issues that were never identified as risks.  The PM owns the issue until a rightful owner has been identified.  It is therefore up to the PM to manage that issue in the interim.  Remember, it is not up the PM to resolve the issues, the PM’s responsibility is to find an owner and track the issues.

Decision Log,
Marcel Proust said: “All our final decisions are made in a state of mind that is not going to last.”  Hence, the need to document the decision and the basis for that decision.  Not all decisions are made immediately, often a decision is needed by someone other than the person who requires the answer.  For this reason it is important to track the question while an owner is being determined and to periodically review the status of all open decisions.  A Decision Log will help the PM to organize both open and closed decisions and may even save his/her reputation should a decision be questioned later on.

Change Control process,
I once attended a User Acceptance meeting where several of the stakeholders balked at accepting the software.  They did not like the layout of the screens and they felt they did not receive everything they were promised.  The PM reminded everyone of specific meetings in which trade-offs were made and then explained why the system was not as they expected.  Fortunately, some of the stakeholders backed up the PM and in the end everyone accepted the system.  Thanks to a good memory and some Stakeholders help the PM pulled this out of the fire . . . this time.  The PM may not be so lucky next time.  A Change Log alone will not save the day but a formal Change Control process will go a long way toward a successful acceptance in the future.  

Larger projects will require additional process and smaller projects will require fewer processes or a “lite” version of these processes but all well managed projects require some formal processes.  In future weeks I will explore these topics is greater detail.  For now these cover the basics.  Stay tuned and let me know your thoughts.

To your success

Steve

Copyright 2009, all rights reserved, S. Randall Westcott

Thank you for visiting the 3 dimensional Project Management site.  This modest beginning will grow quickly as I expect to add at least one posting a week for the next three weeks.  Thereafter this site will be updated biweekly. 

To your success

Steve

In my world I spend the majority of my time in the “directing, monitoring, and taking corrective action when necessary” catagories.  In the “No Special Glasses Required” posting I stated the PM must be a facilitator, coordinator, motivator, conflict resolver, communicator, negotiator, and consensus builder.  But how is this accomplished?   Here are some tips that might help. 

1. Protect your team.  Keep management informed and your team informed.  But, except where necessary, don’t involve team members in project issues, management discussions, or project politics.  These are your responsibility. 
2. Be sure everyone knows where the project stands at all times.  Are we on target, everyone wants to be on a winning team, are we off target why and what you are doing to bring it back on target. 
3. Be sure everyone knows and understands the benefits of this project to the company.
4. Ask and accept feedback from the team.  Be a team player.  Communication is a two way street.
5. Manage.  Take a position and back up your position with accurate and reliable data.  Focus on the data not the position.  Be willing to change your position if there is an option that is better for the project.
6.  Keep the focus on the project.  Remember, there is no right or wrong, only what is best for the project. 
7. Don’t take responsibility that is not yours.  Hold people accountable for the things they have committed to.  If there are issues bring them to the rightful owner.  These are not your issues they are project issues.
8. When correction is necessary point out at least three examples of what the person did well, then discuss the area that needs improvement.  Be specific when discussing what needs improvement.  State the goal and show where and why the effort missed the goal and include suggestions on how to meet the goals in the future.

Regardless of your management style people are your most important asset, it is through people that you get things done.  There is much to be said about each of these topics, too much to include in a single posting so I will be expending on these in the future.  Come back soon.

To your success,

Steve

Copyright 2009, all rights reserved, S. Randall Westcott

IT projects are unique in that the most important resource and often the only resource is people.  Non-IT projects typically have things like materials, equipment, and other resources which don’t have a mind of their own.  This is what makes managing IT projects different.  So let’s start with people.  People are arguably the most unpredictable aspect of project management but it is through people that the work gets done.  A good Project Manager must also be a good leader, facilitator, coordinator, motivator, communicator, negotiator, and consensus builder.  Successful PMs bring all of these skills to the project and in doing so create a coherent team that defines the depth of the project.  In future posts I will provide tips, tricks and techniques on how to be all of the above and still sleep at night.

Just as important is process.  Process can mean different things to different people.  For the sake of this blog I define Process, as a systematic series of actions performed to achieve a goal (delivering a project on time, in budget with full functionality).  The key word being systematic.  By way of example, you might create a packing list prior to leaving on a long trip.  So too we need process in projects.  The Project Plan, Project Scope, Communication Plan, Assumptions and Constraints, Risk Management process, Issues process, Decision Log, Change Control process, and other processes are our packing lists for projects.  Let’s not mistake the shadow for the substance here, a good Process does not guarantee a good product but the better the process, the better the chances for success.  For this reason I will include often overlooked details on processes that can make the difference between an ok project and a great project.

This blog is dedicated to the “art and science of project management”.  Although Process is becoming more and more of a science Procedure largely remains an art.  To clarify what I mean by Procedure I think of Procedure as particular way of accomplishing something.  In project management this would include a schedule, and resource assignments.  But, then it is up to the PM to develop the procedures using the people assigned to the project, the process, knowledge of project management and experience.   You and I will most likely have different procedures for accomplishing the same goal.  Mine work for me because of my personality and yours work for you because of your personality.  Still, there are some procedures that everyone can use and others that simply don’t work.  In future posts I will explore a variety of procedures and I invite others to contribute theirs as well.

These, are what I define, as the three dimensions of Project Management.  In the weeks ahead I will elaborate on all of these topics.  In the meantime, please feel free to forward your questions and comments.  I welcome all input.

To your success,

Steve

Copyright 2009, all rights reserved, S. Randall Westcott