Every new development project should start with a requirement specification or scoping phase. In a nutshell, this is the process of understanding the underlying business need and defining how that’s going to translate into a piece of software that addresses those needs in the best way.
But good scoping is a fine art and one that needs to be approached with due care and attention. After all, it’s the starting point for the entire project and if it isn’t done properly it can have a huge impact on the future in terms of timings, cost and whether the solution is actually fit for purpose.
The basic steps
Obviously every project is different but there are some key steps that every scoping phase should include:
- Clarifying project parameters - set out in detail what the problem is and how the project will solve that.
- Detailing tasks and subtasks - break it down and be really specific about deliverables.
- Allocating responsibilities - both internally and externally with suppliers/contractors.
- Estimating time frames - use your task breakdown to estimate how long each is going to take.
- Setting milestones - link tasks, timings and responsibility holders to build a timeline you can refer to at key points.
- Allocating finance - use the work you’ve done to estimate project costs.
These steps will help you cover the basics of a scoping phase. But in our experience, they’re just a starting point. To truly make a project successful, scoping needs three other key factors.
Allocate a key project owner
One of the things we often see holding a project back is the lack of one person who can take responsibility for making tough decisions. For example, which feature of a new development is a necessity and which is a luxury. This is not about project management or business analysis, it’s about authority.
Most projects will have a number of stakeholders inputting their views and each will have different priorities. This can lead to scope creep, which impacts on a project getting done on time and on budget. The solution is to have someone not only with the vision for the outcome but the authority to have the final say on contested issues and keep the project moving forward.
And while we’re talking about personnel allocation, it’s worth noting that this needs to be done internally even if you’re bringing in an outside contractor to fulfil the development side of the project. They’ll need access to your team for everything from discovery to user acceptance testing and this is worth building in from the start. Without the approval of end users, uptake will be low and you’re far less likely to capitalise on your investment.
Build in a discovery phase
In some cases a discovery phase might be the first thing that happens, before the scoping, other times it might blur into the same activity. The most important thing is that there is sufficient thought given up front to define the parameters of a project, while leaving enough flexibility to work out some of the details later on.
It is well worth spending time talking to end users, really figuring out the problem you’re addressing and what you want to achieve. Allocate time and resource to this internally. Get outside experts in to help and give you a fresh perspective on what you’re trying to achieve. Often people can be too close to see the challenges and the opportunities within our own businesses and need others to guide them to a clear picture of the context in which the project will be undertaken.
Work with external technical experts
You know your business and you know the problem you’re facing. You also probably have a fairly good idea about the outcomes you’d like to see from the solution. But as for the solution itself, not to mention the structure and process of the project delivery, that’s where you’ll find it really helpful to get the experts in from the offset.
No matter what your in-house knowledge, bringing someone in from the outside - and giving them permission to question your assumptions - will bring to attention anything that might be in your blind spot. They might have alternative ideas that can save time or money, suggestions that can streamline the output and ultimately help you create something even better than what you could have envisaged by yourself.
We like to say that we don’t necessarily give our clients what they ask for the first time because our goal is to give them the solution that solves their problem in the best way. Choose a development company that isn’t afraid to challenge the brief.
Build in flexibility
It’s natural to want to know all the details - especially how long it’s going to take and how much it’s going to cost - up front. But the reality is that a project’s requirements are likely to evolve and change over time.
Sometimes you’ll unexpectedly hit on a way of doing things that makes the new system better or allows it to achieve more than you first expected. It could be that an important fact comes to light that no one thought to mention during the initial briefing. For example you might ask your developer how a new booking system will work with group bookings, only to realise that you'd assumed that group functionality would essentially be built in, but had never actually specified it.
Working in an agile, flexible way can have huge benefits, not least delivering a more appropriate solution in the end, but it does mean that you’ll need to treat your scoping document as a working one rather than something which is set in stone. For example, you can use the MoSCoW rating system, classifying tasks as must have, should have, could have and won’t have or would like, so that when something urgent comes up you know what to let fall off the bottom of the pile.
As you can see, scoping does have functional steps. But it is the mindset with which it is carried out that is likely to have the greatest impact on the success or failure of the project. With a rigorous discovery phase, the right personnel, technical input and a commitment to flexibility, it is far more likely that you will achieve the former.
