Project Planning

Last week I started a series of posts that will carry over the next weeks focused on the project management framework (PMF) and it’s various phases. For my first post in this series, The Project Failed…We Haven’t Started!, I began in the Initiation Phase of the PMF and primarily focused on the Project Charter. I understand the elements laid out in that post may not fit every project or the state of maturity your project is at , but I am confident that the more comprehensive you can make that charter, the better your chances are for success. I also realize there are other factors that are important during that phase of the PMF, such as stakeholder identification/analysis, feasibility studies, etc.

As with that post, I realize that the next stage/phase in the PMF, Planning, has several key activities and outputs for a thorough planning phase. However, I am only going to focus on a few and then look forward to your comments on those you may feel should be included in the list.  As with my other posts, I have added a video to the right that brings an interesting twist to the topic.  This week’s video, Monty Python’s Bridge of Death, was used by a mentor of mine to explain how project requirements need to be solid and understood.  If not, they can easily change and cause matter how simple the change may be.  Enjoy the video and here we go…

Requirements Gathering: One of the most frustrating aspects of project management comes down to requirements…for me. It seems like such a simple exercise to me, yet it seems to conjure every bit of energy I have and taps into every aspect of management/leadership/soft-skills I have…time management, conflict resolution, relationship building, coaching, etc. I would think the customer could tell me they want a red car, with four doors, with x air bags, 34 mpg, etc. Not the case! One Product Manager I worked with used to tell me…”We need to sell the dream Robert”. I used to tell him that if he could describe the dream, I will get the team to create it. The only thing more frustrating then ‘drawing’ the requirements out is the fact that once the project has been chartered, the clock starts ticking with or without a set of requirements.

While the product design and vision seems like a customer ‘owned’ step, the Project Manager has really got to take this one by the horns and facilitate this process. Detailed, measurable requirements are the key to limiting re-work, missed customer needs, incorrect time and money estimates, etc. In my experience, the PM is going to have to learn the market trends and competitions to at least be able to ask the questions and provide some illustration to draw out the customer’s requirements. The PM is going to have to pull in the right people from a cross-functional perspective as to get different view points during this phase. What are the thoughts from IT? Does legal have any compliance questions? What about tax and treasury…will the new business (service/product) fit into the current tax strategy? If you are going to list these requirements and be responsible for delivering those requirements, you better make sure they are achievable and measurable.

Some of the common techniques (Interviewing, Storyboarding, etc) can be found in this blog by Dave Nielson at The Project Management Hut.

Forming the Team: According to the PMI and their PMBOK 4th Edition they refer to Bruce Tuckman’s theory that all teams will go through 5 stages of development.

  1. Forming – This is where the team is first coming together and learning about the project. Leadership and vision is very crucial at this point.
  2. Storming – As the vision starts to come together, some cliques may form and other team members begin to jockey for position/power. The PM needs to keep the team focused on the project goals, maintain an environment of collaboration, and get the progress going.
  3. Norming – The team should be a more cohesive group, working together as a team to resolve issues and make decisions. Team gatherings and trust picks up.
  4. Performing – The leader has done a good job at setting the vision, facilitating the relationships, and setting tone with regards to the project approach and strategic fit of the project. This allows the team to move into a more stand-alone unit that can operate with less hands-on direction from the PM.
  5. Adjourning – The work is completed and the teams move on to other initiatives.

Risk Analysis/Plan: With a comprehensive Project Charter, Stakeholder Register, and detailed requirements in-hand you can now perform a proper risk analysis and develop the risk plan for the project. The Project Charter is going to let you know when the business/customer wants the service/product to hit the market, the potential budget cap, and other restrictions and/or assumptions that could create a risk. The Stakeholder register is going to let you know who could provide some valuable input to potential risks or the mitigation strategies to place in the plan.

As you identify risks you need to place them in a measurable format so that you can track them, provide the right focus, and assign appropriate resources.  The best way to do this, is to score the likelihood of the event happening and the impact it will have if it were to occur.  Then you need to provide a priority ‘score’ by adding the likelihood and impact scores, then divide that by 2. With the risks numbered and awarded a priority score, you can then begin to develop risk reduction strategies (reduce likelihood) and risk mitigation strategies (if event occurs, what to do).



Very Low 20 Very Low 20 Very Low >20
Low 40 Low 40 Low 21 – 40
Medium 60 Medium 60 Medium 41 – 60
High 80 High 80 High 61 – 80
Very High 100 Very High 100 Very High 81 – 100

Example: Meet Project Schedule, Likelihood = 60, Impact = 100. Priority = 60+100/2  or 80 (High)

There are some other obvious activities in this phase such as developing the project schedule (MS Project), developing the budget, and creating a communications plan but those can be entire posts by themselves.  For now, I am going to hold to the 3 areas above and look forward to your feedback and additions.

Additional Resources:

25 Ways to Motivate Your Teams

When Your Customer Doesn’t Know What They Want

10 Golden Rules of Project Risk Management


3 thoughts on “Project Planning

  1. Very good and interesting post.
    I encourage you to keep doing/feed such on-line documentation that I find interesting as it is based on real experiences on the field beside formal theoretical knowledge.
    Well done,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s