Software projects that go wrong are a project manager’s (and CEO’s!) nightmare. The famous analogy of the differences between what the customer wanted, what was scoped, designed and then finally delivered are legendary. Whilst we all laugh at the cartoons, when software projects go wrong it can be both painful and expensive – for all concerned.
So how to complete the perfect project? Here at Intrepid we’ve used our extensive experience and in-house processes to design steps that can help to smooth the road in software project delivery. By stepping through these processes in turn, or just using one of them to help clear issues, you can enable much more successful delivery.
1. Proof of Concept (POC)
There are often technical unknowns that can cause significant issues and delays during the project build out phase. By performing a proof of concept, any technical risks can be mitigated by proving the feasibility of potential approaches. If all difficult technical questions have been answered prior to beginning to build a system, then stakeholders can be confident that unknown or unforeseen issues are far less likely to derail the project. This approach allows a client to see early validation before investing additional resources.
A prototype is the next level of technology discovery after a proof of concept. While not a fully fledged production application, a prototype is a customised solution that allows demonstration of the concept to users, clients, investors or other stakeholders that shows the core functionality. Choosing to build a prototype is useful when a client is considering a larger software project but wants to reduce risk by making sure all technical challenges have been proven. Another reason may be if a client needs to perform market validation and needs a working version of the software to show potential users or simply wants to validate an assumption and prove a use case for themselves.
The benefits of a prototype are that clients get not only to see, or show their management, that a concept works but also a get glimpse of what a full production level version would be like if it was built. A prototype further validates a position, reduces technical unknowns (and therefore risk) and provides early validation before fully investing in a full production level build out.
3. Technical Software Road Map
With all assumptions answered, technical unknowns solved, risks mitigated and concepts understood and validated it's time to consider a full production software build out project. However, it's still not a good idea to jump straight in. A technical software road map provides a credible, well scoped and phased implementation and delivery plan that allows a client to see, up front, the clear direction of a project before proceeding. The road map also provides a framework for a project manager to schedule milestone progress checkpoints with all the right stakeholders to ensure a consistently smooth delivery.
The road map should not stop with the software delivery phase, infrastructure design, application hosting and an ongoing maintenance service should also be considered and planned for.
Why go through the above steps of the process and not straight into build? We believe this is a far more cost effective way of successfully delivery software projects. By fully understanding and mitigating the technical risks, scoping the requirements correctly and then testing them fully, the project is far more likely to succeed. It’s about de-risking the process, as well as being highly cost effective.
Want to find out more about how we can de-risk your custom software projects? Intrepid has discrete offerings for every step of the process outlined above and over the coming months we'll be outlining these elements in more detail - but do get in touch with an Intrepid expert to find out more.