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.

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 don’t – 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 day’s 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 everyone’s 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.

Let’s say you are going on vacation, driving through an unfamiliar area. As you are tuning the radio to a local station, you hear that there’s a huge tie-up by Exit 11 of the route you’re 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.

That’s 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!

That’s 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:

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 project’s 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 year’s 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 authority’s 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."

"It’s 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 seat-of-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 let’s 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 don’t become a willing accomplice in jeopardizing your own project. Don't “go along to get along.” Resist organizational inertia and stick to your principles.

 Continue to next section:
Frequently Asked Questions