Project Scope Monitoring and Controlling

The last two processes for Scope Management, fall under the Monitor and Control process group.

Verify Scope requires the validated deliverables to be checked and verified against the requirements documentation. Why is it “validated” deliverables? It is “validated” because it has gone through the Quality Control process.

The inspection done on the validated deliverables is performed by selected eligible stakeholders. This inspection session is usually called the User Acceptance Test or UAT. It could also be called product reviews, audit or walkthrough.

Quality Control and Verify Scope could be done in parallel. However, it must be known that quality control is about correctness of the deliverable and verify scope is about acceptance of the deliverable.

At the end of this process, we will either have accepted deliverables or rejected deliverables; which means there will be change requests.

Control Scope “is the process of monitoring the status of the project and product scope and managing changes to the scope baseline” [PMBOK Guide 4th Edition].

Equipped with the project management plan, work performance information and requirements documentation, variance analysis will be performed to measure the work performance at specific dates throughout the project life cycle.

Based on the findings, there will be updates to project documents and change requests where applicable. Through the variance analysis, we will know the current health status of the project and subsequently deciding on corrective or preventive actions.

Strengthening the Boundaries with Scope Statement

When you have all the requirements documented, it is time to confirm the boundary of the project. If you remember, in Project Charter, we have a high level listing of the things that will be done in the project, and the things which are out of the scope.

In the Process Group: Define Scope, we will make a more detailed description of the project and the product to be delivered. With the additional information that we have collected during the requirements gathering activities, we are now able to include more information related to risks,quality, assumptions and constraints.

To be able to come out with the project scope statement, we will need the high level information from the Project Charter and detailed requirements from the requirements documentation. We will need to extract the necessary information to come out with the scope statement.

For this process group, PMI identifies four tools and techniques that could be used to facilitate the process. They are:

• Expert Judgment
• Product Analysis
• Alternative Identification
• Facilitated Workshop

A scope statement will include amongst others, the following aspects, described in detailed to ensure the work to be performed is defined correctly”

• Product scope description
• Product acceptance criteria
• Project deliverables
• Project exclusions
• Project constraints

Gathering Requirements, Continued

In my previous post, The Art of Gathering Requirements, we looked at few tips on how to ensure that requirements are collected successfully. For today’s post, let’s look at the list that PMBOK Guide 4th Edition has outlined for the tools and techniques that can be used to collect the requirements. Let’s assume that Kat is the PM and she’s required to meet up with Customer OST to learn their needs for the newly proposed system.

• Interviews
  Interview sessions are normally done one-on-one. Kat will arrange a private that makes it easier for her to know the current situation the customer is in. Strength and weaknesses can be discussed openly. However, this technique can be highly time consuming; thus Kat needs to schedule the session properly and maybe pick a few important stakeholders for this technique.
• Focus Groups
  This technique is similar to interviews but it is done in group. Especially to a specific target group, for example the sales department, or the complains department, etc. Attendees are usually subject matter experts and qualified stakeholders. Kat will be the moderator for each focus group sessions. She could gather the necessary information interactively, however she must be able to maintain a positive climate during the discussion.
• Facilitated Workshops
  Kat can organised workshops between cross-functional stakeholders with she as the facilitator. With this technique, Kat can quickly see the inter-relationship between the departments. She would be able to see cross-functional requirements as well as the reconciling the different needs and expectations. Any issues can be discovered., prioritised and resolved quickly. Similar to focus groups technique, Katy as the facilitator must be able to maintain a positive climate to ensure trust can be fostered.
• Group Creativity Techniques
   
• Group Decision Making Techniques
  
• Questionnaires and Surveys
  This techniques are good for a wide number of respondent. Kat can collect huge amount of data in a brief period of time. With special demographic aspects, she would be able to derive statistical analysis quickly.
• Observations
  With this technique, Kat will sit down with the a user of the current system to see how the actual process is being performed. She can choose to perform “job shadowing” or be a “participant observer” where she is performing the tasks. This technique will be useful for Kat especially with people who are reluctant or have difficulty to articulate their requirements.
• Prototypes
  Kat will also quickly build a prototype with the information that she has currently to quickly get feedback from a working model. Some people can only see what they want when they look at what is being proposed. Several iterations of the prototype can be performed through progressive elaboration for the user to experiment and provide feedback. After the last cycle, the requirements collected would be enough to start building the actual product.

As she gather inputs and feedbacks from users, Kat will use several documents to refer to and to record all the requirements down:

• Requirements Documentation
  Within the organisation, this document is known as Requirements Specifications; where Kat will describe how each of the requirements will meet the business needs. As she collect more data, the document will be updated accordingly.
• Requirements Management Plan
  Kat would have prepared this document beforehand. Reason being, this document will tell her which techniques that she will be using to gather the requirements. She will also plan how the data will be analysed and documented.
• Requirements Traceability Matrix
  This document is essentially a table that links each requirements to its origin so that they can be traceable throughout the project life cycle.

Have You A WBS?

WBS or Work Breakdown Structure is defined as “a deliverable oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.” [PMBOK 4th Edition, Glossary pg. 452].

A WBS is essentially a mind-map in the form of tree structure that is structured to achieve the main project deliverable. Here’s how it looks like:

The creation of WBS is so important that it is a process group on its own; Create WBS under the knowledge area Scope Management. To create, we will be using the technique of decomposition. Decomposition means to do a breakdown of project deliverables into smaller and more manageable components. We decompose until we reach a component that we can measure in terms of time and cost. The lowest level in a WBS is called a work package.

Each work package will be tied to a control account. A control account is a management control point where scope, budget, actual cost and schedule are integrated and compared to earned value for performance measurement.

A WBS is accompanied by its WBS Dictionary. This is a document that describes each of the WBS components in detail. It will include a brief description of the deliverables, list of activities, list of milestones, etc.

Project Management is a deliverable on its own. Therefore, it has to be depicted in the WBS as well.

The WBS, WBS Dictionary and the Project Scope Statement; together they form the Scope Baseline. The Scope Baseline is one of the important component of Project Management Plan.

So, what is so important about having a WBS? WBS lets you see the deliverables that needs to be accomplished and the components that needs to be completed to ensure the deliverables can be met. Having work packages at the ready and using it alongside the WBS dictionary will ease the creation of schedule, resources management and cost management.

 

[Images taken from PMBOK 4th Edition]

The Art of Gathering Requirements

Most of the time, customers react "violently" towards services or products that is delivered. They seem to be surprised with the outcome, even though they have approved and signed off the requirements specifications earlier on in the project. They will say that they have not requested such and such and what they want is this and that.

Why is this so? Remember this comic:

One important thing to remember is that a service or product to be delivered is based on the needs and wants of the customer; the requirements. Therefore it is imperative that requirements are collected correctly from the right sources. And however we; as the PM; want it, the product is not our brainchild, the project is! So deliver the correct product, the project is a success!

I see requirements gathering process as an art of its own. Reason being, it is not as easy as A-B-C. You need to spend time for it and refine it as detailed as possible. A work of art is not rushed. It is planned carefully; and sometimes changed as the artist deems fit.

Let's look at the strokes that must be done for an excellent finish of an artwork; the requirements specifications.

1. Identify the correct people – Ensure that the people that the requirements are gathered from, are truly the recipients of the service or the users of the product. This people will know the nitty-gritty.
2. Organise a Requirements Gathering Session – If need be, organise a two-day seminar instead of four hours requirements gathering meeting. Arrange different sessions for different group of people, for different types of requirements; functional, non-functional.
3. Ask the users what they want – Utilising techniques like interviews, focus groups, brainstorming, etc. let the users tell you what they want. Most of the time they want everything because they think the need everything. Let them. This is the session where we listen to them. Ask questions to clarify points that are vague, but do not attempt to improve their ideas; this might in the end misled them.
4. Review what the users want – Utilise story-telling techniques, storyboard, flowcharts, tables, diagram, prototypes, etc when reviewing the points collected from the previous session in #3. If possible, organise this review session as soon as possible after the previous session. This is to ensure users are still fresh with their ideas from before. The objective is to understand the points made in #3.
5. Improve the ideas – Separate the needs from the wants. Get the users to prioritise their requirements. Suggest improvements to the ideas to increase the value of the product or service.
6. Agree on delivery phases – If possible, group the requirements and create delivery phases (exclude timeline). Get the users to agree to them. While work is on going, schedule review sessions in each phase to ensure the work done is meeting the requirements. If there is any changes from the users, assess and include accordingly. Remember; while cooking a meal, we check for taste from time to time, to ensure it is as expected. Similarly, perform continuous review on work done to avoid bottle necks of change requests later.
7. Prepare the requirements specification document – James C. Taylor in his book Project Scheduling and Cost Control, listed 8 Tips For Writing Good SOW. Once the document is prepared, review it with the customer, point by point.
8. Get endorsement – Get the customer to sign-off the requirements specification document to show they have understood and agreed to it.
9. Be true to your promises – Some change requests will be shelved for a later phase, or next release. If you have promised this to the customer, make sure you deliver them as agreed. You might want to review again the change requests to see if it is still relevant to the users, but review them you must!
10. Update project documents accordingly – Do not wait until last minute to update the related project documents. If you already have project templates, make use of them; no need to create from scratch.

With this 10 strokes, hopefully the customers will not be surprised the next time they see the completed product for the first time.