I’ve heard too many painful stories of good early stage startups failing due to delays in software product development. Communication breakdowns, developers gone AWOL, buggy releases and mismatched expectations quickly replace the initial exuberance that comes with a new venture. It’s a hell that neither team creates on purpose, but one which too often gets visited by both.
While failed software development isn’t the most common cause of startup failure (that one is on your plate - no market for your idea - 42%), it stills plays a significant factor in startup failure - with running out of cash (29%), issues with the team (23%) and having a poor product (17%) all potentially stemming from development issues.
When your product enters development, you might be tempted to let the developers do their thing. The first most important thing you can do is to make sure you don’t give in to this urge. Allowing this to happen - or allowing any developer to tell you that is how it should happen - is a recipe for disaster.
Instead, it is time to engage with the development process, focusing on maintaining strong communication, clarifying direction to prevent the project drifting and ensuring crucial time isn’t lost waiting for important business decisions. Communication in any team is a two way process and knowing how to share expectations and keep your project on track is an important step in having your vision delivered successfully.
What follows are a series of rules of thumb that should be enough to provide a broad understanding how you should engage with the development process as a non-technical product owner to ensure your project is getting the attention it needs. First however, in case you need them, a few definitions.
| Waterfall | A now mostly maligned approach to software development where all the requirements, releases and deliverables are agreed before the project begins development. Commonly viewed as inflexible and incapable of adapting to the changing needs of a customer. |
| Agile | A more up to date approach to software development in which priorities are identified, updated and decided upon on a regular basis - normally each month. Results of previous releases and user feedback all tie into a more flexible release process. |
| Sprint | Typically a period of time of about a month, during which a testable and potentially releasable version of a product should be completed. The contents of a sprint are agreed at the start of the sprint and delivered during the sprint, and you should have a functioning (incrementally closer to complete) version of your product after each sprint. |
| Standup | A daily meeting, at most 10 minutes long where all the decision makers needed to make decisions and remove blockers are present and update on their progress. As the product owner and financier of the development process, you need to be here for each one of these. Some outsourcing organisations can use similar daily approaches, like email progress updates or similar options. |
| Requirements | A documented specification detailing how the software should work, I recommend using the one pager format. |
| QA | Quality assurance. A term for the part of the organisation that is responsible for quality - starting with product testing, but also incorporating process quality, continuous improvement, automated testing and more. If you are working with freelance developers or small organisations, it is likely that QA will remain your responsibility and you should plan and ask how this is expected to be delivered. |
| UAT | User acceptance testing. A signoff you make at the completion of the development process which says that you accept the software meets your expectations. |
| Kanban | An approach to managing the different handovers and stages in a software project, initially made famous by Toyota and proven to be effective in managing software projects. |
| Blocker | Any part of a project such as a decision, incomplete feature or handover that prevents another part of the project from continuing. |
A blocker on the critical path will cause a delay in the project and a blocker outside the critical path may do so if not resolved.
Much of the role of a project manager is spent identifying and eliminating potential blockers before they happen to make sure the project flows smoothly.
| Critical path | Any work that needs to be done in a project, which, if delayed, will result in the overall project being delayed. |
Success can finally feel close at hand when developers are working on your project, but the temptation to see code being written as a sign of progress is a false one. Inexperienced developers will always want to jump in and start writing code, but both experienced developers and yourself should know that starting to write code without detailed requirements (via one pagers and designs / prototypes will result in significant project waste and delays.
A typical software project should be broken down into four key deliverables - agreeing what is needed (requirements), designing a solution (design) and only once they are both complete should the first line of code be written (prior to this, developers can be investigating potential software solutions to speed development, resolving technical debt etc). The amount of time that each stage typically takes is shown below.
Typical project breakdown:
| 20%: | Agreeing requirements and planning |
| 25%: | Design - prototyping and graphics |
| 30%: | Development |
| 25%: | Quality assurance and acceptance testing |
Assuming your project is broken down into manageable milestones or sprints, you need to set aside a minimum of 2 hours to engage in planning for each week in each sprint. Anything less than this is going to result in wailing, gnashing of teeth and cries of “they never delivered on time”, “they constantly missed their deadlines” and “they spent ages doing things that weren’t needed”.
If this time isn’t committed on a regular basis, no-one on the project will have a realistic idea as to whether the project is on track simply because the required planning isn’t done to tell whether the project can be delivered at all given the constraints associated with it.
Similarly, if you don’t provide the input, the development team will prioritise some, all or none of the right things, and you’ll end up spending time developing superfluous features and wasting time dealing with unnecessary code improvements and polishing.
These types of planning meetings are often painful, but they are necessary to ensure your project stays on track and the most important things get focused on first.
Whenever a developer gives you an estimate that is more than 5 days for the delivery of a feature or part of a release, know that the estimate will often be off by upwards of 200-400%. The longer the estimate, the greater the risk of error. Time estimates should be broken down into days and half days, and a generous provision of buffer / contingency time need to be allocated too.
There are other techniques (like points rather than time based systems), but any approach that doesn’t break down work into to a similarly low level of granularity will be error-laden guesswork at best.
If you patiently wait till the end of a sprint and are surprised that the deadline hasn’t been hit, tough luck. Getting projects back on track is tough, but totally impossible if you let delays build up without handling them over the course of the project. Furthermore, if the first part of a project is delayed, the follow on tasks won’t magically come in more quickly to balance everything out. In fact, more often than not, it means that all of the estimates for the various tasks are under-cooked.
If you don’t know every day whether your project is on track, it’s not.
It is possible, once you know a project is running behind schedule, to get it back on track. Talk to the organisation or developers you are working with to identify what approach best suits the moment. It may happen that some of the available options are out of your hands, particularly when dealing with contractors whose time you don’t directly control.
If you are clear and consistent in communicating your expectation that the project should have the resources needed to be kept on track, it’s more likely to remain so. Telling you your project is late once at the end of a sprint is far easier than having to look you in the eye and give you same update every single day.
| Ways to get a software project back on track |
| 1. Use allocated buffer / contingency time |
| 2. Work longer hours |
| 3. Add more resources (but be careful, this rarely works) |
| 4. Change the deadline |
| 5. Reduce the amount the work to be done |
| 6. Reallocate people on the team to eliminate blockers |
Expecting any software product to be completed free of bugs, particularly during development, is folly. Every software project requires testing and it is important for a person other than the developer to test the app to spot bugs that the developers have not considered.
If there isn’t a dedicated tester in your organisation or testing is not covered as part of the contract (hint: they’ll charge an hourly rate for it), then the tester is you. This means it’s even more important to get access to the product early in the sprint. Typically, the core features of any release should be completed in the first 60-70% of the available development time, and the last 30% should be reserved for testing and bug fixing of issues found in testing.
This also means that if you are working with a developer, you need to set aside about 30% of your time during a release to test and give feedback to the developers (or ensure that there is a competent person being paid to play this role).
| Project | Developers | Testers per developer |
| Startup / early stage | 3 | 1 |
| Microsoft Windows | 1 | 1 |
| Space shuttle software | 1 | 10 |
Every minute a developer is waiting for your feedback is a minute that developer could be doing something productive and isn’t. Make them wait half a day and that is potentially half a day on your project that you will never get back. Even if they have other things to be doing while waiting for a response, the context switching cost associated with the change will eat up valuable time and cause delays in your project. Worst case scenario, they switch to another project and take even longer to come back to you.
Seeing your face and getting replies quickly (e.g. via messenger) will build trust and expectation with your developers - trust that is critical to your project’s success. Answer all queries quickly and ensure that you talk daily with your developers regardless of any difficulty that might entail. If they are beside you, daily standups are the norm, with quick follow up for any issues that are identified. If you are working with an outsourcing organisation, remote calls via hangouts or daily progress emails from the project manager in that organisations may be acceptable alternatives - though nothing beats face to face time for keeping things moving quickly.
Optimism can be a fatal entrepreneurial flaw when dealing with development failures, especially when that optimism comes in the shape of a forlorn hope rather than a structured plan to improve product development efficiency. If your first sprint fails, do a postmortem with everyone involved, making it clear you expect a better and more reliable output. If it doesn’t improve, you may or may not be working with a suitable organisation for your needs.
If you wait 3, 6 or 12 months before deciding to abandon a developer or agency - you’ve already told them that you will accept a lower delivery standard without taking action, and the reason for the failure lies with you as much as the developers.
In the worst case scenario, your product isn’t progressing at all, your developers aren’t responding, you’ve spent all your money and you’ve lost most of your hair from the stress of it all. There isn’t much you can do, and if you are already at this point, you may need to cut your losses and start with another provider. It’s a horrible situation to be in and one that I hope to never encounter, but taking a few smart steps early on is a good way to ensure you are insured against the worst possible outcomes.
A few smart decisions when establishing a relationship will help mitigate the damage of a bad situation:
When signing your initial development contract, you should ensure that all IP belongs to you, including all assets and code used when creating the app. Make sure all these assets are saved in a repository (a place code is stored, e.g. Github) that you own as part of each release. Before severing the relationship, find another developer who can confirm that all the resources needed to continue the project are indeed available by compiling/running the code.
The second area you may need to protect is your customer data. This one is harder to protect as you will have to have a technical person able to work with the data and back it up or transfer it as necessary. All servers, databases etc should use logins and passwords on machines you own and pay for from the start so that you can update them quietly overnight if necessary to prevent malicious access to your user’s data.
If you are creating apps for the app store, make sure from the start that all submissions happen through your company app store accounts and not your developer’s. This means they can’t take the app down if you decide to dump them in favour of someone else. The same holds true for domain names - you should always register and maintain ownership of these yourself so that they can’t be held against you should the worst come to the worst.
Typically though, good communication even at this late stage can help keep the nastiest of the nasties away, with both sides clearly recognising that the partnership isn’t a good one and needs to be changed. There are a great many reputable development houses to partner with and the best ones (though more expensive) will have the experience and processes in place to make your project a success and will continue to support it throughout the lifespan of your product.
Have you faced one or more of these situations? Do you want to talk about how you can partner with the right companies? Do you have any companies you would recommend as providing truly exceptional development outsourcing? Catch me on Twitter or at dave@fluidui.com and let me hear your story.
