Control Scope

This is a simple process and exactly means what its title is, unlike Verify Scope. It requires the project manager to measure the scope of the project against scope baseline and keep a check on the scope performance using variance analysis. This process is closely linked with the Perform Integrated Change Control process. The project manager is required to be proactive in this process specially. He cannot just go on and accept all the changes requested by the stakeholders. He should control the scope by having all the change requests go through the change management process and only catering for the changes which are approved. The key to success of the project manager is how closely and keenly he monitors and controls the project scope. If you loose your grip on the scope, scope creep will occur and the project will go out of hands immediately and will end up violating all the baselines.

Verify Scope

The title of this process may be a bit confusing. It seems like as if it is instructing the project manager to verify the scope. Instead, it is instructing the project manager to GET the scope of the project verified BY the customer and to seek formal acceptance of deliverables FROM the customer. In fact, this process can alternatively be called “Get Scope Verified and Accepted” for a better understanding. It is relevant to mention here that Verify Scope process is very closely linked with Perform Quality Control process. In fact, most of the time, these two processes are done in parallel. While Verify Scope is related to the formal acceptance of deliverables by the customer, the Perform Quality Control is the process of ensuring that the deliverables conform to the scope and quality parameters set in the project plan by the quality control department, within the project team. This process is done multiple times with the customer to get formal acceptance of the deliverables. There is another point to note and remember; the Verify Scope process results in the acceptance of interim deliverables during the different phases of the project, whereas, the Close Project process results in getting the final acceptance of the project as a whole.

Create WBS (Work Breakdown Structure)

One of the most vital and useful tools used to manage the scope of the project is WBS. A project, big or small, will slip deadlines, will have scope creep and will be negatively impacted without the WBS. The WBS is produced from the scope statement of the project which we developed in the ‘define scope‘ process. It is imperative to know that the WBS is ‘What to do in the project’ or ‘deliverables’. It does not, I repeat, does not talk about ‘how to accomplish the tasks/deliverables’. As the name implicates, it is a process of breaking down work into smaller components. The process of this breaking down is known as decomposition.

A project is decomposed into tasks (deliverables), which are further decomposed into sub tasks and the process continues until a level is reached that the components you finally defined are detailed/decomposed enough to plan and manage the project successfully. These final components, which cannot be further decomposed, are called work packages. Generally tasks which are between 8 to 80 hours estimated duration, depending upon the size of the project, are the work packages. All the project estimation including schedule, cost, resources, etc. should ideally be done at the work package level to ensure that you have the best possible estimates to plan and manage your project. Another very important aspect of creating a WBS is that it is created with the help of the whole project team. This enables the whole team to get a fair idea about the overall picture and it helps in return to create a better project plan and to reduce risks caused by having a team which works in silos of their own specific tasks while not knowing the overall project objectives.

A WBS can be made in multiple ways. It can be a list, tabular or like a chart as shown in the picture above. The experience tells us that the method used in the picture above is the best and with the most successful results. The advantages of using such a method over having a list or tabular form are:

• The WBS chart ensures that nothing slips through the cracks as well as nothing is added into the chart after final approval thus minimizing the scope creep
• The WBS chart shows a complete hierarchy of the tasks (deliverables) and their interrelationships. This cannot be possible, on the other hand, by having a list

Some experts include points like i) lists are usually created by a single person so the team buy-in is not achieved with lists, ii) since lists are prepared by a single person, the team do not understand the project as a whole, etc. as the disadvantages of having a list, but I personally disagree with that. Even a group of people can give their inputs to prepare WBS in form of lists which can be merged together in a single list while everyone from the team is involved in this effort resulting in the team buy-in. Eventually, the chart is a much better option for creating a WBS for obvious reasons.

How it is done is that most commonly the title of the project is on the top of the WBS. The components in first level are mostly the different phases in the project like requirements collection, designing, development, testing, training, etc. These upper level deliverables are decomposed to smaller and more manageable deliverables in later levels until the team reaches appropriate level to estimate and manage properly. Just note that it is not necessary that all the branches of the WBS end at the same level. All the higher level deliverables are decomposed to number of levels as per their own complexity and type.

The WBS of one project created by multiple teams will be different from each other and that is perfectly alright as long as the following rules are followed while creating them (copied from RITA MULCAHY’s PMP Exam Prep book):

• The WBS is created with the help of the team
• The first level is completed before the project is decomposed further
• Each level of the WBS is a smaller piece of the level above
• Th entire project is included in each of the highest levels of the WBS
• The WBS includes on the deliverables which are really needed
• Deliverables not in the WBS are not part of the project

Another concept related to the WBS is control account. This term is generally used in the WBS created for large projects where you do not want to estimate down to the work package level rather you prefer to estimate them to a higher level in the WBS. This node in the WBS chart is called control account. It is mostly done in the deliverables which have been commonly delivered as part of previous projects and the team is well experienced about all the aspects related to estimating them in detail. So instead of wasting time in doing the whole exercise again and again, expert judgment is used and estimation is done at control accounts level for certain deliverables.

Once the process of creating WBS is completed, another output besides the WBS itself is WBS dictionary. This is a document which contains details of the work packages and control accounts. The details include information like the description of deliverable, acceptance criteria, assumptions, constraints, etc. Other fields like resources, duration, cost, schedule, etc. are added later when the estimation is done.

Another concept related to the WBS is scope baseline. Consider it to be the yardstick to measure the project’s performance during monitoring and control process group of project management. Project scope statement, the WBS and WBS dictionary combine together to form the scope baseline. The scope baseline, along with other baselines and management plans, becomes the part of the project management plan that is finally approved by the project sponsor.

Define Scope

We have successfully collected ‘most’ of the requirements in the Collect Requirements process. Somewhat similar information, but not detailed, is found in the project charter and assumptions and constraints defined in project scope statement. All this information is gathered together and after filtering it on the basis of what is and what is not included in the project, we get a detailed project scope.

An important think to know here is that project planning is an iterative process. The project team prepares the project baselines based on the requirements collected. These baselines are then presented to the project sponsor/customer and if any of the component is not accepted, the requirements and scope is adjusted/balanced accordingly to meet the sponsor/customer needs and other constraints of the project. This may involve different schedule compression techniques, budget and scope adjustments.

An important tool used in this process is called product analysis. The concept is that some legwork is done by the project team to define and determine project deliverables on their own also besides getting the list of deliverables from the sponsor/customer. This is done, not always though, to ensure that the sponsor/customer expectations are turned into a tangible deliverable. Once the project scope is defined in detail after this process, it may include:

• the scope
• deliverables
• what is NOT part of the project
• constraints and assumptions
• acceptance criteria

The project scope is the building block of the project and the success and failure of any project comes down to how well the scope statements is made.

Collect Requirements

This process is as important and vital for the whole project as laying a proper foundation is for the building. Weak or incomplete requirements collection results in a project finishing, if it finishes at all, with cost, scope and schedule much above the estimates and budget. All the subsequent processes in the planning phase depend upon the requirements collected at this point. Projects having properly documented and collected requirements have very high completion and success rate.The real success is to deliver the project within performance baselines, not just completing.

Although the high-level requirements are already mentioned in the project charter, this process involves gathering specific inputs and requirements from ALL stakeholders. This process is so critical that sometimes even a single missed requirement can result in a total project failure or at least can cause significant changes in the project. There are different ways of collecting the requirements, as per the circumstances and situations, which are briefly described below:

Interviewing: The project manager along with his team, business analysts mostly, conduct interviews with stakeholders to gather requirements for a specific element of the project. These interviews can be conducted individually or in a group. This technique helps in getting requirements specific to individual elements of the project and sometimes it becomes tedious to sort them out to ensure that there is no repetition.

Focus Groups: This is similar to conducting group interviews with the difference that individuals from the same field/department are gathered together so the discussion remains focused on a particular portion of the project. All the group members are ideally subject experts and share their opinions with each other. The focus groups are managed by a moderator, project manager or any of the project team member.

Facilitated Workshops: The stakeholder with different perspective about a particular element, e-g. designers and end users, are brought together to discuss the different aspects of the requirements. The end result is mostly the consensus about the requirements for that particular element.

Brainstorming: The idea is to gather people to think like a group, altogether on one idea to solve a problem or determine the scope. An idea is presented in front of the group and the inputs from everyone generates new ideas or requirements. Only the relevant and workable things are noted and agreed upon in the end.

Delphi Technique: Don’t be haunted by the term. It is very simple to understand and this is how it works; a request for information is sent to subject experts anonymously. Their response is compiled together and sent again to everyone. The process is repeated until the consensus is reached.

A few more as mentioned in various articles about collecting requirements are mind maps, affinity diagrams, questionnaires and surveys, observation, prototypes, etc. No matter what technique you adopt as per your need, the end result should be a compilation of requirements as complete as possible. As discussed earlier, a comprehensive Collect Requirements process will help you avoid unforeseen risks, unwanted changes, delays, cost overrun, etc. and will help you complete your project within the project baselines.

On a lighter note, though most of you must have seen this, have a look at the following image of a flawed requirements collection process:

Close Project or Phase

The culminating point of the project is close project or phase process. It is to finalize all the activities going on in all the knowledge areas to complete the project. Since its functions span all the knowledge areas, that is why it has been put in the integration knowledge area.  The project manager measures the project performance against the project management plan as a whole and project baseline in particular. If everything is completed as per the plan, the project is announced officially closed. Remember that the project can be closed not only after it is completed but also when it is terminated due to whatsoever reason. The administrative closing of the project happens when another of the process, close procurement, is also done.We will discuss this process in the procurement management knowledge area.

The project manager, besides ensuring that all the work has been completed as per the project management plans, also performs the following activities in this process:

• Completes final performance reports of the team and the project
• Gets the final approval of the product which seals that the work is complete as per the plans and hands over the final product
• Adds project documents and records to the organization’s archives and updates the lessons learned knowledge base
• Release resources

Besides these listed most common done activities, there might be certain activities subject to the project industry which are to be done in order to close the project officially. As a project manager, one should be aware of the industry standards of executing the project from start till its conclusion.

Perform Integrated Change Control

Unlike its very confusing title, the process itself is very simple to understand, but extremely complex to perform. During the project executing and monitoring and controlling processes, changes are requested that effect different components of the project. These requested changes are accepted/rejected and handled in perform integrated change control process. In simple words, perform integrated change control looks in to the changes and their impacts on all knowledge areas. As previous, the integration means dealing with all knowledge areas.

Consider a change in scope requested by the customer. Imagine what severe problems the project manager could face if he just calculates the cost of this change and starts working on it rather than performing a complete integrated change control process. He might totally be missing out the impacts on HR, schedule, quality, etc. and the project may end up in a total disaster. The very next thing to be done after receiving a change request is to calculate its impacts on all knowledge areas in the perform integrated change control process. It is only after this complete impact analysis that the change request, its required actions and strategies are sent to the change control board for the final approval. Change control board are made so that the responsibility of accepting or rejecting a change does not only fall on the shoulders of the project manager alone. The board may include the project manager, customer, industry experts, the sponsor, etc. Once this process is done, the project management plan is updated in its respective areas. There may be changes in the project baseline after the changes are approved, so all these effects have to be reflected in all the documents.

Monitor and Control Project Work

This is another of the integration knowledge area process which means it has to do some thing with processes in other knowledge areas and process groups. This process is very closely knitted with the direct and manage project execution process we discussed in the last post. As the name suggests, this process is about monitoring the activities and tasks being done by the project team and controlling it to stay within the acceptable limits of the project scope. The project manager is required to do this process from the initiation of the project till its end. He has to keep measuring the project performance against the project baseline defined as part of project management plan. This process is considered among the most important of the tasks a project manager does because this is where he finds out whether or not the project is being completed as per the project management plan. If not, the project manager requests changes including recommended corrective/preventive actions or defect repairs to change control board. The monitoring part is reviewing and analyzing the project performance while the controlling part is about taking steps to ensure that project remains within acceptable limits.

There can be situations where in a project, the scope is completed but quality is not acceptable or the quality is met but with excessive cost. These are the situations where monitor and control project work process comes handy if done properly. the project manager can continuously balance the requirements of different knowledge areas to control the project within acceptable limits. The integration function of monitor and control project work mainly involves reviewing the current status reports, analyzing them, foreseeing and forecasting the changes to be made in order to keep the whole project under control. There is a concept of work authorization system associated to monitor and control project work process specifically. This means that there has to be a system under the project manager which ensures that no work on the project is carried out or started before the authorization of the project manager. This is a very important concept to understand. As we know that the project manager is a person who knows about all the activities going on in a project, their results and their inter-dependability in detail. He knows which activity is to start after which one is finished. He cannot afford to have an electrician or a painter show up to work on a construction site where the foundations are being laid. Without a proper work authorization system, things like this are likely to happen.

The key is to remember that this process is in the integration knowledge area and that the monitoring and controlling means measuring actual project performance against the project baseline.

Direct and Manage Project Execution

Direct and Manage Project Execution is a process that falls under the integration management knowledge area and executing process group. For details on knowledge areas and process groups, please click here. In simple words, the project manager ensures that the project management plan is implemented in its entirety. If you understand the project management plan, then this topic could be really easy to grasp. One important thing to note here is that this process is the integration part of executing, so it does not cover the entire executing process group. Think of it as a process where you just gather the information from all over the executing processes in different knowledge areas and then using that information to measure the project performance but comparing it against the project performance baseline mentioned in the project management plan.

The key to be a successful project manager is to keep the word integrate or integration all the time in your mind. It is not the project which is to be managed. Its actually the individual knowledge areas plans that are to be monitored and managed. It is about knowing the effect of change in one plan on all others. For example, change in scope management plan may have effects on HR, time/schedule, cost, risk, etc. management plans. The day you start thinking on these lines and can link the relationship among the different individual plans, you will become a great project manager; just like me. 🙂

While managing the components of the project management plan, the project team is required to implement one or all of the following actions which are the result of the decisions taken by the change control board after receiving the change requests:

1. Corrective Actions: as the name suggests, these actions are taken to execute the work in a way that brings the project in line with the project management plan
2. Preventive Actions: unlike the corrective actions which are taken when something goes wrong, the preventive actions are taken before that by identifying the risk in advance and preventing it.
3. Defect Repair: another word for rework when the component of the project is not as per the specification. This happens when the work is completed without any corrective or preventive action taken but does not result in the required state.

The details on these actions will be provided in the preceding articles. Once these actions are taken, all the effected component in the project management plan are updated to reflect the latest status of the project. Besides updating the project baseline, if needed, and individual management plans, project documents like requirements document, risk register, stakeholder register, logs, etc. are also updated.

Process Groups & Knowledge Areas

As described by the PMI in PMBOK guide, 4th edition is referred here, the project managers’ work is divided into 42 different processes. These processes are listed in a matrix structure of 5 process groups and 9 knowledge areas. In simple words that I read somewhere some time back, the knowledge areas define the different areas of project management which the project manager should have knowledge about. Whereas, the process groups are where the project manager applies his knowledge. For example, in the ‘project cost management’ knowledge area, the project manager should know how to manage the project cost by properly estimating the cost and making budget during ‘planning’ and later controlling the cost in ‘monitoring and controlling’ process groups.

The important thing to understand here is that these process groups and knowledge areas are continuously evolving with the progressive research in the field of project management. Project managers encounter new problems and find new solutions to tackle them. These solutions and their forming steps are later refined into processes which are placed under the matrix of process groups and knowledge areas. Following is the list of knowledge areas and process groups as listed in the 4th edition of PMBOK:

Process Groups

1. Initiating
2. Planning
3. Executing
4. Monitoring & Controlling
5. Closing

Knowledge Areas

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resources Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
10. Project Stakeholder Management (newly added knowledge area in PMBOK guide 5th edition)

An easier way to remember these knowledge areas by heart, which I learnt from my teacher, is to remember this phrase ‘I Saw The Cute Quality Hens Commonly Rated PeacockS‘. The bold letters are the initial characters of all the knowledge areas in proper sequence. All these knowledge areas are discussed in detail in preceding articles.