INTRODUCTION

In my previous blogs I describe the framework around how to manage a project, the process groups and the knowledge areas.  It’s now time to delve into the details and understand each of the knowledge areas in more depth.

We start with 'Scope'.

Scope is about understanding what the customer wants us to do. 

I was once told a story about a project to track moose within the Canadian countryside. The scientists involved commissioned a tracking device to be hung around the moose’s neck. The project was duly delivered and fitted to a moose that was captured and then set free. The scientists gleefully returned to their research station but the moose never moved. On return they found the moose dead. The tracking device designers were contacted, “You killed our moose?”. To which they replied, “What moose?”. Apparently, the device was too large for the moose to stand whilst wearing and eventually died of starvation. The scientists had neglected to tell the designers what the tracker was for and the designers had failed to ask.

moose head shutterstock_341552243.jpg

 

This is probably an urban myth but similar misunderstandings happen in projects all the time. What we need is a way to track all the project requirements; and this is called a...

Requirements Traceability Matrix

This is a detailed list of things that must be done. We should describe what is needed, why it is needed and what we are going to need to be able to do the task.

It should be started at the beginning of the project in the Kick-Off meeting. Here knowledge is limited but the higher-level tasks should be apparent. Through successive conversations with the customer you will learn more requirements and the details of those requirements can be progressively elaborated as the project moves forward.

Getting details out of the customer can be difficult. They will assume that what they know is obvious and therefore you should use a wide range of group creativity techniques to ascertain all the requirements.

Scope Baseline

Once we have completed our requirements elicitation we should have a good high-level view of what is required for the project. We can then generate our scope baseline.

Our scope baseline is a statement that identifies what will and will not be done on the project e.g. To design a tracking device to be fitted to a moose within 6 months at a cost of 24 man-months.

moose head shutterstock_341552243.jpg

The scope statement will also detail:

  • Boundaries – Specifically where we will stop e.g. the antenna will be outsourced
  • Constraints – What is constraining the project e.g. scope, schedule, cost or quality
  • Assumptions – What assumptions have we made e.g. Only fitted to adult moose
  • Deliverables – What and how we will deliver at the end
  • Acceptance Criteria – How will the customer accept our delivery

 Group Creativity

When discussing requirements with customers – and in general with all team information gathering – it can be difficult to extract the information.  Therefore, several group creativity techniques can be employed:

  • Brainstorming – An open fast moving session where ideas are written down on a whiteboard with no time taken to analyse them. This comes later
  • Nominal group technique – Same as Brainstorming but ideas are later voted on for relevance
  • Delphi technique – The experts produce and rate the ideas secretly. Stops anyone from being dominated by the group
  • Idea/mind mapping – Used to visually organise information as a hierarchy of its parts
  • Affinity diagram – Used to sort the ideas coming out of brainstorming into groups
  • Multicriteria Decision Analysis – Used to find the ‘sweet spot’ between often competing factors e.g. cost and quality

Validate Scope

As we now understand the customer requirements through our elicitation process we can then proceed to execute our project and deliver the final product.  But how can we be sure we are delivering the right thing?

This is achieved through validating our scope and is the process of agreeing with the customer that what we have delivered matches their expectations.  Typically, this is done by running a checklist of all the requirements and agreeing that each has been completed.  Of course, this does require that all the requirements are well documented.

Once a delivery has been validated, we can close the project or phase and move onto the next. 

At Sondrel, for our RTL2GDSII project engagments we follow our own proprietory methodology calledNeon. This a 5 step process, taking the project from a discovery phase, through a series of flow and trial gates, onto an implementation stage, and then to a finishing and ECO stage. 

Neon_diagram.jpg

If the customer later decides that the delivery doesn’t match their requirements it can be handled via a change request.  This will stop continuous re-deliveries when the customer is unsure of what they want.

As always, the process must be defined in the project plan.


CONCLUSION

moose head shutterstock_341552243.jpg

This is a brief insight into some of the key concepts of managing Scope and with just these you should be able to prevent any more unnecessary moose deaths!  In the next blog, I will continue our examination of the knowledge areas with the Schedule knowledge area.

Andrew Miles PMP

 Andrew_Miles.jpg

Andrew Miles is a physical implementation engineer turned project manager.  He is PMP certified and has led many projects for a number of tier one companies.  He helps to run the Sondrel Project Management Office (PMO). If you'd like to know how Sondrel's project managers can help your project then please contact sales@sondrel.com