How we screwed up or learned lessons

4 Great Ways To Screw Up a Project* 

*based on real life story

We've screwed up! And that is ugly truth, we just did it... Huge start-up with great investments is just closed. 2 years of work went down the drain.

No bla bla bla - just solid analysis what was done wrong!

Immersion in the situation

Project type - product start-up;

Software Development Methodology - Agile, Kanban;

Roles involved in project delivery  - System Architect, Team Leads, Developers, Project Manager, QC Lead, Configuration Manager, Build Engineer, Business Analyst; (Dream Team, isn't it?)

Total amount of people involved- 85;

External teams - ROI team, PR team;

Product lifetime - 2 years;

1st delivery to market - after 1 year of development.  

Why we screwed up:

1. Product idea/information about it  was a TOP secret information.

There was No User Acquisition strategy at all. We thought that we are doing iPhone or second Facebook: once it's done, huge presentation and !BANG here we are - millions of followers and users are already in turn to get an app.

Learned lesson-

if your'e startup which is going to be public service start doing some buzz as sooner as possible. Run facebook, twitter, instagram accounts - spread the information about the problem you are going to solve. Spread the information about how exactly you are going to solve this problem. Share first wireframes/screens in order to get first feedbacks! Don't be afraid to go to your end-users earlier. As much feedbacks you get at early stages than there is a bigger possibility you're doing the right thing in a way needed for your target audience. 

2. Software Development Life Circle (SDLC) - it wasn't agile at all! However everyone was sure that it's exactly agile. From the early begging we've followed SCRUM with 2 weeks sprints. However it was fixed price project. As you already guessed, requirements change was a pain in the neck. Just try to imagine - 6 scrum teams are located in different areas, stakeholdersare located in different areas (6 scrum teams  and stakeholders are located in different areas). And there was actually multinational team. It was a horror movie at early stages! Really painful process to change the requirements. But how startups could leave without changes in requirements from sprint to sprint? Nohow! They appear from time to time and SDLC should be adopted for this. We actually did it, however after almost a year of development.

Learned lessons - 

you're hired as consultant who should actually help customer to achieve his business goals. Don't keep silence if something goes wrong. They would say we need agile development however we need to assign fixed price contract. Is this a service with huge amount of users? Is there direct goto market strategy? Is there already defined ROI strategy?Does problem which software is going to solve exist? Was competitor analysis done? If most of answers to this questions are- NO. Don't be afraid to say to your customer: 'We are not ready to sign fixed-price contract yet. Your idea requires deeper analyzes and investigation. Which we as a consultants are ready to provide. In that case you would take part of responsibilities however chance of success in such approach is much more higher!      

3. Huge amount of Roles/People involved in project development - 85!!! Never do this, except you are doing space shuttle. Try to be small as longer as you can. If you need so much people in order to achieve some goals in some time-frames - two cases are possible: you are building spice shuttle or you have problems with Product Management. That definitely means that you don't know what your users exactly need.

Learned lessons-

Try to be small, simple and straightforward. Try to define what are the main features of the app you build. This should be done taking into account value you're trying to deliver to the market. Problem which your end user has. The best case - you're trying to solve something that  nobody solves. In that case, even if solutions are not perfect, users will forgive you a lot. Because you solve some particular problem which exists. You will never be perfect however there is always a lot of room for improvements. In case you are doing something which already exists - you should do it better than competitors, which is obviously. Otherwise there is no need for your product. 

4.  Technology stack. This one is one of the most important aspects of our fail. We used wrong technologies for front-end. Why? See item #2 in the list. There was no analysis at the early stages of the product development. We thought about one really specific feature for implementation of which SilverLight was the right choice.  That was actually mainstream - this feature assumed to be a main business driver. Unfortunately it wasn't. Just two technologies on front-end were needed: html + javascript (jquery) .

Learned lessons -

Be careful during technology analysis. Migration to another technology stack after certain period of development is expensive and painful! On early stages: Try to define requirements for load, scalability. Take into account requirements for performance and user experiences. Also think about your target audience.  In case your target audience are people above 45 years this means that most of them would use IE and install some third party software(SilverLight or Flash) or some plugins will be a big problem for them. And as a result you will lose your users before they actually try the product. Entry point is - think about people who would go through it and how would they react on different scenarios.  Only after this try to figure out which technologies could help you to achieve this goals.  

I would highly appreciate your feedbacks and comments. It's worth to hear some stories from you. Let's discuss problems you've had!