We’ve already talked about how a fixed budget, scope controlled engagement model can help you manage software project risks. I’d like to give three more quick tips that cover some other important aspects to reducing risks on software projects.
There’s lots of angst when things don’t go exactly as planned. That can cause:
Unneeded pressure on the entire team.
The key is agility.
Take small steps, learn as you go, and refine scope along the way. Fortunately those are elements of the Agile model that we employ at FrogSlayer.
In this vein, clients should consider developing projects along the MVP model, which is very common with many of today’s tech startups. MVP means Minimum Viable Product, which is the minimal acceptable solution that solves the core problems.
MVP may not be totally pretty, may not have all the bells and whistles everyone wants, but the MVP should address the core pain points that led the client to want a custom solution in the first place.
DON'T FORGET THE USER
Involving users early, and often, is another important tactic.
Again, this is another feature of Agile development that we employ.
Involving key users in the design, and letting them evaluate small chunks of the solution in phases rather than the whole finished product, ensures that the development team is building what the client ultimately wants rather than what the developers think they need.
In this area, integrating the client into the developers’ tools is important to getting the right results.
This means access to:
The development team via email, voice, and video as appropriate.
Integration into project management and bug tracking tools.
Typing into other productivity platforms helps clients and developers work as a team
Even with some of the best practices we note above, there will be still be technical risk that may not be totally visible at the start. It may be in the choice of:
Response times and performance standards set for the project
Integration with partners' external system
Whatever they may be, technical risks can be mitigated through extensive research and building a proof of concept.
Research may find that a similar project in the industry reached a technical dead end due to architectural issues of the preferred platform. A proof of concept, which might be a minimal MVP, may help to assess complexity and to see how layering on many more features and integration points will affect the overall solution that the client wants.
A key feature Agile is to release features often for users to evaluate and test.
The important part to this is that developers have a deadline and feature delivery to work against that reduces churning on the same thing for weeks on end when one aspect of the solution may not be working right.
It also can encourage clients that see bits of progress over short lengths of time. No methodology or framework guarantees success in a project, but breaking things down into manageable chunks is an important element in delivering a successful project.
Often this phased release process identifies parts of a project that need to be deferred into the future or jettisoned entirely because of technical difficulty or simply being not worth the cost.
Before you engage with any software development team, be sure to consider the risks of building custom software and the firm’s approach to de-risking your project. If they try to push all of the risk on you then just walk away.