Setting project scope

Recap

So far in this series we have looked at software development methodology and conflict. Now we will discuss project scope. We will observe how setting scope can be used to minimise conflict and provide for a clearly defined, better quality product or service.

Let’s recap on what good looks like, on a project that conforms to Government Digital Service. We can then identify different phases, which may benefit from a clearly defined, commonly understood, project scope.

Before the team come out of discovery, they should understand:

• Users
• Problems
• Needs
• Constraints
• Policy intentions

Introduction

At this point, the team have done enough to understand that there is a problem that needs addressing. Now, it would be useful to introduce some form of problem statement, in order to ensure the team has a common focus. The activity of creating a problem statement, can go hand in hand with producing a scope definition. A problem statement and a scope definition can help to produce a product roadmap.

Problem statement/Scope definition

The creation of a problem statement could be a great team activity, involving senior stakeholders and representatives of every specialism on a project. It can be produced during an ‘inception’ and should involve three key questions:

• What is the problem? – becomes problem statement
• Why is it a problem? – ensures common understanding
• How will we solve it? – sets clear direction and allows the team to discuss ‘ways of working’

When defining ‘what’ the problem is and coming up with a problem statement, the explanation should be short, clear and precise. It should focus on the negative aspects of the current process/service and outline, why addressing the problem is particularly important.

Once we have defined what the problem is, it is important for the team to understand why it is a problem or how it became a problem. When working through this as a team, it ensures a common understanding. This will allow the team to keep focus and form the basis of a scope definition.

When the team understand what the problem is and why it is a problem, it is important to ideate on how it can be solved. Here, we can ensure an understanding on roles when moving into alpha. We can also allow for a clear separation of duties and an understanding of which tasks require a collective and joined up effort. Bearing in mind that collaboration will be key to the project success.

At this point, senior stakeholders such as the Service Owner and the Product Owner can provide details and answer any questions on the project scope. This can be documented at a sufficient level of detail, but the important objective is a collective understanding.

Example: The number of nurses applying for a job has been decreasing for the last 10 years, leading to a shortage.

Product roadmap

Once the problem statement and scope definition have been produced, it becomes possible to create a good product roadmap. At the highest level of the product roadmap, it is useful to set out the ‘Product Vision’. This could be a one liner on where we intend for the project to end up.

The product roadmap allows for a prioritised approach to service design and software development. It will also contain a timeline. Depending on the level of detail that is required, it could outline Themes, Epics and Stories that are to be tackled. However, I find it is most useful when it highlights only Theme and Epic level detail. This allows for the team to break down the Themes and Epics into Stories, based on user research findings and user needs.

Sprint goals

Now that we have discussed the products that should come out of discovery, we can take a look at one other scope item, often useful for the remainder of the project. This is the use of ‘goals’.

When working in a scrum environment, it is useful to have goals set out on a sprint by sprint basis. However, if the team does not work in sprints, it is still useful to discuss and agree goals at a regular interval. This ensures that the work being completed by the team, is in line with the problem statement, scope definition and product roadmap.

It is important to keep in mind, that any goals should be achievable, visible, meaningful and measurable.

Example: create a solution that allows for applicants to browse for jobs

Final Instalment

The final instalment of this series will take a look at organisational culture and the balance of skills within the team. Stakeholders have been a common feature across this series. Therefore, I would like to discuss a technique called ‘Power/Interest’ as a means for stakeholder management. We may also be able to gain further insight from experienced colleagues at Difrent, on techniques that have helped when successfully delivering projects.