This is a critical process in any project management. Possibly this is the most critical one. On the one hand you have to plan to a very high precision to increase the probability of success as also to have minimum and predictable costs associated with it. On the other, change is a constant. Changes may be essential because of business reasons, because the requirements were not understood clearly, because the estimates of time and cost were wrong due to an inexperienced team etc. The list can actually be very long. One consequence of all of these reasons is that change in scope is a reality and needs to be planned for. Changes in scope as the project progresses are inevitable. What one needs to ensure is that the changes do not become uncontrolled leading to a run away project. It is thus very important that a change control be drawn up at the time of drawing up the project management plan. This is one of the critical plans that can have a heavy impact on the outcome of a project.

Controlling Change

As always the project management plan is your reference. In particular, scope baseline, scope management plan, change management plan, configuration management plan and requirements management plans are essential documents against which changes are to be reviewed. Work performance information, requirements document and the requirements traceability matrix and organization process assets are additional documents which let you decide, what effect the changes requested are going to have and how best to manage them.

Scope baseline when compared to actual; performance tells you if changes, preventive or corrective, are required. The changes then will have to be managed according to the scope and change management plans. The change management plan also would have been drawn up when the overall project management plan was finalized at the beginning of the project. Configuration management plan defines the items that are part of a configuration of the product and possible configurations of the product. Changes in these may need formal changes. The configuration management should specify how to manage the configuration related changes.

The requirements management plan must specify how requirements changes will be managed, how to get that process started, analyzing the impacts and relevant approving authorities involved. Work performance information is about project progress, what deliverables are available, how much progress has been made on other deliverable and how much yet to be done etc. requirements and requirements traceability documents together help keep track of requirements and impacts of changes, if required. Of the organizational process assets, existing formal/informal scope control policies, procedures and guidelines as well as monitoring and reporting methods are relevant to change control.

Determining Changes that are required

There is only one technique to evaluate if there are variations from the planned expectations. The departure from the baseline and the extent of departure would determine what actions to be taken. It will also determine if preventive or corrective actions are required. The real trick is to be able to proactively flag such departures so that early containment actions can be taken. Project performance measurements that are taken periodically to monitor progress periodically can be used to determine the variance from original scope baseline. You should be able to determine the cause and extent of variance, from the baseline, through whatever variance analysis is appropriate. Take a decision as to preventive or corrective action required.

Outputs of the Process

Work performance measurements are done at specified/periodical intervals to determine the planned vs. actual technical performance and other scope performance measurements. These are communicated to stakeholders.

Organizational process asset updates helps keeps these references current as the project progresses. At a minimum, causes of variances, corrective actions selected and the reasons for choosing the particular course of action, same for preventive actions as well as any other lessons learnt are recorded.

Change requests are tricky and they need to be carefully analyzed. This may result in a change request to the project scope base line or other parts of the project management plans. Preventive or corrective actions are to be carefully studied so that the anticipated problems are resolved with the minimal impact of time and cost budgets. One may have to decide on what kind of defect repair/ rework activity is appropriate. Review of change requests and their disposal9 how exactly to be deployed) will be controlled by a change control plan created for this purpose.

Change orders that are approved trigger changes in the project management plan documents; specifically in the scope baseline and other baselines such as cost and time schedule. So updates will have to be issued if there are changes necessary. Approved change orders can affect the requirements document and consequently requirements traceability matrix document. Updates will have to be issued for these documents too as necessary.

Inspection is always about checking a product or output against some specifications that these product(s)/ outputs are supposed to meet. As an example for a bolt manufactured through a manufacturing process the inspection would probably include measurements of the dimensions as per the applicable BS/ANSI or some national standard. Inspections carried out would use tools as appropriate. A Vernier calipers for measuring the length dimension for example. The BS/ANSI/National standard would be the specification or the scope document in this instance. This may sound like the QA/ QC exercise but looking at a bigger context of say use of the bolt in a machine/ structure assembly these would ensure the complete structure needs are verified.

Scope Verification Inspections

Important issue to note here is that the inspection should use an appropriate tool that can measure or otherwise pin down the scope aspects. Thus inspection may involve measuring, examining, doing complete product reviews and walkthroughs. Purpose of using these techniques would be to confirm acceptability or otherwise of the project deliverables. The nature of the project, its domain area, specific phase of the project and exact nature of the work packages will determine the verification methods. For example a walkthrough in the coding phase of a software project would simply mean the code walkthrough; a technique by which specialist programs study and detect potential code problems. At the topmost level though the sponsor/customer and other stakeholders may have to use appropriate methods at a very high level (may be a presentation of results at a lower level), where project scope as defined by documents and deliverables as verified by the quality group are checked.

Deliverables meeting acceptance criteria are formally signed off and the formal acceptance closes the project or the particular phase of the project unless there are change orders that need to be carried out immediately (some change orders may get carried over). Reason for non acceptance is recorder and reworks (repair work) are carried out. Project related document updates are released.

There is whole set of documents you need to look at to be able to verify the scope of deliverables. The common thread that ties these documents together is that they help define the deliverables and the project context in the form of the project management plan.

What do you need for Scope Verification

The complete set of documents that you need for verifying scope at the end of a project, or the end of a phase, of the project include the following. The project management plan is a top of the list item. That is the master document that defines the complete framework. Some specific components of the project management plan are essential inputs to this verification process. These are the Scope baseline document, the WBS and the WBS dictionary.

The scope baseline describes the reference point of the scope that the project started with and as it evolved through the project lifetime and up to that point in time. WBS document defines the activities that were to be carried out and down to the work packages level. The WBS dictionary defines the work activities and the packages. WBS and the WBS dictionary together are able to specify the activities to be carried out to make defined deliverables available. So if one is to verify the scope one needs these definitions to be readily available.

Requirements document lists all the project, product, technical and other requirements of the project. Corresponding acceptance criteria are also available from this document. Another related document is the traceability matrix. This links down each requirement to the original business needs and any changes that would have happened during the project life cycle.

The documents mentioned up to now defines what was needed/expected in terms of deliverables. One last document defines what has actually happened. This is the validated deliverables document. It tells you about the deliverables as delivered and validated (checked for correctness) by the QA/QC processes.

Conclusion

Having looked at the two sides of what was needed and what was delivered the stakeholders and/or customers accept the deliverables and ask for changes in the ones not delivered right.

At the end of a project or a particular phase of a project one needs to verify that the scope of the project as defined by the deliverables has actually been completed. When a deliverable is completed quality control activities ensure that the completion has maintained the quality of the deliverable. But the question remains, if the deliverable, as delivered, was what was required in the first place? That activity is what constitutes verification of the scope.

Scope Verification

The complete process of scope verification is about looking at the documents that defined the deliverables and ask for approval of the sponsor, customer or stakeholders. Sponsor/customer/other stakeholders would look at the relevant documents and inspect the deliverable against the requirements of these documents and approve if the scope has been met. In few cases where approval is not given changes may be suggested or the project management team should decide on what changes are required and generate change requests.

The relevant documents are project management plan, requirements documents, requirements traceability matrix and validated deliverables. Validated deliverable are the deliverable which has been validated by the quality control team. Stakeholders use inspection to decide what scope requirements have been met and what needs change.

The approval required would be formal in case of key stakeholders; stakeholders such as sponsor and/or customer. Typically they’ll actually sign off on paper or send approval through emails etc. The outputs of the scope verification process are of course accepted deliverable, change requests and changes in project documents if required.

Scope verification really brings out an aggregate effect of if scope was captured completely and delivered completely too. If there is any deviation it will result in change orders. The effect of change order are directly on the project timeline and the cost estimates. More the deviation, more work needs to be done further to bring a closure to the project phase or the project as a whole.

Scope baseline is a part of the project management plan and acts as the reference point through the project life. It has several components. These include project scope document, the WBS itself and the WBS dictionary.

Scope Baseline Document

The project scope document describes the product scope descriptions, project deliverables and acceptance criteria. The WBS is a very detailed description of the complete set of activities that are required in the project. It defines each deliverable and describes how each of these are decomposed onto work packages. The work packages and their interrelationships with higher level deliverables define the exact scope of the project. Exact activities to be carried out as well as any exclusion indicated in the scope document as well as the acceptance criteria specified there describes the project quite accurately. This is as understood at the beginning and acts as the baseline.

As the project progresses, the project progress monitoring sessions may indicate changes ion the baseline document and the project scope. Documented change requests and approved change orders can take care of such changes. Scope management thus remains under control. How effective that control would be depends on the baseline document largely. The scope document and the WBS are crucial data to define this baseline reference. The WBS includes the so called 100% of all work. Work is defined as activities that lead to an outcome. The action per se is not important. The WBS elements are mutually exclusive too. Thus it is nearly as complete a description of the project as possible.

The WBS dictionary has details of work and technical documentation of each WBS element. The dictionary lists and defines the WBS elements. As the WBS evolves, the dictionary will need items added to it to clarify any new elements or terms introduced.

When finalized, a WBS will have several control accounts associated to work packages. More than one work package may be associated with a control account but any one work package is associated with one unique control account. Control accounts are management control points where scope, cost and schedule are integrated. These are used to estimate earned value at performance measurement points in the project life cycle.

The WBS Dictionary

The dictionary is really a supporting document to the WBS. The dictionary provides more detailed descriptions of the WBS elements. By the very nature of the diagram not much detail could be included in the WBS. The dictionary would provide the details related to the activity indicated in the WBS diagram. Work packages as well as control accounts are indicated in the dictionary.

The dictionary contents would include the code of control account, description of the work, the organization that is responsible for it, list of schedule milestones and related activities, resources required, cost estimates, quality requirements, acceptance criteria, technical references and contract information.

As you can see, the pieces of information almost completely define the corresponding WBS activity in the WB structure. Some organizations may need additional information for managing the project. The WBS dictionary should accommodate these additional details.

The control account is the overall control that tracks everything about a particular work package. Description of the work defines the work package and assigning an organization responsible for it, makes sure someone is handling the work package. The activities defined in the work package are defined as are the list of schedule milestones. People responsible would be aware of what has been planned and thus, as a consequence, how the activities related to the package must be controlled.

Resources required will help the team responsible to assemble the necessary resources together before start of the work package. Cost estimates data ensures work performance measurements can be carried out as the work progresses.

Quality requirements are clearly specified so that quality control and assurance activities can be arranged at required points in the work package progress. Achieving quality is an essential deliverable for products certainly, even for services and results too.

Acceptance criteria defines where exactly work ends. These criteria must be measurable so that the deliverable can be checked against measurements and one could take a decision that the work is completed and the completeness of the work and its quality are acceptable.

Technical references must be clearly mentioned. That can help checking assumptions as the project progresses. For determining the completeness and sufficiency of some work, a reference may have been made to literature available in public domain or in some specialist literature. When reading the WBS one needs these references to be absolutely clear.

Contract information also should be readily available. This way the exact reference is available always. Whereas finding the exact applicable contractual reference may be a difficult task, if one has to go through the complete contract every time. One may even miss the need to refer to the contract proposal. The contract reference flags any relevant issue so that it is not missed.

Decomposition is the activity of breaking down project deliverables iteratively. This is continued until the lowest level is reached, this level is the work package level. Work packages are set of activities that are so well defined that cost estimates and time estimates of these sets of activities can be done reliably and accurately. The level of details described in the work packages, obviously depends on the type and complexity of the project.

Decomposition method

Decomposition is an iterative method. At the top level of the WBS structure, which is essentially a tree, are the deliverable objectives indicated as branches from the project level. The deliverables may be indicated as phases of the project, specific deliverables, a set of subprojects or a mix of these. Deliverables and related work are identified and analyzed to create the next level of the WBS. As this activity is continued each branch of the WBS keeps generating multiple branches at the lower level. This continues until you reach the work package level. The organization/ reporting relationship like diagramming is maintained. Each component is identified. One such representative diagram is illustrated in the PMBOK at diagram 5.8. The element numbering can simply represent the level and the branches generated from that level. For example, when level 2 branches off to three activities they can be numbered 2.1, 2.1 and 2.3 etc. the lowermost nodes are identified as the work packages and the same numbering is continued right through. At every step you must verify and confirm that further decomposition is necessary and sufficient. This stops at the work package level which are, as mentioned earlier, a set of activities that can be estimated (time, cost) for the purposes of planning the project.

There are several ways one can go about creating the work breakdown structure. You may start with the project lifecycle phases at the first level of decomposition. Product and project deliverables then can be added at the next level. Fig 5-9 is an illustrative figure of this kind of decomposition.

The first level of decomposition could be the major deliverables, Fig 5-10 of PMBOK is an illustration of this mode of decomposition. Decomposition can also be based on sub projects that are contracted out to agencies other than the project team. The contractors then are responsible for developing the WBS for the parcel of work assigned to them.

It is possible to get carried away and decompose to too much detail. While details help plan, manage and control the work; too much detail can be counter productive. The time and effort of management personnel will increase to co-ordinate too much of detailed activities. It will lead to inefficient use of resources and decreased efficiency in performing the work. So the trade off really is simplifying things but no further (as Einstein is reputed have said).

The details to be achieved are the level at which one has a clear definition of the work package and the estimates can be made accurately. The decomposition proceeds by breaking down the deliverables into its fundamental components. These components should represent verifiable products, services or results. What kind of diagramming is used is not mandated. It could be like an organization structure, as indicated in the illustrations discussed here. The structure could be depicted as a fishbone diagram too. In fact, it could be any diagram that shows up the structural relationships clearly.

A quick test of verification of decomposition process is to confirm that the lower level components are necessary and sufficient to generate the higher level element. This test needs to be applied at every level as the structure grows. The structure is not likely to reach the same levels of decompositions for all the deliverables. Some deliverables that are simpler, could decompose into a work package in one or two levels of decomposition while there may be other activities that would have to be refined for many more levels.

Sometimes it is not possible to decompose activities which may be required some time in future. The decomposition is undertaken only when this part of the work, specific deliverable or sub project are clearly understood. This, thus can be a continuing activity and are often called a rolling wave planning.

There is a so called 100% rule that must be applied to the WBS structures. The structure must take care of 100% of the work and nothing more. For that, lower level elements must roll up to higher level activities. Iteratively the complete set of work packages must thus roll up to the complete projects and no other extra work. When we say work, that includes work not only to produce the deliverables but the project management work, documentation work and everything else that are necessary activities. The “Practice Standard for Work Breakdown Structures” from PMI has detailed methods of creating such structures including industry specific templates that could be used.

Once the project scope document and the scope document are ready, detailed planning for the project needs to start. To do that effectively the project activities need to be defined in terms of clear tasks that can be estimated well in terms of effort and time. Break down of deliverables into well defined tasks also helps define the overlapped activities possible so that schedule planning can be very effective. Breaking down the work to easily handled logical pieces will also show up unknown areas, risks etc. quite clearly.

Work Breakdown Structure(WBS)

The WBS is a hierarchical structure of all tasks/activities related to a higher level activity ending up at the root as the complete project. To arrive at the structure one can resort to decomposition as the only effective tool. You start at a higher level with the requirements(guided by the scope document) and successively breakdown the activities. At each level the activities are geared towards delivering some part of the project deliverables, intermediate or a major one. Project scope document, requirements document and the organizational; process assets taken through successive decompositions would give rise to the WBS. The related documents are, besides the WBS structure, a WBS dictionary and the scope baseline. Project documents update also may take place.

Each lower level of the WBS defines a increasingly detailed definition of the project work. The WBS represent the scope of activities in the project in a very detailed manner and is cornerstone of validity checks on effort, cost, time estimates. The lowest level of activities is called work packages. A work package can be scheduled, cost estimated, monitored and controlled. Creating the baseline project management plan then becomes easy. At this stage the project team is able to generate the scope baseline completely. First level documents such as project management plan, activities definitions, cost estimates, budget estimates, quality plan, risk identification and procurement plans are generated at this stage.

The project scope statement needs to describe in detail the deliverables. The work required to create those deliverables are also to be included. The scope statement can also include specific exclusions, work that need not be done.

Scope Statement

The deliverables definitions as well as the exclusions help manage the expectations of the stakeholders. For the project team it is the basis of detailed planning. The team also checks the statement during on-going work. Change orders arising during the project lifecycle can be checked against this statement to decide if the change requested is within the scope or fall outside it. The project team’s ability to control scope is largely dependent on how well defined the work to be carried out is and what are exclusions.

Typically the scope statement will include project scope description, project acceptance criteria, project deliverables and exclusions as well as project constraints and project assumptions. Project documents that get updated due to this exercise of creating the scope document include the stakeholder register, the requirements documents and the requirements traceability matrix.

Product scope document details the characteristics of the product, service or result to be delivered through the project. These are elaborations of the descriptions in the project charter and the requirements documents. This is further pinned down by defining the project acceptance criteria. This defines the exact boundaries of expectation of the product, service or result as is expected to be delivered.

Project deliverable must define concrete items to be delivered at the end of the project. Intermediate deliverables also could be defined. Besides the deliverables defined as a result of the project, service or results to be delivered this part of the documentation defines project management reports to be delivered as well as any other documents to be delivered. The detail to which deliverables are described basically is governed by the organizations traditions.

Project exclusion, when known can define the boundaries of the project scope very well. What is out of scope, stated clearly, helps focus the project team not to waste efforts on anything that does not contribute to project outcome. It also helps keep stakeholder expectations at realistic levels.

Project constraints is another vital dimension of defining the project scope. Constraints such as a pre-defined budget to a time constraint defined by the customer ( which may be driven by his need for meeting a time-to-market) or some such schedule milestones need to be known up front. It will help work planning when these are clearly articulated. When the project is being executed under a contract there can be several contractual obligations which are constraints to be religiously met. Depending on the organizational tradition these constraints may be part of the project scope document or listed as a separate log.

Project assumptions also are part of the scope definition as these assumptions define what exactly was considered to determine the scope. The assumptions are listed, as well as the impact if the assumptions turn out to be false. Project teams not only identify, validate and document assumptions at the beginning of the project, they need to look at the validity and applicability of the assumptions right through the project lifetime. Once again, these details may be part of the scope document or listed in an annexure.

Tools help in defining scope well, include product analysis and alternatives identification techniques. Product analysis techniques apply to projects that have a product, not a service or a result, to be delivered at the end of the project. Alternatives identification is mainly for identifying alternate methods of achieving same results.

Product Analysis

Product analysis involves breaking down of high level descriptions into concrete deliverables. Typically the techniques include product breakdown, requirements analysis, systems engineering, systems analysis, value engineering and value analysis.

Product breakdown is creating a structure that can depict the product completely in terms of its components and sub systems. It is a hierarchical tree like structure showing the product at the top or the root of the tree and then sub-systems on branches from the root. This continues to the depth required for discussions/ decision making or down to individual components that cannot be broken down further. Product descriptions and product flow charts are additional outputs.

Systems engineering involves the use of engineering (a methodical and accurate) disciplines that can be applied to building systems. Systems Engineering focuses on analyzing and eliciting customer needs and required functionality early in the development cycle. Documenting the requirements, then proceeding with design synthesis and system validation completes the cycle. The process has two parts a Systems Engineering Technical Process, and a management Process.

Analysis literally means taking things apart. In case of systems analysis it means identifying various systems working as parts that interact to create the larger system. Systems analysis helps with the system engineering. It is "an explicit formal inquiry carried out to help someone, the decision maker, identify a better course of action and make a better decision”.

Requirements analysis in the systems engineering context is an activity that determines the needs or conditions to meet for a new product or a modified product is to be developed. Clear cut requirements are essential for projects. They need to be so clear that they are actionable, measureable as well as testable. They should be directly linked to a clearly identified business need. The level of detail needs to be sufficient for carrying out system design.

Value engineering (VE) is a set of techniques you would use to increase the “value” of the products or services. Value is a function of functionality/performance and cost. Enhancing functionality/performance versus reducing costs enhances value. Basic functions are preserved despite pursuing value improvements. Value analysis (VA) is analyses where reductions of costs can be made or functionality improved to increase value. Component cost reduction helps improving value. The analysis directly contributes to value engineering.

Alternatives Identification

It is essentially an ideas generation process. It is followed by validating of the ideas that suggests alternative that are effective for any given approach. Thus all the techniques that apply to idea generation such as brain-storming, lateral thinking and pair-wise comparisons are applicable to this process.

Essential part of the brain-storming process is to suspend judgment of generated ideas at first and generate as many ideas as possible. The idea generation process can be in a meeting like setting where people sit around a table and contribute to idea generation. Depending on how well the session is conducted there is always a risk of the session being dominated by some one. It is also usually hard to keep people from reacting immediately to any idea offered. An alternate method is to create ideas individually and then submit the list. A follow up meeting of the contributors then prunes the generated ideas down to ones worth trying.

Lateral thinking is trying to generate ideas by analogy in different areas. The process is essentially the same as suggested by Edward DeBono and you concentrate on generating ideas first rather than judging them. In his “Six thinking Hats” process he suggests the idea generation be focused by trying to think in one specific aspect. Positive aspects only, negative aspects only, looking at growth aspects and so on lets one to look at various areas, one at a time, and a team should be able to generate a set of all round ideas.

Pair-wise comparison generally refers to any process of comparing entities in pairs. This lets you decide which alternative should be preferred. Alternatives can be compared one to one and given 1 point for a win over the other alternatives and a half point for a tie. The Alternative with the highest score among the candidates wins as the preferred alternative.