Around 2-3 years ago, we were struggling to improve our business processes and implementation of custom development projects. It’s no wonder that IT projects fail at alarming rates like at almost 80% due to several factors. Some biggest factors can be nailed down to communication, testing, specifications faults etc.
So how we covered this distance from
to
?
Here are few things where we focused all our energy during the course of these 3 years.
- Collection of data – If you’re trying to increase your success rate – you should start by finding out the reason why the project failed in first place. Back in 2006, we started collecting this data very seriously. After the project completion, we sat down and analyzed if project was success or not, if not, why it wasn’t successful, what were the main pitfalls and how this can be avoided in near future? It was hard to do at beginning but this gave us a new vision about where to focus our energies on.
- Specifications – Our study from previous point concluded that having a bad documentation or not enough information on the project was the biggest fault why our projects failed. In order to avoid it, we started focusing more on the requirements specification as provided by client. We used to discuss every possible source of technical issue once we started the project. Spent 2-3 days on discussion of requirements, database design and things like that – so in a way we minimized potential issues we could see in future.
- Reusability – This was personally my best one – and it ended up saving tons of time and cash on development. As we begin implementing more and more projects, we started building our reusable libraries and huge code base which helped us delivering these project in less and less time. It did not just saved our development costs but also reduced the risk of our projects drastically because a particular feature or module was already being used by hundreds (if not thousands) of users already. Now most of the feature a client asks for in our custom web development services, it’s likely that we have them deployed somewhere already. So this ultimately helped reducing our failure rate.
- Automation – As they say ‘Defect prevention is better than defect detection’, When I first looked into it, I said to myself “maybe automated testing is just for the big companies like Microsoft”, but over this time as we developed our reusable code base I could see it becoming a necessity. And that when we started developing tests – it was an investment of time which has paid off very well. When we knew we had spent ‘x’ man hours on a feature and we knew it was working all the time with the help of automated tests – we could do business with more confidence and focus on several other parts of project development which required our attention.
- People – Keeping your developers motivated in a project is good for project all the time. When a team believes in their work, there’s a lot of positive energy in surrounding. Though it was barely a problem with us, but we tried going next level in involving our developers to know about the client’s requirement and what users want from the software they’re developing. Again, this increased the development time, but we could afford it.
We still see a room for a lot of improvement for the next level as we collect data. Thanks for reading.
Abhimanyu Grover
