How to Reduce Software Project Risk on Your Next Startup

All startups have some element of risk and never more so when you have an idea, but no technical co-founder. Atlas is a bespoke software development company that has acted as that missing technical co-founder for startups in the past and here are our insights on how startups can reduce software project risk if they approach a software development company to be their technical co-founder.

Atlas have been in business for over 10-years and in that time, we have discovered what does and doesn’t work to reduce the risk of software projects failing. We personally favour the agile methodology for bespoke software development and we will explain why, however it’s important to understand that an agile approach to software development can, in some instances, highlight project management issues, but it doesn’t resolve them.

Before diving in to advocate agile software development, let’s first review the traditional method of software development, commonly requested by most of Atlas’ customers – The Waterfall Model.

The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. It originated in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Because it was created in a time when no formal software development methodologies existed, this hardware-oriented model was simply adapted for software development.

Wikipedia

The waterfall model for all its flaws has been used successfully across a range of industries including the military, space development and healthcare. Such industries are tightly controlled, regulated environments where decisions are made by experts and peoples’ lives depend on decisions being right first time. There isn’t any room for,

Whoops, that didn’t work – hide the bodies and let’s try this another way.

This figure provides a visual representation of the waterfall model. You will instantly notice that it’s impossible to return to the start once the software development process begins, and herein lies the ultimate problem with waterfall. Many of the application development projects undertaken this year and next will be started, and funded, by people who do not understand the complexities involved in writing software and do not know all their software requirements upfront. No matter how many software requirements gathering techniques we have tried at Atlas to extract comprehensive software requirements from our customers, if the product owner doesn’t know what they don’t know, they cannot provide the correct information. This is not their fault, it’s unfortunately just a fact.

Now let’s imagine for a moment that the software development team ignores the above issues because the customer is waving a fist full of dollars at them. They gather the incomplete software requirements as best they can and hurl themselves down the waterfall (model) using a functional specification the size of the complete Encyclopedia Britannica as a floatation device. The customer is stood by the waterfall (model) watching and he’s hyped. He’s positive that between himself and the software development team, they’ve nailed down all the requirements and then BOOM, they hit the bottom of the waterfall (model) and begin to drown. Turns out the functional specification had holes in it, and no amount of paddling or bailing water is going to help. Furthermore, the customer has seen a preview of the application and they have a bunch of last minute changes they wish to make.

With the pressure of a fixed deadline, and fixed budget too, the software development team now find themselves having to paddle and bail harder to meet the deadline. They produce a sub-optimal application that exactly meets the customer’s specification, but could have been so much better if only a more iterative approach had been taken.

So this brings us to the agile methodology as shown in figure. Do you think agile is the way forward? Well agile is equally as dangerous if not carried out properly, and certainly isn’t a solution to all the problems outlined here. To work properly agile still requires an overall plan, and plans for each iteration must still be laid down before software development begins. An agile development methodology does ensure that software development is a collaboration effort and shares the risk across both parties more evenly. In other words, the software development team may still hurl themselves down the river, but in this instance the customer is in the boat helping to paddle and bail out water. It’s all about collaboration.

Atlas transitioned the majority of our projects from the waterfall method to the agile methodology back in 2011 and we intend to ensure that where possible we only use agile going forward. Here’s our best tips and tricks that we’ve used to ensure that all of our software projects regardless of size and risk stand the best chance of being delivered on time and budget:

1. If we’re approached by a customer who wishes to create a web application and this is their first web application or they’re entering a new industry we strongly recommend that they create a MVP (Minimum Viable Product) first. Trying to create an application with all manner of bells and whistles is unnecessarily expensive, and usually a disaster in the making.
2. On occasion, we recommend the creation of a proof of concept. This is especially useful if one or more areas of the overall application requirement are high risk due to technical complexity or reliance on a third party system.
3. On from point 2; if we do create a proof of concept we show it to as many people as humanly possible before continuing. If the application is internal, show it to your staff. If you’re looking to sell the application, show it to as many of your potential customers as possible before proceeding. Yes this takes time, yes this is a great deal of effort, but it’s less expensive to discover early on that you’re heading down the wrong path.
4. If a proof of concept is overkill, we always recommend that we at least create wireframes (Balsamiq is our tool of choice unless a HTML prototype makes more sense). Even the simplest wireframes will ignite a product owner’s imagination and make them think about details they might previously have overlooked. Given that a picture is worth a thousand words we make sure that wireframes form part of our iteration plans as they are difficult to misinterpret and can therefore minimise ambiguity.
5. We use a client portal to aid transparency. In particular we make sure that customers can track what we’re working on as part of the current iteration. In Europe, startups seeking to validate their ideas efficiently often turn to MVP development companies, leveraging Minimum Viable Products (MVPs) to minimize risk and ensure effective scaling. We add any potential issues to the portal for discussion as soon as we encounter them rather than waiting for the next meeting.
6. Speaking of meetings – we insist that the key product stakeholders attend all end of sprint meetings to provide feedback. We’re so adamant about this point that we include this requirement in our agile software development contract.
7. We won’t ever get bogged down in awkward contractual discussions. Software development is a collaborative effort with shared risks and our software development agreement reflects this approach. Rather than discussing contracts in detail we’d much rather focus on getting our customers’ application built.

With or without agile the above tips and tricks have saved us 1000’s of hours of wasted software development time. We hope they can do the same for you.