Scoping statements

Motivation#

Within the first few days of my time I was introduced to the concept of a scoping statement. Essentially it is a document to ensure that a project is completed and the deliverables are as expected for the client. The party creating the product/service should write this document to make it explicitly clear what they will be doing, and then they should provide this to the client to ensure their expectations are properly met. I already understood the concept of having this documentation as the aim is to avoid completing a project and then having it discarded due to some misunderstandings along the way. However, I have only ever received this type of document for courseworks, I have never written my own.

This blog will describe the general format of a scoping statement and then I will outline how I used them during my work experience with National Grid.

I made use of this website to learn about the general format of a scoping statement. There is room to adjust this of course, and so I will also discuss how I altered the general template a bit within my experience.

General format#

Business case#

The first section of the document aims to outline the reason for the project and how it will be useful once completed. It should describe the end goals of the project to help visualise what the project will provide when completed.

This section should be quite extensive as this is essentially ensuring that both the client and creating party understand the project at a high-level, and then the specifics can be outlined within the subsequent sections.

Project deliverables#

Within this section there should be a description of all the deliverables that will be provided to the client.

Again this needs to be extensive such that no details are missed out as these missing details could lead to misunderstandings and ultimately a project that may not meet expectations. By making it clear what the client will receive you are ensuring that they will not keep asking for more throughout the development of the project, this means that the project can be planned more effectively and the time-frame for completion is more likely to be accurate.

Acceptance criteria#

This is an extension of the previous section and it explicitly desscribes what needs to be completed in order for the deliverable to be accepted. This will become a checklist for the project team to complete for each deliverable. This will keep the project on track and it will ensure that only the requested features of the project will be completed.

Constraints#

This section outlines the constraints of the project to manage client expectations. Typically the time and budget constraints will be the main articles in this section. However, this could also include constraints with software that the project team might need to use, or it could describe the potential risks associated with the project.

Assumptions#

This section aids the party to outline more about the client they are working with. This is especially useful for the start of the project when there are still many unknowns, and by conveying these assumptions to the client they can either confirm or deny them.

Exclusions#

Any final clarifications about anything that is out of scope and will not be included in the project. This again enforces there is no room for debate about what was expected to be delivered to the client as this sectioon will specifically outline what will not be included.

Agreement#

Finally, by having the party and client sign the document it ensures that the document is fit for use and that the agreement is official.

My experience#

I received three projects during my experience which I was told about before I started. Originally there were quite vague and when I arrived at the offices I did not really know what I was going to be doing at all. Reflecting on this I think I should have asked more questions before the experience started, that might have given me a headstart as I struggled a lot with getting started. This was emphasised by the fact that my manager was very busy so did not have much time to talk through the projects and answer my questions.

I began the scoping statements after it was recommended to me by another employee. As I had little idea about my projects, my original statement was actually just a set of questions to refine my idea of what I was going to do. Throughout the experience I slowly developed the scoping statements for each project and I then had a complete view of all my projects and their respective deliverables.

I do not think I used the scoping statements as thoroughly as I could, but I was largely limited by my time and the fact that I was not able to get much time with my manager to discuss the projects. Nevertheless, I now better understand the process of completing a project for a client, and I am sure that I will be able to use this type of documentation more effectively the next time it is required.