Question

Project Management:-

This exercise pertains to the Validate Scope and Control Scope processes. Please answer the following questions:

a. Identify the inputs of the Validate Scope process. How are these inputs used to fulfill the purpose of this process?

b. Discuss the tools and techniques used in the Validate Scope process as well as the outputs of the process.

c. What inputs of Control Scope can you use to help determine if a scope change has occurred or should occur?

d. When scope changes are requested, what parts of the project should be examined for impact? What needs revising or updating as a result of scope changes?

e. Describe how the configuration management system and change control system work together in this process.

Answer 1

Validate Scope

Validate scope is the process of formalizing acceptance of the completed project deliverables. Validating scope includes reviewing deliverables with the customer or sponsor to ensure they are completed satisfactorily and obtain formal acceptance.

Validate scope is closely related to quality control as well. However, scope validation is primarily concerned with acceptance of the deliverables.

Whereas, quality control is primarily concerned with the correctness of the deliverables and meeting the quality requirements specified for the deliverables.

Quality control is generally performed before scope validation, but these two processes can be performed in parallel as well.

Let us look at the inputs to this process.

The project management plan provides information about how the deliverables will be validated and accepted by the customer and other stakeholders. The requirements documentation acts as the basis on which the validation activity is to be carried out.

The requirements traceability matrix documents how each of the requirements has been implemented and how it can be validated.

The fourth input is verified deliverables and implies that the verification activity is first carried out by the team under the control quality process, and only then, the deliverable enters the validation process.

Work performance data gives more inputs on the deliverables that may be useful in validating and getting acceptance. The technique used to validate scope is inspection and group decision making.

Some of the typical activities that are done as part of inspection are measuring, examining, and validating to determine whether the work and deliverables meet requirements and product acceptance criteria.

Group decision-making techniques may be employed if a team is working on the process of validating the deliverables. It helps in arriving at a decision by either consensus or majority or any other method.

The output of this process is the accepted deliverable.

Sometimes deliverable might be acceptable and that results in another output, i.e., change request. Due to the validation process, the information about the deliverables, which have been accepted, and any observations during the validation process may be recorded.

Some documents, like a report on the status of the project’s product, is updated as result of this process and listed as one of the outputs.

Control Scope

Control scope is the process of monitoring the status of the project and product scope and changes to the scope baseline. Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the “perform integrated change control process.”

The inputs project management plan, requirements documentation, and work performance data are the same as the inputs for control scope and validate scope.

Work performance data has information about the progress of work on the different deliverables.

The other input is requirements traceability matrix, which lists the requirements included in the requirements document.

Organization process assets also influence control scope in a sense where an organization would have standard templates for monitoring and reporting scope related updates. Scope control is performed using variance analysis.

The variation is measured from the original scope baseline, which decides whether any corrective or preventive action is required. The key output of the control scope is work performance information, which is planned versus actual technical scope performance.

If any part of the scope performance does not meet the acceptance criteria, it may result in change requests, which is the other major output of this process.

If your scope is pointed the wrong way, you’re not going to hit the target!

In fact, ineffective project control is one of the biggest sources of project distress. For this reason, one of the most important aspects of a project manager’s job is controlling the boundaries of the project, that is, the tasks that are and aren’t part of the project.

If you want to have any hope of hitting the target at the end of the project you need to make sure the scope is pointing right at the target, not off to the side, or too high or low.

In the Project Management Body of Knowledge (PMBOK), scope control is a major part of the Monitoring and Controlling process group.

Simply put, the scope of the project should not change.

Often there are external forces pushing and pulling on the project that result in changes to the project’s scope, and these can be legitimate. But the project itself needs to be planned well enough that changes in scope don’t result from normal project work.

The exception to this might be with an agile project, a technique which is used primarily in software development where pieces of software are developed, tested, and released in parts. This process is required when you can’t define the final product well enough to accurately estimate the work required at the outset. But in conventional project management the scope needs to be defined as well as possible when the project is initially planned, and scope changes avoided whenever possible.

In the second world war, the Germans lost to Britishers & Americans in North Africa. Why?

Because of their failure to do Configuration Management.

When a tank used in the war broke down and needed a replacement part, it will be ordered. Most of the replacement parts would arrive on time, but would not fit nicely, causing the tank to be put out of service. Over the next few months, the supply of the German tanks reduced considerably, and the Americans and Britishers triumphed.

Configuration Management is the solution to solve this wrong-replacement-part problem. It tracks the different revisions to the design, blueprints, technical specifications, and can tell you which one is the lastest revision, so that the right part can be identified.

Configuration Management is primarily a Version Control System for the Product of the Project.

According to the PMBOK Guide, Sixth Edition:

Configuration Control focuses on the specifications of of both the deliverables and the processes.

Change Control is focused on identifying, documenting and controlling changes to the project and the project baselines.

A Change Management Plan documents how changes will be monitored and controlled. The plan defines the process for managing change on the project.

A Configuration Management plan documents how configuration management will be performed. It defines those items that are configurable, those that require formal change control, and the process for controlling changes to such items.

Basically, a Change Management Plan is a generic plan that guides the Project Manager in terms of making any kind of change on the project, specially the ones that can impact the baselines (scope, time, cost baselines), whereas, a Configuration Management Plan only guides you in making changes which are specific to the Product Configuration.

Do you understand what does the term “Configuration” mean?

A configuration is the identified and documented functional and physical characteristics of a product, service, result or the component. This really means the “actual specifications of the product” of the project.

A Clear Difference:

First of all, you must know the difference between a project and an operation.

Let’s say that we are undertaking a project to create the product, service or result.

All the work that is done as part of this project is considered the “process”, which is used to create the “product” of the project.

The change management plan oversees how any change to the “process” should be done.

The configuration management oversees how any change to the “product” should be done.

An example of Configuration Management:

Let’s say you are the Project Manager of a large, multi location application installation & implementation Project. It requires you to send your team to upgrade the software, hardware, and get the system up and running in each of the 562 locations country wide, in the next 6 months. Each location has their own servers, and you need to upgrade them to standard version of hardware, software, utitilies and application, which are all compatible with each other.

You can have a great Change Management System in place, which will track how changes to the user’s specifications in terms of scope, time, cost, quality etc. are to be managed. But your team will have a tough time if you did not setup a proper Configuration Management System, which will track the different versions of the Hardware, software, compatibility between the versions that are running on each server, and enable the team to know what is compatible, not compatible, and what has been upgraded or not upgraded.

Remember, this is a large project, and your team is going to be spread out – no one person will be able to remember the different versions of each server specifications, and their upgrade state. With a proper configuration system, all changes to the servers will be tracked, and you can easily find out what version is running where, on which server, it’s compatibility etc. and make life and project management easier, less stressful for you.