stakeholder managementAs we understand from project management basics section, a stakeholder is defined as “an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project”.

Thus stakeholder is anyone – customer, sponsor, team member, CEO, end user, neighbor – basically anyone who can impact the project or whose interests are positively or negatively impacted by the project.

Per the definition, a stakeholder can be someone that may just think that they are affected by your project. So, in real life managing stakeholders is not an easy job for the project manager, and it starts with identifying them!

This knowledge domain stresses on continuous communication with stakeholders to understand their concerns, interests, and issues, and managing any conflicts that may arise. Managing stakeholders, making them happy (or at least not mad) is, as many project managers concur, one of the most important part of their job. After all, the project exists for and because of stakeholders!

[continue reading…]

Plan Cost ManagementCost management planning activity defines policies and procedures to plan, manage and control costs on the project. This helps you create the Cost Management plan, which is part of the Project Management plan.

This is not a process that is often executed, once at the beginning of the planning phase of the project and then at preplanned intervals such as the beginning of a new phase.

What do you need to create the Cost Management Plan?

In order to estimate costs you need to know how schedule and risks are managed on the project. Simply because schedule and risks are two areas that can shoot your project costs out of the roof if not managed properly.

The 2 documents that tell you how they are managed – that is, schedule management plan and the risk management plan – are part of the Project management plan.

The information used from these are – scope baseline and schedule baselines primarily, and then other relevant information such as risks and communication needs related to cost management.

Project charter contains summary budget information and budget approval needs which are essential.

Apart from these, you’ll also be referring to the published industry specific labor rates, project management information systems, and lessons learned while managing costs in other earlier projects, any templates and policies governing cost management specific to the organization, financial knowledge bases and so on.

If your costs are based on procurement from vendors and suppliers, the type of contract you’ll have with them will also have a bearing on your overall cost planning. Plus, if there are imports involved then currency fluctuation is something to be considered as well.

These are all part of EEF and OPA. [continue reading…]

plan schedule managementMany people confuse project schedule with project plan. This is a common perception because many people look at a Gantt chart and think that they are looking at the project plan.

Right off the bat let me tell you that this is NOT about creating project management plan. You can learn how to create a project management plan, here.

Project schedule is in fact part of project management plan.

So far we have seen how we collect requirements, and from those requirements we define project scope. Then we break down this scope into high level logical chunks of features called Work Breakdown Structure.

Now is the time to estimate how long the project takes and in what sequence we shall execute various project requirements. The project Schedule is all about How and When of the project work.

This process, Plan Schedule Management is about outlining processes, procedures, and policies to come up with a project schedule and manage changes to it. The focus of this is to sensitize project managers to the right way of approaching schedule creation.

Schedule management plan is a subsidiary plan and an integral part of the project management plan.

[continue reading…]

difference between Requirements and ScopeWhat is the difference between Requirements and Scope?

This question may confuse people even after working in the project management role for years. We have an elaborate process where requirements are collected using various tools and techniques, but why is there another process that talks about scope?

The difference is simple.

Requirements define the product behavior. They indicate what is that users want from the product.

A carpenter needs to be able to drill 2-inch holes. This is the requirement. He needs a drill-bit that can drill 2-inch holes.

Scope indicates the activities that need to be done in order to achieve the requirements.

Scope is about figuring out what material and process goes into creating the drill-bit that has a diameter of 2-inches, and the acceptable tolerance limits. 

Scope can achieve partial set of requirements when the requirements are implemented across multiple phases or iterations (if you are using Agile methodology) by scoping part of requirements in each phase/iteration. [continue reading…]

plan scope managementYou would have noticed that Scope management processes have two distinct words – requirements and scope – as in Collect Requirements and Define Scope.

What is the difference between Requirements and Scope?

While there is a short lesson on this for now think of it as ‘business requirements’ and ‘project scope’.

Does it make sense?

Well, Requirements are capabilities that are required to be present in the product, service or result that project is supposed to produce in order to satisfy a formal agreement (which could be a Contract). Whereas Scope consists of the activities that need to be done in order to achieve the requirements.

In short, requirement is outward facing – specified by customer/business; and scope is inward facing – to be provided by the project. You understand customer’s business requirements and turn them into project scope. This means that we derive scope from requirements.

That is why after collecting requirements we define the scope of the project (PMI defines these two processes in this order). However, in strict practical sense these processes overlap in ways that is unique for the project.

Planning for managing project scope involves creating a plan that outlines how scope is to be defined, controlled and managed throughout the project.

requirements scope wbs activities

Figure: Flow from requirements to scope to WBS to activities

Stakeholders provide requirements, which are turned into project scope, which further are divided into Work Breakdown Structure (WBS), which them are broken down further into activities. Project Scope Management knowledge area covers the flow till WBS.

You would need project management plan (with their subsidiary plans) and Project charter (contains high-level business needs giving you some sort of context to help come up with scope creation and management plan). Apart from these you can make use of available templates from older similar projects in the organization.

One of the ways to create scope management plan is by involving experts in the organization, or outside the organization. These people have the necessary knowledge, experience and foresight to guide you about the approach.

You would meet with senior team members, project sponsor, people from Project Management Office (PMO) and customer will help understand more about product and project scope, the challenges involved in collecting and managing them.

This project management activity produces a plan to collect and manage, and then control changes to project scope.

This plan describes the approach to be used to define detailed scope, to create Work Breakdown Structure. It also describes the process to validate scope with the customer and the techniques to control scope so that unwanted features do not get into the product.

This project management exercise produces another plan apart from the Scope management plan. That is, the Requirements management plan.

What is Requirements Management Plan?

It is important to outline which of the tools and techniques are used for the current project to collect business requirements. It is also necessary to outline how they these requirements are documented, analyzed and how changes are authorized, managed and communicated to stakeholders throughout the project.

If project is planned to be performed in phases as discussed in an earlier lesson, the relationship between phases also determines how requirements are managed. The level of detailing to be done upfront might be less if phases are iterative than if phases are sequential.

All this information is captured in a document called requirements management plan. This document also captures the process by which requirements are prioritized, and traced to deliverables.

Before we move onto the next process in Scope management knowledge area, let us look at two possibilities you should know about that is going to help you manage project scope much better!

PMBOK5 changesOn 1 August 2013 PMP® exam moves over to using PMBOK® 5th edition. As with any new thing, you might be feeling bit jittery about PMBOK 5th edition changes. I know I did. But you are in for a pleasant surprise!

The good news is that you are going to love the changes. I promise.

Let me show you why.

For one, PMBOK® 5 brings in clarity in lot of areas. The structure is more streamlined, clear and consistent. For instance, ALL of the knowledge areas now follow the pattern “Plan {KA} Management” for first planning process. This makes it easy to remember the process names.

Download this pdf describing changes to PMBOK 5th edition here.

[continue reading…]