What is scoping?

Scoping encompasses the relevant practices and processes, to ensure that the project provides all the deliverables required from it and does not expel any unnecessary effort. In the context of this article, I’ll borrow the definition outlined by the PMBOK Guide in that the term scope can refer to:

• Product Scope – features and functions that characterise a product and or a service
• Project Scope – the work required to deliver a product or service with the specified features and functions. Thus, project scope can encompass product scope or an element of it

For those of you not familiar with the PMBOK, it also states a logical flow of activities that the Project Manager should perform in order to scope a project. These are:

1. Plan Scope Management
2. Collect Requirements
3. Define Scope
4. Create WBS
5. Validate Scope
6. Control Scope

However, in this article I am going to deviate from the PMBOK and jump straight to Collect Requirements.

Why?

Firstly, because part of the ‘art’ of scoping is appreciating that the application of the above steps, in the real world, will require you to make a number of iterations. Secondly, because this article, in part, provides an outline which can be reduced to a set of bullet points, which will form the basis of your initial scope management plan; essentially capture this once you’ve read this article and you’ve met the criteria for step one.

Though the more important point that I am keen to get across is based on my experience of scoping, I am yet to encounter a sponsor or group of stakeholders that has clearly defined, even partially, ‘what’ they want to achieve. Without going into the multitude of reasons as to why this doesn’t happen, your area of focus should be on what is required in order to progress the project successfully, which is to establish a shared and agreed understanding of what the project will and will not do, a.k.a. the scope. Hence, the first weapon from your armoury which you will need to blow the dust off are your stakeholder management skills, as you’ll need to ensure that you talk to all the relevant parties and capture their interpretation of what the project will do. So, let’s get started.

Collect Requirements

Step one is to request, if already documented, any existing requirements. If there is something, even if this ‘document’ also contains the words ‘Benson and Hedges’* be grateful. It means that they have provided some initial thought into ‘what’ it is that they want. Your job now, with the assistance of a Business Analyst if required, is to refine your understanding of these requirements. To aid you in this process, engage the local organisation and / or PMO to determine if there are any standard tools or templates that you can use, or are required to meet any internal governance criteria . Also, if you do have resources supporting you, agree on how you will document and store the requirements going forward – this forms the low level basis of your Requirements Management plan. Ideally, Requirements should be stored in a Requirements Traceability Matrix which can be as basic as post it notes on a whiteboard, an excel spreadsheet or a dedicated system.

You are likely to find that, at this stage, the requirements that you have raise more questions than answers, or that nothing has been documented. Subsequently, the second step you will need to take is to organise a further round of discussions to clarify any questions and elicit requirements from the relevant stakeholders, which will invariably begin to flesh out the next level of detail.

Approaches that you can take to achieve this include dedicated interviews with key Stakeholders, or you can establish focus groups of Subject Matter Experts (SME’s). Which you opt for is dependent on your experience as a PM and that of the organisation and customer. Personally, I would recommend interviews with key stakeholders as a first step, as you are likely to need to build trust with them and having a private environment to discuss the project can facilitate more confidential information to be shared. This can be key to the overall projects success, as it will likely inform your future decision making process.

The other benefit of this approach is that you are likely to have some stakeholders who are more extroverted than others when it comes to sharing their opinions – by giving them each their personal space it ensures that no one voice is dominating the discussion. The downside to this is that it is time consuming, and certain stakeholders are likely to have busy schedules. Hence you will need, at some point, to hold a meeting with multiple SME’s. When doing this be clear on what the purpose of the meeting is and have a clear agenda in order to structure the conversation.

In order to mitigate a single voice dominating the conversation, make a concerted effort to ask the opinions of quieter members whilst in the meeting. You can also use active listening techniques to summarise your understanding of key points and clarify if everyone agrees with your understanding – this will give others the opportunity to voice their perspective.

Solution mode

Regardless of the meetings that you hold, you are likely to encounter stakeholders who have already jumped to ‘solution mode’. This can be characterised as being told ‘what will fix a problem’. This invariably will be based on preconceived ideas and assumptions which may not address all the underlying issues. Hence, a tactic to address this is to use an approach such as the ‘5 whys‘; asking ‘why’ five times in a row in order to find the root cause of said assumption or issue. Another alternative is using an approach such as Design Thinking to foster divergent thinking to build consensus on understanding the problem, before attempting to use convergent thinking to design the right solution.

You may get some ‘push back’ from stakeholders who have already, in ‘their mind’, solved the problem and that their solution just needs to be built. Resist the urge to blindly follow this person. As well-intentioned as they may be, from my experience I have not yet met a stakeholder who has doubled as a ‘design genius’ and a ‘mind reading savant’ of the customer, we are all fallible. It is highly likely that this person is what can be described as a dominant action-orientated personality type**, ultimately they want to see results and are less interested in the process.

As such, they are likely to perceive anyone not agreeing to immediate actions as a blocker. In order to harness their enthusiasm, without them dominating the process, I recommend creating a prototype as it demonstrates tangible progress and allows you and the team to clarify requirements, helping you to validate the scope.

Prototyping

I cannot stress enough the benefits of creating a prototype as quickly as possible. It will help all involved to get to a point of a shared understanding of the scope of the solution, enable the elicitation of the requirements and help to identify any underlying assumptions, allowing the team to learn as quickly as possible. The thing to remember with prototyping is that is can be exceptionally low tech – hand drawn sketches on paper as an initial first step can be all that you need.

For a brilliant example of what Eric Reis’s refers to as ‘Wizard of Oz testing‘ in his book The Lean Startup, Reis outlines the exploits of a team creating a product called Aardvark. In order to create a working prototype they hired humans to replicate back end functionally to demo their product and confirm with their customers that what they were creating provided value. This example demonstrates that you don’t have to get drawn into a full on development cycle to create an ‘all singing and dancing’ prototype. All that is required is a little imagination and creativity.

Depending on the nature of the desired product and the maturity of the organisation creating it, you may have access to more elaborate tools. The point is to capture something as quickly as possible which will elicit a conversation to help you and those involved build consensus as to ‘what’ it is that needs to be built, and ensure that it has value to the intended customer.

WBS/Product Tree

Once you’ve captured a list of requirements via interviews, workshop or potentially building prototypes, you will begin to get a clearer idea as to ‘what’ is the scope, though may not yet have captured anything which clearly depicts the scope to other stakeholders. It is at this point I recommend creating a graphical representation of it. This is sometimes referred to as the Work Breakdown Structure (WBS). I have also encountered variations of the same concept in Product Management and Agile tools and techniques with Product Trees being a prime example of the same concept inverted. All you need to get started is a a whiteboard or pad of paper, some post it notes if desired and some pens. For more information on how to create a WBS, check out this video:

Regardless if you capture a WBS or Product Tree the key benefits for depicting the scope graphically is that:

• You can structure it however you see fit; features of a product, phases of a project etc.
• It enables decomposition, breaking down deliverables from the upper levels, down to each Work Package or User Story. Creating a clear list of deliverables, which you can validate and prioritise with stakeholders
  • N.B. you don’t need to decompose to a uniform level across the diagram, some elements will go to greater level of detail than others
• You can also include Enablers Work Packages or Sub Components which will be delivered by third parties, identifying dependencies
• Once you have decomposed the elements, you can further plan, manage and control the project to a greater degree

When creating a WBS or Product Tree, it should be an inclusive task, which will allow you to pull on the expert judgement of SMEs who may have created or delivered similar products or projects previously. Hence, you can also create a draft WBS in order to help elicit a conversation with them and use this as part of a meeting or workshop, if required.

You may find that some deliverables are not be able to be decomposed at a particular point in time, this could be for a multitude of reasons (e.g. they will not be achieved until far into the future or theirs is a lack of knowledge at this particular stage). Don’t fret, this is an iterative process. The only other thing to be wary of is attempting decompose down to an excessive level, which is clearly a waste of your time and effort and of those assisting you in the process. The key question that you need to ask yourself is, can the lowest level of the diagram, for example a Work Package or User Story, be delivered in a project reporting /Sprint cycle? If yes, then you have the right level of detail. If not, then you may need to refine it further.

Validation

The point, up to this stage, has been to engage all the key stakeholders and look to build consensus around what it is that you and the team have been tasked with delivering. This may have taken multiple iterations whilst you refine your understanding, though you should have enough information to capture a scope statement. This will include the following points:

• Description of the scope
• List of deliverables
• Acceptance criteria
• Exclusions – what is outside of the scope?
• Justification – background as to why the project is needed
• Assumptions – document any if known and outline how you will look to test these

You may also find that the first time that you are responsible for scoping a new project that you have the underlying feeling that you’ve missed something. This unease isn’t a bad thing. Ultimately it means that you take pride in your work and want to ensure that you do it to the best of your ability. However, you can’t let this cripple you into a state of inaction. In order not to fall into the trap of ‘paralysis by analysis’ you need to get this scope statement shared with the Sponsor and key stakeholders in order for them to validate and ultimately seek their approval.

The nature of the organisation that you are working in will determine if there are any set formal documentation and or procedures you need to undertake at this stage. Check what these are with the Head of the PMO. If there isn’t one, ask other Project or Programme Managers as to what is the correct procedure. In the absence of anything being defined formally, the bare minimum is that you need to play this content back either via a Steering meeting or engaging stakeholders on a one to one basis in order to seek confirmation. Ideally this will result in them providing written confirmation via an email, following a meeting where you have presented this content to them.

Scope Control

Congratulations! Upon receiving confirmation, you have officially now defined and baselined the project’s scope. I have been in situations where this can be cause for celebration, given that it can take multiple attempts before all key stakeholders are aligned and agree with on another, though it is not the time to crack open the bubbly. The project team, if the roles have already been defined and mobilised, will be keen to crack on with delivering as quickly as possible. Though as the PM you need a plan as to how you are going to control the Scope going forward, as Requests for Change (RFCs) are inevitable, to which you will need the project team and the Sponsor to understand their roles and responsibilities in supporting you with this.

Change Management plans are outside the scope of this article, though I would stress you need to tailor your approach depending on the perceived likelihood to which you will encounter RFCs. I have worked on Telecommunication rollout programmes where there is a dedicated resource who manages this process alongside project managers, as well as Software Development projects, where the process was not been formally documented. Though, due to the need to increase funding on the project to cover resource costs, to deliver additional features, this RFC was treated formally and was a regular item in steering meetings until resolved. In short, have a plan, even if it is a set of bullet points in an annex of a steering meeting presentation.

Summary:

So there you have it! I hope that you appreciate that scoping is not as rigid as the PMBOK structure suggests and that with a little time and experience you’ll come to appreciate that scoping is an art, rather than an exact science, which relies heavily on stakeholder management and communication skills alongside using tools such as building low fi prototype and capturing a WBS or Product Tree. The key is to build consensus across stakeholder groups using graphical representations and formal documentation prior to having what is captured validated and approved.

*Please note that the author of this article does not in anyway support smoking, or any particular brand of cigarettes for that matter

**For more information search DISC personality types

• Reis, E. (2011) The Lean Startup. St Ives: Portfolio Penguin, pp 103-106