We have all read or heard and hopefully understood that;
- Inaccurate requirements gathering remained a primary cause of project failure (37%) in 2014……… by PMI Pulse of the Profession Study ….
- IT and Software Project failures are determined by failure in the first phases of any project initiative.. namely the requirements phases.. Projects cannot fail in quality evaluation phase.. it is the requirements definition and management which primarily determines the quality of any software.
- Agile methodologies have proven their limitations in serving the business while delivery is fast, the deliverable is impaired; failing to fulfill the business needs of complex IT projects.
- Outsourcing of IT professionals has become a pillar of the Software Industry whether it is the development team, the quality team or the business analysis team. With outsourced staff or even full time junior relatively more economic resources, the only guarantee to Software Projects success is accurate, complete requirements. There is no other way around this simple fact.
It is no coincidence that almost half of all IT/Software projects are failures worldwide.. Neither success nor failure are coincidental, they are the results of your vision, wrong or correct decisions. Many business leaders are still unaware or neglectful to this day of the key success factors in software projects…And justified by that alerting negligence software projects still fail to this day in meeting their intended business needs . While most studies attribute majority of the failure to inadequate requirements, the percentages may vary from one source, environment, culture, project nature to another.Throughout my 16 years experience as a business analyst and software design definer, I have witnessed -among tens of projects- three relatively large software projects where I raised my hand as high as possible confirming that the start was a definite choice of failure. I had requested withdrawal from these projects because they were failures from the head start.. there was no way to save them unless there was a significant change in strategy.
The First... was rejected by the customer two years after my justified withdrawal .. I guess this is where vision comes in handy!
The Second not a complex project, one that has been developed by many software solutions providers over and over …but has taken in design phase alomst three years … with no clear understanding of the solution or a single functioning service….
The Third … I believe the code was very smart and delivered faster than the speed of light but due to strategic reasons has been truncated into company archives… what a huge waste of money!
Within both private industry and government agencies, the business analyst is becoming the central figure in leading major change initiatives (1)..
It is rather simple but we insist to complicate things sometimes…
Revise your strategy and understand that inaccurate requirements and poor design definition (overlooking the business architecture) leads to IT projects failure in terms of cost overrun, poor quality and customers/users dissatisfaction… not to mention the frustration of every team member on-board..
Enough emails for the sake of God… emails are not a proof of productivity or alignment with business objectives and goals..
Focus on the early stages of the software development life cycle, being the requirements definition, business and software applications’ architecture and specifications phases…and stop jumping into useless code.. fast is not necessarily smart…
Specialization is a key attribute to any success… don’t overload staff with tasks outside their experience or job responsibilities.. you may think that you are saving money but you are losing much more, not just money but also business opportunities and your valuable reputation…
Never blame the executor… they are following directions you have forced upon them.. motivations and bonuses to the development team will not clarify ambiguous requirements.. I hope it could!
The quality of the deliverables of your vendors is the quality and timeliness of your specs..
If your project is estimated a year for example, designate in your plans 6 months out of them for the early stages of the SDLC and you may not even need all the remaining 6 months for development, testing and UAT… it works like magic!
Written by Angie M. Eissa, CBAP, MSc BIT, UK Founder & Managing Partner of Business Borderlines
ef. Unearthing Business Requirements…Elicitation Tools and Techniques..2008… Part of the business analysis essential Library by Rosemary Hossenlopp, PMP and Kathleen Huss, PMP