Project Management and the Knowledge Areas – Scope

Project Management Nov 29, 2016 2:00:01 PM

Nov 29, 2016 2:00:01 PM


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.


READY TO MANAGE YOUR OWN DESIGN TEAM? WE ARE LOOKING FOR ENGINEERS WHO ARE TEAM LEADERS, OR THINK THEY ARE READY TO STEP UP AND LEAD A TEAM. LET US KNOW...

I'm Interested!

 


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 called Neon. 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

www.sondrel.com

For more information on Helium and Neon - Sondrels Design Methodology & Flow - click on the button below:

Click Here to Download Datasheet

 

Tags:

Project Management

Comments ()

Add comment

Related / News

INTRODUCTION

In my previous blogs, I describe the framework around which you manage a project, the process groups, and we started with the first knowledge area ‘Scope’.  I now continue with.

INTRODUCTION

So far in this blog series, I started with my top 5 takeaways from my PMI Project Management training and project experience within ic design services, and then went into more.

INTRODUCTION

In my previous blog, I discussed some of the perils to avoid as a new project manager and now I’d like to begin to explain how we turn this herculean task of project management.

INTRODUCTION

Once upon a time I was a carefree physical design engineer, happily running place and route.  I must have been doing something right because one day I was asked to replace the.

Subscribe to Email Updates