Project Management Knowledge Areas and starting the Planning Process
This item identifies the Project Management Institute’s (PMI) project knowledge areas and discusses the first step in the project planning process.
Following the sanctioning of a project proposition and the preparation and issue of an unambiguous Project Charter we project managers then need to plan the execution of our project to achieve the goal, as per objectives, constraints and other information given in the approved Project Charter, which remains our authority and reference point throughout the project life cycle. The resultant Project Plan is a formal, approved document used to guide project execution. It’s a road map that shows how to initiate, sustain and terminate our project. It records planning assumptions and decisions, reduces uncertainty, facilitates communication among stakeholders, and documents approved scope, cost, and schedule baselines. We project managers create the Project Plan to comply with the information given in the Project Charter with input as appropriate from our project team members and other key stakeholders. The benefits of planning should be obvious, but real-world pressures and an anxiety to “get on with the job” may have us overlook the following benefits of planning:
- It forces us to think through our entire project.
- It provides a common understanding of how the project is to be implemented.
- It is the best defence against unrealistic time and cost objectives.
- It allows for best use of scarce resources.
- It provides a basis against which to track progress and make corrections.
If during this planning process we find that the goal is unobtainable within the given constraints, particularly spending limits, it’s back to the sponsor with suggested solutions – essential options being more money, less scope (fewer features and functions), reduced quality, or some combination of these possibilities. Once completed, our baseline plan needs to be approved by our project sponsor before it is implemented. Of course, this baseline plan is a basis for change. As with the Project Charter, the Project Plan may need to be updated as realities emerge, recognising that no project is better than its plan and things do change.
Project planning need not be scary. It is a very natural process. Every day we all make lots of little plans (such as, what we will watch on TV tonight, what we will do during the weekend, what we will have for dinner, where we will go on holiday, and so on). The process is so natural that we probably don’t even think of it as planning. The fact is though, we all plan all of the time and are (on the whole) rather good at it. As a project manager we are responsible for our Project Plan. This does not mean we need to prepare it in isolation, far from it. It’s therefore helpful to hold a workshop to get others’ planning input. One approach to save time is to for us project managers to prepare a draft Project Plan as a basis for discussion. Such a plan is sometimes called a “straw man” or “Aunt Sally” (with reference to a traditional English fairground game in which objects are thrown at a figure in an attempt to knock it down) designed to generate discussion and provoke new ideas and eventually produce a final plan or “concrete man.”
This planning process is not a one-off effort, but is continuous throughout our project life cycle. So no project plan is really a “concrete man.” The plan changes as the project progresses. As I mentioned above, doubtlessly, things will happen during the project that will force us to make controlled changes. No plan is likely to survive in its original form from the start of the project to the finish or as German military strategist Helmuth von Moltke put it – “No battle plan survives contact with the enemy.” When our plan meets the real world, the real world always wins. Thus, despite our best efforts to keep on track, sometimes we need to build a new track.
The project plan tells us how the project goal is to be achieved and of course the clearer this goal is the greater chance we have of hitting it. The most useful project goal complies with “SMART” criteria – it is specific, measurable, agreed, realistic and time-bound, to which I would add clear, concise and written-down, but not so concise that it is ambiguous or otherwise unclear or incomplete. Kipling may not have been a project manager, but he had the right idea. In essence, the planning process reuires we address Kipling’s six basic questions:
- Why? What is the problem or value proposition addressed by the project? Why is it being sponsored?
- What? What is the project goal and work that will need to be performed on the project to achieve that goal? What are the major products or deliverables?
- Who? Who will be involved and what will be their responsibilities within the project?
- When? What tasks will be performed when?
- Where? Where will the project work be undertaken?
- How? What project management methodology will be applied?
In practise, the project plan covers the ten PMBOK topics or knowledge areas, which provide a useful checklist for planning, periodic project management reviews, and for final project evaluation, although not necessarily applied in the following sequence:
Project Integration Management. This knowledge area is concerned with integrating the other nine knowledge areas as appropriate. It also includes managing issues and change, and re-planning as required. There are two main tools associated with this process – Earned Value Management (EVM) and the use of project management software. This knowledge area consists of six processes:
- Develop project charter
- Develop project management plan
- Direct and manage project execution
- Monitor and control project work
- Perform Integrated change control
- Close project or phase.
Project Scope management. There are two aspects to scope management; one is product scope and the other is project scope. Product scope covers the what – required features and functions that characterise the deliverable, whereas project scope is concerned with the how – the work needed to achieve the project scope, and again clarifies the boundaries of what is and is not included in the project. Project scope management includes five processes:
- Collect Requirements
- Define Scope
- Create WBS
- Verify Scope
- Control Scope.
Project Time Management. This knowledge area is not about our personal time management, although that is very important, but is about estimating task durations, determining the project schedule and project completion date. It also includes monitoring and controlling a project schedule throughout the project. This knowledge area has six processes:
- Define Activities
- Sequence Activities
- Estimate Activity Resources
- Estimate Activity Durations
- Develop Schedule
- Control Schedule.
Project Cost Management. This knowledge area is about estimating the resources required, and determine the project budget. Resource costing is not just about people. It also includes other types of resource such as materials, plant, equipment, facilities and project related services such as letting contracts. This knowledge areas has three key processes:
- Estimate Costs
- Determine Budget
- Control Costs
Project Quality Management. This knowledge areas concerns creating the deliverable to an acceptable standard of functionality and performance as set out in a product specification, and the quality of the project management process itself. There are three processes:
- Plan Quality
- Perform Quality Assurance
- Perform Quality Control
Project Human Resource Management. This knowledge area is to do with managing people. It includes aspects such as acquiring the team, developing the team, and then managing their performance through performance appraisals, motivation, delegation, leading and coaching, and resolving human resource issues. The objective here is to ensure that all human resources are used efficiently and effectively. This knowledge area contains four processes:
- Develop Human Resource Plan
- Acquire Project Team
- Develop Project Team
- Manage Project Team
Project Communications Management. Communications is not just the face-to-face human variety, but includes meetings management, project plans, reports, reviews and walk-throughs, etc. This information must be shared with all of the project stakeholders — both internal and external to the project. The communications plan should document these aspects, and along with other documents, be reviewed and updated as needed. This knowledge area contains five processes:
- Identify Stakeholders
- Plan Communications
- Distribute Information
- Manage Stakeholder Expectations
- Report Performance.
Project Risk Management. Contemporary thinking is that risks include both threats and opportunities. An opportunity should also be seen as a type of risk because like a threat, an opportunity has uncertainty. Threats should be reduced or removed. By the same token, opportunities should be exploited. This knowledge areas contains six processes:
- Plan Risk Management
- Identify Risks
- Perform Qualitative Risk Analysis
- Perform Quantitative Risk Analysis
- Plan Risk Responses
- Monitor and Control Risks.
Project Procurement Management. Most projects work within a customer and contractor environment. Generally, the project team is working on behalf of the customer, and contractors provide expertise, materials, equipment and components. Project Procurement is used when it is necessary to purchase or acquire products and services from outside the project team. This knowledge area focuses on contract management and contains four processes:
- Plan Procurements
- Conduct Procurements
- Administer Procurements
- Close Procurements.
Project Stakeholder Management. This is the latest knowledge area to be formally recognised and appropriately so given that project success is nowadays often described as happy stakeholders. Stakeholders are groups and/or individuals who may affect and/or be affected by the project. The project manager is responsible for analysing, engaging and managing the various stakeholders in the project. This is a continuous process throughout the project lifecycle, with the objective of stakeholder satisfaction and contains four processes:
- Identify Stakeholders
- Plan Stakeholder Management
- Manage Stakeholder Engagement
- Control Stakeholder Engagement.
Further information about these ten knowledge areas and their processes is contained in the PMI PMBOK Edition 5 publication, which can be purchased at www.pmi.org. The 1996 version is here. Or go to http://edward-designer.com/web/introduction-to-pmbok-guide-knowledge-areas-processes-process-groups/.
A format or template for our project plan is contained in “The Framework” at appendix eight, which is that used as a guide for NZIM Diploma in Project Management assignments.
Producing the plan is of course a challenge. Once we have a Project Charter we might typically assemble our planning team and other stakeholders as appropriate. At this point it is useful to have the project sponsor and ourselves as project manager talk through and discuss the Project Charter with the team to ensure we all have a clear and common understanding about the project we’re about to plan.
Another useful practice at this kick-off meeting is to develop a Team Charter – agreed rules to govern our behaviour and performance. The format for a Team Charter varies from project to project and from team to team. And while the Team Charter can take on many forms, much of the value of the Team Charter comes from thinking through, discussing and agreeing the various elements. Possible topics for this meeting and our Team Charter are these:
- Health and safety
- Conflict resolution
- Workload distribution
- Work periods and timings
- Internal and external communications
- Team membership changes
- Performance reviews
- Public relations
- Confidentiality issues
Once our Team Charter is complete, every team member might sign it. We may be tempted to skip this signing bit, but it’s important. The act of signing the charter helps each of the team members commit to the agreed items. Once signed and published, we need to adhere to these guidelines and any subsequent amendments. This first team get-together is also an opportunity for some teambuilding activity – probably not abseiling, but perhaps a barbeque where team members can get to know each other in a relaxed environment. If nothing else, this will help people put names to faces, which is particularly helpful if the team is dispersed during project execution.
Once the planning team understands the Project Charter and has prepared a Team Charter, we identify the work that needs to be done to achieve the project goal given whatever objectives and constraints have been set. The deliverable from this first planning step is the project Work Breakdown Structure (WBS). A good way to identify this work scope is to write the project goal in the centre of a large whiteboard and though team brainstorming record in mind-map fashion all the work elements needed to realise the goal. To create the WBS ask the question “What will need to be done to achieve this goal?” By asking this question over and over for each work chunk, we eventually create a detailed breakdown. Since brainstorming is a non-critical process, the resultant map needs to be critically reviewed to remove out-of-scope activities and duplications, and combine or expand work elements as necessary to eventually produce an initial WBS – essentially a family tree of work chunks to which we might then assign code numbers for easy reference. Here is a WBS in indented list format, rather than family tree or graphical format, that shows the work needed for a home landscape project.
These work chunks are typically expressed in “verb-noun” format, such as “Dig Trenches” given that they are tasks that will eventually need to be delegated or contracted out for completion. In this example the deliverable is the completed “Home Landscape” and an “event” in project management lingo would be “Trenches Dug” that might later be designated as a “milestone” – the start or finish of a key task. Incidentally, a WBS is not a project plan, a schedule or a chronological listing. It simple shows what work is to be done, but not how or when. The above example shows up to four levels of breakdown, the lowest level consisting of “verb-noun” work packages (or terminal elements) and the other levels consist of summary tasks. Incidentally, summary tasks are not executed; rather they simply summarise the subordinate work packages.
This breakdown allows us to prepare a bottom-up budget and then a network diagram and Gantt chart. How far we break down the work is mostly a function of project size, and what constitutes a delegation-size chunk of work, but we might also limit work package sizes to allow for better control. For example, if ours is a time-driven project, we might decide that no work package will exceed say three days’ duration. For a cost-driven project we might limit work packages to say $3,000 in order we can carefully track expenditure.
A useful WBS shows small discrete pieces of work, that we can measure progress against on a regular, perhaps weekly, basis. It allows progress to be quantified. Here are some further thoughts about the WBS:
- It is a means for dividing our project into easily managed increments (work packages that are essentially smaller projects) that are assignable and for which accountability can be expected.
- The WBS helps ensure better control, allows for delegation of coherent work packages, enables work to be defined at the right level for estimating purposes, and enables risk to be contained.
- Start WBS development with the top-down tasks and then work downward, and ensure that every piece of work has a descriptive name that includes a noun and a verb. There need not be a uniform level of breakdown.
- While each project is unique, a previous WBS could be a useful start point for a comparable project.
- Ensure our project management tasks are included in the WBS so that their costs are included in the project budget. A common alternative is to include a project management overhead of perhaps 10-15% in the budget.
- During the process of the developing the WBS some assumptions may be needed. If so, these are often best expressed as risks and assessed and responded to as such.
- When developing our WBS resist breaking work down too far such that we are telling people who will do the work how it should be done. If a more detailed breakdown is required for more accurate costing and scheduling purposes, where practicable, we should involve those who will do the work in this WBS development process.
- If our project employs contractors to do some of the work, we can require a detailed WBS for their job part of their tender submission.
A WBS is not to be confused with a product breakdown structure (PBS) such as referred to in PRINCE2 methodology, which is a list or hierarchy of products (nouns) as in the example below, where end-products and intermediate-products are represented by rectangles, collective-groupings by rhomboids and externally-provided products by ovals. The preparation of a PBS allows us to prepare a Product Flow Diagram (PFD). While the PRINCE2 developers think the PBS and PFD are great tools, as a project manager I very much doubt their value and have never used them, mostly because they are unnecessarily complicated and of no real help, and unless converted to WBS format cannot be used with conventional scheduling software. I suspect that PRINCE2 developers were looking for some new and unique tools to help distinguish their methodology from other methodologies, which I guess they achieved with their PBS and PFD, and a lot of reinvented terminology. I’m a PRINCE2 practitioner and trainer, but frankly the only improvement I find that the methodology offers over most other methodologies is the attention given the project business case and benefit realisation, otherwise PRINCE2 is a bureaucratic nightmare that defies down-scaling for smaller projects, which of course most projects are. Sorry PRINCE2 advocates – had to say that.
For further information on the WBS and contents of a project plan and the steps involved that culminates in the project plan please refer to “The Framework.”