Three: Project Planning (Detail Level) Risks & Ways to Avoid Pitfalls

Project Planning (Detail Level) may afford the Project Manager the last opportunity to plan for the successes and prepare for the disasters that may follow. Once the Project Plan has been accepted (read: set in stone and put aside) the events will unfold in their own due course: following the plan (more or less), or arising spontaneously, haphazardly and perniciously to jeopardize it. Your mission, should you choose to accept it, is to position the project so as to enable the former and impede the latter, or your plan will self-destruct in no time flat. What are some of the key elements of Project Planning (Detail) that require the most attention? The following table identifies processes and tasks that are highlighted in this section.

Process

Task

Why is it important?
Choose your Impossible Mission Force wisely they must be fully prepared and totally committed. The more impossible the mission, the greater the need for precise planning. It matters not what you know about the ambush, but what you will do to avoid, or overcome it. Who has the authority to change mission parameters? When and how? What is your exit strategy?"

Conduct Project Planning Kick-off

Orient New Team Members Refine Project Schedule Develop Risk Management Plan Define Change Control Process

Refine CSSQ

Perform Risk Assessment

Refine Project Plan

Define Issue Escalation and Management Process

PITFALL #1 You Have the Wrong Team

Before you get to play the leader, you first need to form your team. As a Project Manager appointed to a project, you probably think that you have very little latitude in selecting your team. Most likely, you are right but it never hurts to try! And considering that these are the people who will define your success (flashback: what is the definition of management? answer, getting work done through others) you should certainly make every effort to surround yourself with folks who not only have the right alphabet soup on their resumes, but also have the right stuff to form a high-performing team.

It is a hard, and maybe even a counter-intuitive lesson to learn, that the right combination of character and intelligence or, in other terms, of attitude and ability to learn is far more important than a particular type or even length of experience. Here are some pointers for selecting and weeding out team member candidates. When selecting new team members, the first attribute to determine is aptitude. Whatever the technology or tools they will have to use, do they have a knack, a natural inclination for it? Do they take to it, do they do it on their own time, and do they innately like it? Have they chosen and succeeded at it in the past? No degree, no level of erudition or IQ, guarantees that a person has an aptitude for a given job. And if they dont beware. No matter how hard they work, or how much they study they will still not produce the same results as someone with an aptitude who seems to knock off tasks left and right with nary an effort. The second desirable attribute is work ethic. Whatever your expectations are of the level of effort required on the project, you must be able to answer an emphatic Yes! to these two questions about each new team member: (1) in the normal course of events, will the person put in an honest days work? and (2) when the circumstances require it, will the person do whatever it takes to get the job done? Both questions are equally important, and both demand an affirmative answer. The third requisite attribute is versatility. Despite what you forecast on your schedule, and what you outline in roles and responsibilities, your team members will have to either substitute for one another, or perform some tasks you cannot currently anticipate. The team will need to be able to adapt to different circumstances and to learn new skills. Consequently, people who have a track record of performing well in disparate environments are certainly preferable over fragile personalities who are thrown off their pace for a week when a time sheet format changes, or who cannot function unless they have the right view out their window. Likewise, folks who have a track record of learning new skills and techniques, especially on their own, are vastly preferable over the types who must attend weeklong vendor seminars (preferably in tropical locales) before they can be persuaded to learn anything new. The fourth, and final, attribute to look for and look out for! is temperament. Or disposition, or attitude, or character whatever you want to call it. It makes a difference between enjoying camaraderie and synergism of a close-knit team and dreading coming to work in the morning. Another way to stack your deck is to make sure you have the right combination of types for your team. Every team can benefit from one or more of the following:

An "Eager Beaver." This is a person who typically has little experience with whatever technology your project is employing, but more than makes up for it in sheer persistence. You need these folks to carry the load.

A Guru. This is someone who knows everything there is to know about the subject, and is willing to teach anyone everything he or she knows; hopefully, the subject is what your team will actually need the most of. You need these folks to provide expertise and to solve real problems.

A Mother Hen. Male or female, this is a person who will remember everyones birthday, take up collections for baby showers, and organize extracurricular team activities. Hopefully, they will have time left to do some actual work. You need these folks to maintain morale, provide team cohesion and balance the professional with the personal.

A Gadfly. Only in the sense of acting as a constructively provocative stimulus (The American Heritage Dictionary of the English Language, Houghton Mifflin), this person is indispensable in providing creative new ideas and challenging the status quo when improvement is warranted. You need these folks to help the team come up with creative solutions, and to continuously improve the process.

A Leader. Finally, in addition to yourself, you need senior people on your team to inspire the other team members to accomplish their goals, as well as to hold them accountable when they don't.

PITFALL #2 You Plan for Success. Only.

Lets say you are going on vacation, driving through an unfamiliar area. As you are tuning the radio to a local station, you hear that theres a huge tie-up by Exit 11 of the route youre traveling on. You look up and see that you just passed Exit 10. What good is knowing about the obstacle at that point? Would hearing the news at Exit 9 or earlier make a difference? Only if you had a local map and could plot your way around the obstruction. But what if you knew, when you were first planning your trip that Exit 11 on this highway was under construction? Would you not lay your course differently to avoid the delay? So it is with risk mitigation. Identifying the risk is good; but planning a wise course of action around it is infinitely better. Planning mitigation actions ahead of time also removes the pressure of the moment, and allows you to clearly see the forest without bumping into the trees. However, planning ahead for an eventuality that may or may not happen does not quite sharpen the mind with the same clarity that an immediate crisis does. It is not easy to be honest and tough, to avoid pat answers and rosy scenarios. Thats why it is useful to prioritize the risks first (using the Risk Management Worksheet) and start working on the ones that have the greatest chance of sinking the project. The anticipation of a disaster ought to concentrate your mind on a realistic solution, and allow you to plot the best course of action around major obstacles.

PITFALL #3 You Are Overcome By Change

Some projects resemble the Blob from the eponymous 50s movie (and its unnecessary 80s remake): they absorb any obstacle in their paths, growing larger and less well defined all the time until someone finally puts them out of their misery (usually, by freezing the funds). Unfortunately, a lot of people get hurt in the debacle. One way to avoid this fate is to know what the project is and is not and keep it that way. A good Project Plan is certainly a good start. But either according to the risk mitigation planning you did, or in totally new and unpredictable ways, one thing you can definitely count on during the course of the project: CHANGE WILL HAPPEN. And whether you are prepared for it or not, you will have to take actions that deviate from your Project Plan. However, by the very nature of the dutiful sign-offs you so diligently pursued, you have no authority to undertake actions that deviate from your Project Plan! Thats where the Change Control Process comes in handy. You will need to know:

What constitutes a change How to respond when a change occurs Who can approve the new plan of action

What constitutes a change? Simply put, anything that in any way deviates from the totality of your Project Plan as the Project Sponsor and/or Project Director accepted it. Some examples: If your project approach is not working for whatever reason and you need to modify it ... ... it's a change. If your Project Scope changes (beware the scope creep!) ... ... it's a change. If your Project Schedule needs to be modified either up or down ... ... it's a change. If the quality standards in the organization change ... ... it's a change. If the budget gets cut ... ... it's a change. If you adapt a different communications mechanism because it works better ...

... it's a change. If your Project Team composition changes ... ... it's a change.

Of course, not all changes require the same level of response. It would be ludicrous to initiate a formal change control process and demand a sign-off when all you are asked to do is to change the date format on your status report. However, if you get fifty contradictory requests for formatting changes that effectively prevent you from getting your status report out on time you may well need to wake the change control Cerberus. All changes need to be documented, but it is useful to separate changes into two categories: those that affect the projects Budget, Schedule, and Scope and those that don't. Just remember that an accumulation of tiny, seemingly insignificant changes can affect Budget, Schedule, and Scope just as much as one big obstacle: if you remain still long enough, piranhas can get you just as surely as sharks. So your change control process needs to explicitly state that you will consider any variation to the Project Plan as a change, and will respond to it in one of two ways:

Changes that do not affect Budget, Schedule, and Scope will be documented in your status report. Changes that affect Budget, Schedule, and/or Scope will trigger a change control process.

Finally, the change control process needs to explicitly define who has authority to approve a change. Usually, different people have the prerogative to approve changes of a different magnitude or kind. Having it clearly spelled out up front will save you many headaches later.

PITFALL #4 Why Can't We All Just Get Along?

Your schedule is as tight as a drum; you've defined deliverables until no ambiguities remain; everyone knows what to expect and when. You think you are done? Only for as long as it takes one of the decision-makers to disagree with you. And disagree they will! The Customers will disagree that what you are delivering is what they had in mind all along. The Stakeholders will disagree that they are not being adversely affected by the new product or service. Your own Project Sponsor and/or Project Director your purported guardian and protector will disagree that the budget commitments were actually made for next years budget. When something like that happens, you need to be able to appeal to a higher authority. Unfortunately, if you have not obtained the higher authoritys okay, and others concurrence, to appeal to them well ahead of time, you don't stand a chance. You have to define, right up front, who will arbitrate when you and your Customer, you and your Stakeholder, and you and your Project Sponsor and/or Project Director , have a difference of

opinion and cannot negotiate a compromise. And the time to plan for it is early on, when you are still their best friend and you have no active issues at stake.

PITFALL #5 WE don't REALLY need to follow all these steps, do we?

In most PM-immature organizations, as soon as the project enters an area when some real work needs to get done and real resources applied, the questions start: "Do we really need all this methodology junk?" "We should just concentrate on what REALLY needs to get done." "Its crazy to expect us to create all these deliverables!" "We don't have the luxury of making the plans look pretty." "Why do we need to do (fill in any deliverable/process)." "We need to produce results not waste time on methodology." "If we produce all this make-work we will not have time to DO anything." Etcetera, etcetera, ad nauseam. Of course, what these comments betray is a fundamental lack of understanding of what Project Management is all about. Project Management (as well as just basic Management) methodologies were developed, all over the world, in response to crises and disasters that resulted precisely from the kind of seatof-the-pants approach that the doubters actually advocate. To cure the root cause of this attitude would take massive organizational re-education and PM "conscientiousness raising." Unfortunately, you (the enlightened Project Manager) don't have either time or authority for that. What you can do, though, is to say No clearly, articulately and resolutely. No, you will not substitute a vague verbal statement of intent for a thoroughly written scope statement. No, you will not take a promise to let you have our best people when you need them instead of a signature on the Project Plan. But lets be realistic the pressure may get intense, and you may not have a choice. Your own manager, the Project Sponsor and/or Project Director , or an influential Customer, may force your hand into short-changing your deliverables or skipping on your tasks. Your only recourse at that point is documentation. Document the specific risks to the project. Document the fact that a business decision was made to accept those risks. Just dont become a willing accomplice in jeopardizing your own project. Don't go along to get along. Resist organizational inertia and stick to your principles.

Final Phase Responsibilitiesby Rick A. Morris, PMP

Okay, so what do you have to do to properly end the project? The following checklist will get you on track for closing the books.

Make sure all unfinished project activities are completed. Many project managers drop the ball at this point, assuming everything is done because most tasks are completed. Assume nothing do a thorough review. Sometimes people cut corners to move on to their next project or operations. Don't let this happen to you. Set up a task list of final items and review it to ensure that everything is completed and the quality of the work is satisfactory.

Have a team meeting to evaluate the project.You may do one meeting with your team to prepare a wrap-up presentation for stakeholders. Determine how you got where you are, and what you might do differently in the future. Review your documentation to be sure it's complete for the next project team. Include a thorough review of the budget, your resources, and barriers. Share what you learned the hard way to save the next team time and money.

Meet with stakeholders, sponsors, and anyone else who needs to approve or sign off on the project. Make sure that everyone with final authority agrees that the project has concluded. Finish off all accounting procedures including paying final bills and fulfilling all contracts. Make sure all bookkeeping is up to date and all information for team members is accessible, including personal information needed for 1099s or other taxrelated documents. Your goal is to close the books on the project before shutting off the lights.

Make sure all documentation lands in the hands of those who will need it in the future. If you have created a new product or started a new service that the sales team will now be selling, make sure the sales force has all the information (such as product specifications, user tools, or plans for future development) they require.

Meet with team members and thank them for their efforts. Let them know that the stakeholder, sponsors, and others are pleased with the job they have done. Also, thank vendors and others who were integral to the success of your project. Make sure everyone knows the project is indeed officially over, for better or worse.

Reassign team members. If you own your own business and the team was made up of employees, you will need to either assign them to a new project, move them into operations resulting from the project, or have them return to doing their original jobs. Let people know what they should do next.

Return all tools, equipment, or anything you borrowed to its rightful owner. If you purchased equipment for the project, decide what to do with it. Often, when people leave a project, a lot of stuff is left behind. You need to clean up the mess and determine what is necessary for project maintenance and standard operations, and what was part of the project phase only. Can this equipment be used on future projects? On occasion, tools and equipment have been known to grow legs as the pr oject winds down keep tabs on resources and equipment. If you do have some dispensable goods, give them away to team members.

If the project was a success, celebrate! Sometimes, even a failed project is cause for celebration, recognition, and appreciation. Successful and unsuccessful projects need to shut down in a similar manner; however, on projects that have failed, there are a few additional considerations:

You may have a hard time convincing stakeholders that the project is indeed over. Many hopeless projects linger on indefinitely because one or more of the stakeholders do not want to accept that the end has come. You will have less celebrating and more consoling to do, since team members may feel frustrated or disappointed. You need to encourage team members to focus on how much was accomplished and what everyone learned. Do not rehash mistakes or lay blame; acknowledge that sometimes that's the way things work out.

It may take longer to close the books, since there may be outstanding or irreconcilable bills. Set up a time frame in which to try to close the books. Depending on the project and the attitude of the team members, you may need to pay special attention to security issues.

A project may fail for many reasons. It is important that at some point the project failure is realized and accepted, and there is an official shutdown. This can take a long time if there are legal entanglements, but in most projects there is a need to acknowledge that, at some point, it may indeed be over, even if you believe in your heart it shouldn't be. And then there are projects that end while you're still going strong. All appears to be going well, but management, for whatever reason, decides to pull the plug. Team members are especially let down when a project ends abruptly, because it means the rug is pulled out from under them. Sometimes there are warning signs, but not always. Businesses move quickly and changes are made in the course of a few days or even a few hours. A sudden shutdown is never easy, and sometimes the only way to deal with it is to pick yourself up as soon as possible and move on. Console and comfort others who are likely as shocked and angered as you are. Even in this scenario, you are often expected to tidy up a bit. The team will be gone, but as a leader, you may have to straighten out loose ends. If you are no longer on the payroll, you are in a good position to negotiate a deal to do whatever is asked of you at this point, but be sure to get it in writing.

Be sure to get necessary information from temporary or contracted team members, including their computer passwords and file locations. If team members will no longer be around after the project ends, don't forget company badges, security cards, and office keys. If you don't have a formal exit interview process, arrange an informal meeting to give and receive feedback and collect company property.

10 ways to get a slipping project back on track

Plenty of things can derail a project plan: underestimated tasks, departing staff, misallocated resources. Here are some practical techniques that can correct the direction of a project that's losing ground.
Plenty of things can derail a project plan: underestimated tasks, departing staff, misallocated resources. Here are some practical techniques that can correct the direction of a project that's losing ground.

Anyone who's worked on project teams knows that a variety of factors can move a project past its deadline. It's not uncommon for some of the work to be harder than originally anticipated or to have

turnover on the project that requires you to bring new people up to speed. Sometimes you discover that activities were simply underestimated.Regardless of how it happens, many times you'll find that you're trending beyond your committed deadline date. If you discover that happening, your first obligation as the project manager is to try to determine the cause. If you look for remedies without knowing the cause, the situation will probably recur. Your second task is to try to make corrections that will get the project back on track.At the beginning of a long project, you have many options to solve your problem. But toward the end, your choices dwindle. Look at this list of techniques and see which ones can be applied to your situation. Note that this list is not prioritized. Some of the techniques may work in one instance, while others could be applied better in another situation.This information is based on the articles "Correct your off-schedule project with these techniques," and "Apply these techniques to get your project back on schedule," by Tom Mochal. It's also available as a PDF download.

#1: Work overtime

Everyone hates it, but one logical place to start is with overtime. If people work more hours, they can get more work done in the same amount of calendar time. Overtime may be the best option if you're close to the end of the project and just need a final push to get everything done on schedule. If you're toward the end of the project, you also may be able to issue comp time after the project is completed. If you're still early in the project, there are probably more effective strategies. This option may also have cost implications if you need to have contract resources work overtime.

#2: Reallocate resources

The project manager must first understand what activities are considered most vital to the project's success, or on the "critical path." After all, if the project is trending over deadline, by definition it is the critical path that's late. Once you understand the critical path, see if resources can be moved from other activities to help resolve the issue. This will allow you to get the project back on track by delaying or stretching out some work. Be careful, though: Delaying some work may end up changing the critical path. Always make sure you double-check the critical path each time you change the schedule.

#3: Double-check all dependencies

Schedule dependencies represent activities that must be completed in a certain order. For example, if you're building a house, you cannot start putting up the frame until the foundation is poured and dried. If you're trending over your deadline, you should revalidate dependencies, since it's possible that the schedule is being lengthened by invalid dependencies between activities. Invalid dependencies may make it appear that activities must be performed sequentially, when they can really be done in parallel. Sometimes the scheduling software accidentally adds a dependency. Sometimes the project manager adds the dependency but on later review decides it doesn't really exist. It might make sense to have the team members review the schedule to see if they find dependencies that the project manager thinks are valid, but that they know to be invalid. Check all dependencies to make sure you have all your facts correct before you move into more drastic measures to bring the project back on schedule.

#4: Check time-constrained activities

Time-constrained activities are those with durations that don't change based on the number of resources applied. For example, you may be allocating team members to a five-day class. The class takes five days if one person attends, and it takes five days if 10 people attend. Check all of these time-constrained activities to validate the timeframe. Perhaps you're making assumptions that could be changed with a different approach. For instance, if you allocated three days for a contract to reach a client, perhaps the time could be reduced to one day by paying more for overnight delivery.

#5: Swap resources

I mentioned that the first thing to do when you're trending over your schedule is to determine the cause. One cause you may find is that you have one or more resources that aren't as productive as you planned. Perhaps certain team members don't have the right skills. Perhaps they aren't as productive in this particular area as they are in other areas. Regardless, there may be opportunities to replace resources. In some instances, you can simply swap people who are working on different activities within your project. Other times, you may release a team member and bring in another person. Remember that the activities on the critical path are key. You may have options to assign a more productive resource to those activities, while reassigning a less productive resource to noncritical path activities. If the activities off the critical path are delayed, you may still be okay in terms of meeting your overall project deadline.

#6: Crash the schedule

Crashing the schedule means applying additional resources to the critical path, the sequence of activities that must be completed on schedule for the entire project to be completed on schedule. It's always possible to just throw more resources on the critical path, but crashing also means you try to get the biggest schedule gain for the least amount of incremental costs. For example, if one person were assigned to complete an activity in 10 days, you could see whether two people could complete it earlier. If two resources can complete the activity in five days, you may not be adding any incremental cost to the project, since you're applying twice the resources for half the time. In another example, if two people can complete the work in six days, you will have accelerated the schedule at an incremental cost of two workdays (two people for six days vs. the original 10-day estimate). In this example, you could further crash the schedule by applying three resources. Perhaps then the activity would take four days, or four and a half days. Typically, the more resources you throw on an activity, the more the incremental cost will be and the less incremental timesavings you will receive. The additional resources may come from within the project team or they may be loaned temporarily from outside the team. One of the goals of crashing the schedule is to minimize the incremental cost. However, crashing -- in exchange for completing some work ahead of schedule -- usually leads to some incremental cost increase to the project. If cost is not as important as the deadline, crashing a set of activities can result in accelerating the schedule.

#7: Fast track it

Fast track means that you look at activities that are normally done in sequence and assign them totally or partially in parallel. Back to our home-building example, you can't construct the frame until the foundation is dry. However, if the house is large enough, you may have options to fast track by starting to erect the frame on the side of the home where the foundation was poured first. The foundation will start to harden there and might allow you to erect the frame on that side, while the foundation on the far side of the home is still drying. Another example involves designing an IT application. Normally, you wouldn't start constructing a solution until the design was completed. However, if you were fast tracking, you would start constructing the solution in areas where you felt the design was pretty solid without waiting for the entire design to be completed. Fast tracking usually involves risk that could lead to increased cost and some rework later. For instance, in our example of designing and constructing an application, it's possible that the design might change before it is finalized, and those final changes may result in having to redo some of the work already under way.

#8: Prevent all scope change

Many projects begin to trend over their deadline because they are doing more work than they originally committed to. This could be a result of poor scope change management or it could be that small changes are being worked in under the radar screen. If you're at risk of missing your deadline date, as the project manager you must work with the client and team members to ensure that absolutely no unplanned work is being requested or worked on, even if it's just one hour. All energy should go into accelerating the agreed-to core work.

#9: Improve processes

When you look at the cause for the project trending over schedule, you may find that some of the internal work processes could be improved. Solicit team member feedback and look for ways that are within your team's internal control to streamline processes. For instance, perhaps you have a daily status meeting that is not providing value and that can be scaled back to once per week. You may also find bottlenecks in getting deliverables approved. If you discover delays caused by external processes, try to negotiate changes to the processes going forward, at least on a temporary basis. For example, you may find that activities are being delayed because people need to work on their yearly performance reviews. While these are important, perhaps the timing of completing the reviews can be changed to allow critical project activities to be completed on schedule.

#10: Scale back the scope of work

One option that is usually available is to look at the work remaining and negotiate with the client to remove some of it from the project. If you think some of the remaining work is not core to the project, you could discuss eliminating it quickly. If the remaining work is all core to the solution, this discussion still might need to take place as a last resort. It may be an option to complete this project on time with less than 100 percent functionality and then execute a follow-up project to complete the remaining requirements.

Determining priorities
I've pointed out 10 areas to examine if you're behind schedule. Obviously, one solution is just to deliver the work at a later date. In some cases, that may be perfectly acceptable. However, the assumption here is that the scheduled completion date is important to the client. Some of these techniques don't require any incremental budget. You should look at them first, if possible. Other techniques to accelerate the schedule will result in increased cost to the project. If the deadline date is more important than costs, these techniques should be applied next. If the deadline date is extremely important and you can't move the schedule or the budget, there may be options associated with scaling back the scope of work. Usually you can complete less work faster. Once you know the cause of the problem and your budget flexibility, you can determine the best actions to undertake to get you back on track to hit your deadline.