A Good Project Scope Can Save Thousands
Project scopes take time to get right. They often involve a number of stakeholders, cover more than just the software (such as training and implementation periods) and need to go through several iterations before they are correct. They are a lot of work and this often puts people off from writing one. One of the best reasons to make the effort:
Changing a project scope document is much faster and much cheaper than changing a project during development.
That is only one of the reasons though, so below is an example of what we would include.
Project Summary
This should all fit on a single page and should include:
Project Title
Bonus points if you have a great acronym.
Summary
One or two sentences about the project.
Project Leader & Team
This is the first critical part of success. Every project should have an identified Project Manager who is going to lead the project internally from beginning to end. If this document is being shared externally then it is a good idea to also put in their contact details.
The rest of the team should also be put in here and their roles and responsibilities. In bigger projects there may be external team members too, such as designers etc.
Budget
If you are stuck then read our blog on sensible budgets.
Dates / Milestones
If you have a critical deadline for completion of the project then highlight it on the first page. You could extend this section to have milestones, for example dates for Scope Sign Off, Mock-ups Sign Off, Development Start, Testing Start, Live Launch etc. It may be the case that you can’t fill in all of the dates straight away, especially if you need an external party to provide them.
Version
Keep everyone working on the same version of the project scope.
Objectives
Write down no more than the top 5 objectives the project is trying to solve.
Not in scope
Keeping a project manageable is as much about what not to include as what to include. Writing down what is not included keeps everyone involved focused and also allows for quick decisions on if something should be included in the project or not.
A quick side note on language. The whole document should be as jargon free as possible and anything technical should be explained in a non-technical way. Try to think about who is going to read the document and aim to make it understandable to them. This is especially important if the document is going to be used by a third party, e.g. the software developer, as industry or company specific jargon can easily be misunderstood.
Project Detail
Keeping the objectives in mind this section is the detail of the project. It will run to several pages and can include screenshots or mockups. The goal here is that anyone can take this section and develop the software with little external input and end up with what you are expecting. Don’t make assumptions that something will just be developed.
For example, nearly every web application will have users. Here is an idea on the level of detail we go into for users.
Types / Roles:
A list of the user types (admin, general user etc). Each user type is broken down into what they can and can’t do (permissions). Without getting too technical, developers often refer to CRUD (Create, Read, Update and Delete) for user actions. So one role might only have view permissions on certain data, i.e. they can’t add, change or delete that data. As the complexity of roles increases so does the need to simplify the presentation of all the variations and a table is a great way to do this.
Passwords:
We define a password policy, e.g. 8 characters minimum, with at least 1 uppercase letter, 1 lowercase letter and 1 number.
Then anything else that may be required, such as 2 factor authentication or forcing a user to update their password every 3 months.
Then anything else that may be required, such as 2 factor authentication or forcing a user to update their password every 3 months.
New Users:
We define a sign up policy, e.g. Only Super Admin type users can add new users to the system, once their details are added the new user will be sent a link by email and asked for a new password on clicking that link.
Users:
We define what happens when someone is no longer allowed access to the software. One approach might be to stop their access but keep a record of what they have done by not removing them from the software completely.
Ex Users:
We define what happens when someone is no longer allowed access to the software. One approach might be to stop their access but keep a record of what they have done by not removing them from the software completely.
Tracking :
TrackingDo you want to keep a complete record of who did what and when or just the last changes made?
You can probably see that this section is going to be the most time consuming part of the project scope. Here are a few more tips:
- Keep everything organised using good headings and sub headings.
- Keep referring back to the objectives of the project to make sure you are staying on track.
- Diagrams and mock ups can really help. A sitemap or flow chart can make sure you don’t miss out on the details needed.
- Remember some of the other common parts that need to be covered, like hardware you are intending to use. Browsers are worth concentrating on, especially if you can cut down on the browsers the software needs to work on as this can cut costs both in development and testing.
- Remember who you are writing the scope for.
- Check and revise this section a few times.
A side note on phased projects. The project scope may only cover one phase of a many phase project and there is some merit in adding in a brief note about future phases. In software development it is great to have an understanding of the overall project so that enough flexibility for future phases can be built in from the start.
Review and Approve
It is good practice to get the whole project team to review and approve the scope before passing it to relevant members of your organisation for sign off. If you make someone physically sign it off they will pay more attention to what they are signing.
This is the basics of what can be fleshed out to become a Software Requirements Specification, which is something we write at the start of every project, read more about that here and of course contact us at any point if you need some help or guidance.
What’s Next?
In our 4 Point development process, the specification is step 2. Then we move onto the Development and Testing Phase (Full Metal has been selected among the Top Software Testing Companies by Designrush) followed by the final Deliver point where everyone’s hard work pays off and the new software is put into use.
