Scope Your Software Project for 100% Success
Define Your Software Requirements and Achieve Better Results

Download the PDF version of this page for easy printing

Customers often say to us that they are unsure how to understand how much implementing the vision of their new software will cost or how to understand what’s involved. 

This article on the subject of scoping studies is designed to help you understand why you might like to formally scope and define your next software project.

Purpose

If you are not familiar with the process of defining or commissioning software, it can often help to enlist the help of an expert in defining requirements.  A good way to define requirements is through a scoping study. 

Strong requirements invariably lead to better project results.  They serve to set expectations as to what should be delivered and what you vendor needs from you in order to help them deliver.

Essentially at the end of the day what you get out of it is a set of documents that you can either make a decision to do nothing, put together an invitation to allow vendors to bid for the work (and managing this to create a good level of competition so that you get the best deal is important – and we would like to be one of those bidding), or you can ask us to go forward from the scoping study an deliver a final implementation.



(Click on the image to view a larger version)

Comfort Zone

A scoping study is designed to hit the comfort zone between the “business” and “technical” worlds – i.e. it is supposed to be technical enough to help technicians understand the way the software should be built, but non-technical enough to help non-technicians understand the purpose and functionality of the software.



(Click on the image to view a larger version)

The Scoping Process

The scoping process is one of facilitation whereby your requirements are gently extracted through a number of day-long technical interviews between a consultant and yourself.

The process is always conducted face-to-face in person, and usually at your offices.  The reason for this, together with the reason why the interviews take a day is that this is the best way to develop a mutually-agreeable working relationship. 

In addition, facilitating an intensive level of concentration over a short period of time tends to allow both parties to get to all of the “edges” of the problem and truly understand the requirements.

The scoping process takes between three and four days for a project with a budget of approximately £50k.  The smaller the project budget, the fewer days are required and vice versa.

The Deliverables

A scoping study will usually have these deliverables:

Scoping specification – this document describes all aspects of the application and is the one in which the requirements are defined. 

Technical appendix – this is a separate document that describes the technical environment that exists, the technical environment that you wish the application to operate in and another other technical points and issues that will be helpful for anyone looking to bid for the project to understand.

Draft timetable – this document defines the key milestones defined within the project, including delivery phasing.  This may include calendar dates if the customer is able to offer these.

Briefing session – the final day of the scoping study is a briefing session to ensure that everyone is on the same page with regards to what is to be delivered by the project.

The price – this is the amount that you could expect to pay if you were to commission the project to be done.  If you were to ask us to do the scoping study, this would be the exact price that you would pay if you commissioned us to implement your project.

For the business, the “fixed price” element of the scope is immensely valuable as it answers management’s question of “how much will it cost?” 

"What's Next?"

There are two big advantages to the business that commissions a scoping study.  Firstly, the business is able to answer the question of “how much?”  Secondly, the business is in a far stronger position to go out to market as more information in this instance really does offer you more control.

Of course, when you have a final price for the project it is possible to make a decision that the cost/benefit ratio is not high enough to support your business case.  In this instance you simply put the output of the study in a drawer for a later date knowing that you have almost certainly saved time and money by avoiding a “albatross” of a project.

If you do want to go ahead with the project, you can choose to either commission the company that did the scope to do the implementation, or you can go out to find a set of vendors to compete for the work.

Any software vendors looking to pitch for the work now have a more constrained framework in which to operate.  This is a good risk control point – the reduction in ambiguity in the specification greatly reduces any misinterpretation by the prospective vendors.

Whatever you choose to do next, you can be assured that commissioning a scoping study has put you firmly in the driving seat of your software project well before it begins in earnest.

Download the PDF version of this page for easy printing