Project Planning Part I

project planning

“Everyone has a plan, until they get punched in the face. Mike Tyson”

Mike Tyson knows a thing or two about getting punched in the face, or more like punching others in the face. You are probably wondering why is it that I am using the analogy of face punching on the topic of Project Planning. The point here is about adjustment and adaptability. We can do all the Project Planning in the world to ensure success, but one of the core components of that success is your ability to adapt when things change. Indeed, we Plan the Work and then Work the Plan, and this is the most engaging stage of the entire project management lifecycle, but don’t get too caught up in the Project Planning. This section focuses on the key activities, skills required and tools used during the Planning phase.

Project Planning phase should solve the main fundamentals:

  • Define the Scope
  • Determine Project Objectives
  • Identify Stakeholders

Define Project Scope

Scope definition is all about identifying the main problem that we are looking to solve as part of this project. Whether you are a newly appointed Project Manager for a new project or you are inheriting a project, it is important to address the main problem that is being solved on this project. Problem definition statement activity should happen between the Project Manager, Project Sponsor/Owner and any other key stakeholders.  “Our Customer Service Department is experiencing a high volume of dropped calls” or “Product enhancements delivery to the client needs to be faster” are some of the examples of statements that you can expect to hear from your Sponsor. Before you jump straight into designing or looking for new software to solve these issues, perhaps it is necessary to analyze the underlying issue of employee training, motivation, review internal processes and procedures, etc. As a Project Manager, you will constantly perform the balancing act between the three parts of the “iron triangle” (scope, time, cost), and it will become your responsibility to protect the scope that was agreed upon initially.

Changes are inevitable, and at times they are much needed. Scope and requirements changes will be requested from your stakeholders, customers, end users and even your own project team members. Ultimately, it is the responsibility of the Project Manager to protect the scope of the project. Gaining consensus is more about making sure that the sponsor and the stakeholders are fully aware of the requested changes and their impact on the other parameters of the triple constraint (cost and schedule).

Project Charter is at the core of this stage. There are plenty of various versions of this document and most likely your organization already has an adopted template. For the purposes of the fundamentals and for those are relatively new to their roles as Project Managers, let’s take a quick look at one of the versions of the Project Charter:

Think of a Project Charter as your initial draft agreement with the Sponsor. This document will include high level information about the overall project. Here are some of the key aspects that shall be covered:

  • High Level Scope
    • Example: The scope of this project is to implement Slack (Communications Software based on hashtags) into Marketing Department as the primary tool for internal communications
    • It is a good practice to include any ‘out of scope’ items in this section as well. In this scenario an example would be: implementation of Slack will not replace email communication as Phase I; this implementation does not impact other departments
  • Proposed Timeline
    • Sponsor(s), who approves the project, has a target timeline for this initiative and it needs to be included in the Charter with a caveat that this is a proposed timeline and subject to change
  • Benefits & KPIs
    • This section of the Project Charter needs to spell out the primary benefits from completing this project and the reasons why it was initiated
    • Success measures and acceptance criteria also needs to be considered to include high level metrics for how the overall success of the project will be measured
  • Constraints and Assumptions
    • Any limitations or potential restrictions should be part of this section of the Charter. Examples of such constraints could be limited budget, dependencies on other technologies, lack of resources
    • Assumptions shall be kept at the high level and include some of the items that we, as a project team, do not know if it is true at the moment
      • Example: Slack software may not be compatible with the existing email provider
    • High Level Budget
      • Include pertinent information about the approved Project budget
    • Project Resources
      • This is the section to include the resources needed for your project team. For the purposes of the Project Charter, this section can be kept at high level as you will be putting together a detailed Roles and Responsibilities document to identify all key players and their responsibilities

Once the Project Charter draft is ready, you should have a final review of it with the Project Sponsor, agree upon the main components and determine the next steps.

Part II of the Planning Stage to be posted soon. Stay tuned and don’t forget to sign up to stay updated.

Comments