When you decide to start the development of a project you are reading lots of articles and books about how to make it right. Usually, it’s the success stories that people are reading and are searching for the magic formula of what startups did right and are not thinking that these startups maybe just didn’t do wrong things.

We have been working in software development for almost 7 years now and over this period there were successful clients that became huge corporations or were bought out by big market players but at the same time there were projects that were not that lucky and lost their investment, gave up on their idea, chose a different way to resolve the problem.

And since most of the companies are afraid to tell about such failures (and we consider client’s failure to be also our failure) showcasing only success stories, we decided to share our experience of bad practices for your businesses connected with the software development.

1. Tech teams and reading minds
2. Lying to yourself about deadlines and budget
3. Aiming for perfect product
4. Aftermath

Tech teams and reading minds

Too many vague requirements not well explained.

A client started the development of a pretty big project with us on Time and Material basis and spent 2 years developing it with the team of project manager and developers. The number of the team varied over these 2 years from minimum 1 developer and maximum of 12 developers + the team of QA engineers, designers, slicers, etc.

In 2 years client reached to me with a concern that his investors are not happy with how the development goes because they are spending the time for the development but at the same time not getting a result. Our client wanted to see the working end product. When I went to project manager and logs of work over these two years resulted that all requirements were too descriptive and client rushed team up to start the development based on descriptive requirements instead of spending time to analyze things and plan them before their actual development. And project manager at the same time was never pushy enough to make client follow the procedures within the company.

Even though this fact itself was already painful to the project, client was overpromising to his investors much more functionality that team could possibly provide without checking neither the timeline that scope required nor if the promised functionality was possible at all. As result investors were promised with a big scope and they were not seeing it. And since client was getting pushed by investors, instead of finishing current scope client demanded to stop the work on current scope and start the new sprint (scope) as high priority one. You understand the result of this: no finished functionality only partly finished things that you cannot release or demonstrate.

Conclusion:

• Make sure that team and you are on the same page in terms of how user story will be working in the end BEFORE the development.
• Make sure to check with the team the realistic timeline when the sprint/milestone/etc will be completed and take a couple of days for backup. Even the best team sometimes are too optimistic about their estimations.  
• Remember the golden rule of investors management: it’s better to under promise, rather than over-promise.
• You should take part in forming of the sprint (scope of work for selected period, we recommend not bigger than 2 weeks) together with the team. Join the meeting, tell the priorities, make sure you understand the risks told to you. If no one is telling you about the risks, ask them. You need this info to manage investor’s expectations.
• Your team should give you the Gantt chart using which you can track the progress. If you are using Jira or similar project management tool correctly and follow the agile methodology, they allow making agile reports on progress like burndown charts and similar that should give you an understanding of how things are moving with the project.

Lying to yourself about deadlines and budget

Praying that the team will meet the deadline and budget that you pushed them to accept.

We had a client who made deadline commitments to his end client (we were working as subcontractors in this particular case). This deadline could never fit the scope of work that client initially wanted to go forward with. As a result when the duration of a project for 6 months of development (at least) was presented client was disappointed and crushed since he made promises.

A similar case happened to another client of ours who managed to get funding for the estimation that we gave based on unfinished specifications. However, once the specifications were finished and they got extended to bigger functionality than initially intended, the budget increased almost 3 times and here of course client was furious since money only for initial estimation was raised.

In such cases the human factor plays a huge role, since the team wants to find the way out,  project managers are sometimes building too optimistic project plans and developers are giving too optimistic budgets, trying to satisfy the clients demands when they see how important it is for the client to meet the deadline/budget.

In the end, these optimistic deadlines and budgets never work because development is what it takes and without decreasing the scope maximum you can win (at least based on our experience) by optimizing the project processes, adding additional more experienced team members is only 20%. The rest is the actual time you need to spend for writing the code.

Conclusions:

• Never go with this compromise on timeline and budget. Always keep in mind the worse case scenario.
• You can tell your client or investor what he or she wants or needs to hear to manage their expectations, but be realistic about the situation and be honest with the deadlines for yourself.
• Don’t lie to yourself, if you see the team is not making the deadline, have the backup plan. For example, plan the releases into mini-releases, so that certain functionality can be released without waiting for other things to be finished (read about lean development, it should help you out with how to do this properly).  
• Define the top priority functionality that is absolutely vital for the project from the functionality your project can live without. And put the least for the end of development
• Never promise anything on deadlines or estimations until you receive the final confirmation on those from the development team based on full specifications. No team can give you accurate estimation out of conversation or even the wireframes. Please believe our 7 years experience, accurate budget can be formed only based on the minimal set of detailed use cases and wireframes. All estimations till then are just guessing.
• It’s important not to change your current team to the new one that promises you better deadlines or costs especially in the middle of development. I promise you, the realistic deadlines and budgets are always not the ones within your expectations, they are usually big and expensive and if someone is promising you better price and deadlines, usually this is by sacrificing quality or by missing important things in scope or procedures.
• Remember that 9 women won’t deliver a baby in a month. A woman needs full 9 months. Same with the project no matter how many people you add to the team, well planned and big projects still need their time for planning and architecture development if you want your system to be scalable.

Aiming for perfect product

Too many changes and additional requests during development.

Everything started really well. We spent lots of time for planning, we had over 100 pages of specifications. Designs were also prototyped and we confirmed the budget and the scope. The project consisted of 9 milestones, client wanted the mini-version of uber like app.

What we noticed is that on the delivery of each milestone we faced a huge problem with the acceptance of milestone from the client because he was changing designs and adding things and this was in circumstances of strict deadline where each addition is very painful.

The additions were mainly concerning the change of designs (which were prepared by client’s designer by the way) and we had to reslice things almost every milestone to new interface. This was pushing the deadline forward and finally once three milestones were delivered the client stopped his project due to too many additions that led to extension of budget and pushing the deadline.

Conclusions:

• If you don’t want to wait with writing all those use cases and “all this looks like waterfall and we are in the age of agile, where you can write stories as you go”, go with Time and Material budget scheme then, not with fixed price. Because you need agile budget to keep the development agile too.
• Remember Reid Hoffman’s words “If you’re not embarrassed by the first version of your product, you’ve launched too late.” This means no need to change interface thousands of times during the development, especially if you developed it with designer over a few months.
• It’s a bad idea to start improvements before actual release. First release absolutely vital things, add desirable things later.
• Remember that you might be developing improvements that your users won’t even need.
• You can’t compete with uber, facebook or similar platforms with budgets hundreds of times smaller compared to theirs. You need to be different and this is what you need to concentrate on.  Don’t go into development with $10k for facebook like app.
• Remember that once your app is developed you need to maintain it, service its servers, update to most recent OS versions and API updates (if used) and this will require money.

Aftermath

We learned how to manage each of such situation and when we see it coming we always tell this to our clients and in most of the cases they are very open to improvements and collaboration with us.

We were lucky to meet the customers that were working with us to deal with such failures instead of putting the blame on us, they accepted where they were wrong while we accepted where we were wrong. And we learned how not to make same mistakes together with them and both our clients and us paid good money as result of these failures sharing the negative experience. So hopefully reading this article will prevent time and money losses for you and your team. Be better together.