Welcome back to the GreyLoud University. This is the third in my series of articles on ‘How to Ensure Software Project Success'. By following our course you can gain the benefit of our experience across many projects and thousands of hours of development work.
Here I am going to show you how you move forward from the initial set of confirmed Solution Requirements to firm up the specification of the system or app you want to build. When I say ‘firm up’ I mean that you will add more detail to the requirements, come up with a tighter cost model (by feature), rationalize and check the prioritization of the requirements and formalize the user and system flows – and cross check. You also will need to settle on a final choice of technology option. The result will be the System Requirements Specification.
Before I do that, I’m just going to remind you that you are in an iterative process and you will very probably come round this cycle again as you learn in more depth about what you can and can’t expect to achieve in the initial build. For example, some really great features might require third party technology (such as ‘middleware’) or have a build cost which would price the final product out of the market, or which your budget will not stretch to.
Decide what really matters: Prioritize the requirements
Now you have the information about the solution, the cost estimates, the Business Analyst will liaise with you (the client) and will help you prioritize the requirements. This is where the Business Analyst adds more value. You are not throwing anything out at this stage, just confirming the functionality that will be built in the first version – and that it is within budget. Other functionality may be delayed until a later version.
To ensure both budget and timescales are achievable you go one step further and prioritize the functionality within the first version. In an agile ‘scrum’ development process the build is made up of a series of sprints – or development/test cycles building out functionality progressively – delivering additional features sprint by sprint. If you set clear priorities within the version 1 requirements then development snags need not cause delays – you just reschedule the ‘desirable’ items for a later stage. This means that the MVP (minimum viable product) is achievable within the timescale and you have all the ‘must have’ functionality in version 1.
Sharpen the focus: Formalize user and system flows then cross check
In this step, you or your development partner will formalize the user and system flows - in simple terms how the user will interact with, say, the video streaming app, and how the datastream will be delivered and presented on the target platform(s). This check covers all the users, including your support desk and managers – maybe even the finance users on the billing side.
More nuts and bolts: Technology options
Taking a video streaming example, the broad architectural options would range from using a simple server to using a CDN (content distribution network). The options will need to be considered right through the application to the presentation layer and user interface (‘UI’) on the target platforms. These will need to be assessed with the pro’s and con’s (including risks) – and costs – being identified. If, for example, the Business Requirement is to deliver a video stream to the iPhone platform only, then there are Apple-specific options which may be simpler to implement.
Some options may be more costly initially but would enable a shorter implementation timescale. This could give you earlier benefit flow - revenue or business efficiency gains – maybe both.
Requirements and cost: How much for this video catalogue view format?
This work is usually done by the ‘Technical Lead’ – the senior software engineer on the project, someone who knows that the devil is in the detail – and that the last 5% of functional nicety (say a particular ‘should have’ video catalogue view) can be the most expensive to build. This costing is usually done by estimating the amount of work involved in each piece of functionality, not forgetting that the functionality has to hang on an architectural framework which may have a cost – and that will depend on the technology to be used.
Depending on the particular project it may be that a range - ‘low’, ‘most likely’ and ‘high’ estimates will be produced, and they may be produced against a range of technology options.
Rolling up the costs: Final estimate
All these costs are then rolled up into the final estimate.
This is a critical checkpoint, where you confirm that the user and system flows match the product vision – and that this budget is acceptable. Some changes are often made at this point – better now than later. You might have to drop one or two functional niceties from version 1 and schedule them for a later version when your app is earning its keep. However, it is at this point that you should expect to commit to a specific technology option.
Closing Remarks: Your product vision has crystallized
So, you now you know what you will be getting (at least in version 1). Not only that – you have confirmed the content and fined tuned the solution requirements specification. You should also have an overall cost estimate for the whole project, so you know what you will be getting – and for how much.
In the next article I will be looking at the next step along the path as you discover how to ‘Ensure Software Project Success’ – when the first prototype is built.
Follow us and be sure you don't miss it!
