Welcome back to the Greyloud University course on ‘How to Ensure Software Project Success’. This course gves you the benefit of GreyLoud's experience across many successful projects and thousands of hours of development effort. We will help you achieve your vision.
In my previous articles about we have navigated the early stages of the software development life cycle (‘SDLC’), and by now you know a bit more about gathering requirements and firming up the specification. Now we come to the prototype – something you and your stakeholders should be able to ‘touch and feel’, something that starts to bring some life to your vision.
Why build a prototype?
The prototype helps build stakeholder commitment and ownership of the solution – an absolutely critical element in ensuring a successful project. Beyond that, the prototype can help uncover technical and business requirements issues before serious budget is committed to a full production build.
The prototype may only be ‘low fidelity’ – that’s jargon for ‘rough and ready’ – but it is of huge significance. Formally accepting it (maybe with some reservations) is a key change of state in the software development life cycle. When the prototype is approved, it demonstrates that:
• Technical risks have been identified and resolved• The Business Requirements have been validated (at least at the summary level)• Users have commented on the UX (user experience - the look and feel)• The base specification is confirmed for the first production build• The stakeholders have bought in to the solution
Avoiding Problems: Technical Risks
Many projects have failed simply because of incompatibility between versions of 3rd party software. Maybe the specific functionality was released but didn’t work properly. That’s just one type of technical risk, known as an external dependency. Then there are internal dependencies, cross project dependencies, performance risks (say where a mobile app struggles to perform when there is low memory availability) – the list is endless.
When the specification is firmed up, the technical risks should have been identified and there should have been solution strategies identified to eliminate or work around them. Now at the prototype stage, those solutions will need to be demonstrated. ‘Show stopper’ is a phrase that says it all. That’s a critical risk that must be resolved at the prototype stage. Ignore show-stoppers at your peril.
But there’s one other risk that can easily be overlooked - the inherent risk in your development team. Do they have the skills? Are they up to speed with the latest technology? You will certainly find out when you review the prototype.
If your application is highly innovative or uses new technology then the technical risk profile may be much higher – and this fact should be explicit. These risks should be clearly and satisfactorily addressed in the prototype. The ‘Leading Edge’ is often known as ‘The Bleeding Edge’ – and there’s good reason for that.
Is it really what you want: Business Requirements
You have your list of approved business requirements – maybe on a spreadsheet or in a database. When reviewing the prototype you will work with a Business Analyst and should be able to confirm the presence of the required business functionality. There may be some snags that need ironing out (record them and categorise them as Critical, Moderate or Low Severity).
It is not uncommon at this time to find that nuances of functionality become apparent and that one or two requirements may need revision – remember the word iteration?
What do Users think: The User Experience – Getting Feedback
The UX is an important part of an application. For example, if you are planning to release a smartphone app linked to an e-commerce store then the ‘shopping experience’ will be important. The person who had the role of ‘remote user’ during the requirements gathering process will need to review the whole experience of using the prototype.
Of course not all detailed functionality will be present in the prototype. For example the full process of a user returning a product to your store – which hopefully would not be a common occurrence. Ensure that all your user representatives – including your support staff – have an opportunity to review and comment on the prototype. They are all part of your stakeholder community.
Setting the foundations: The base specification is confirmed for the first production build
Working with the Business Analyst, you and your stakeholders will walk through the prototype. This is best done in a workshop environment to encourage interaction and help resolve issues speedily. If it’s a large or complex project then this walkthrough may be split into several workshops, organized by functional area – for example Supply Chain, Customer Shopping.
At the end of the Prototype review there may be some issues outstanding and your stakeholders may give qualified approval provided that a clear issue resolution plan is agreed. For example:
Prototype Issue #3: Supplier Order Screen layout does not reflect optimum layout for user input. Severity: Moderate. Resolution: Specific test issue to be created. Comment: this is a prototype only.
All on the same page: The stakeholders have all bought in to the solution
Once the prototype review is complete, then you will have an issues list to be addressed by the development team. Circulate this list to all the stakeholders and ask them to confirm it is accurate for the areas which they have reviewed, and that they formally approve the prototype. Depending on the issues, you may want the prototype to be adjusted or tweaked before formal approval.
It’s worth noting that what can seem to be a relatively minor technical point can have deep-seated ramifications. Usually, the issues are relatively minor but beware of any technical issues which have not been resolved.
Closing Words
So, your stakeholders have all confirmed the prototype and should have bought in to the solution. In larger organisations and/or with complex projects, achieving 100% buy-in can sometimes be a challenge. Managing the stakeholders can be a bit of an art, but hang to your vision of the solution – somebody has to drive progress!
In my next article I will be discussing the next critical step – Confirming the Plan, Technology and Resources. Follow us and be sure not to miss it!
