Reason number 1 for project failure: poor specsSubmitted by Hans van Nes on Thu, 17/03/2011 - 17:00
I was raised in an IT World where we focused on specifying the business needs before we started to develop. We prided ourselves being Information Engineers: translating business requirements into structured specs which even allowed for automatic code generation. Maybe at bit laborious at the outset, but in the end kicking out what the organization wanted. Current studies show that the biggest reason for failing projects are wrong or incomplete specs. So where did we lose paying attention to specs? My top-3 of causes.
Cause 1: the rise and fall of CASE-tools
Where are the integrated CASE-tools? In the hay days of the tools at the end of the last century, 4th generation tools showed remarkable quality and productivity. Yes, CASE-tools with the right methodology and the right people really worked. But that also implied the weakness of these solutions: rigorous procedures, well trained staff and thus rather high investments upfront. I remember a quote of a CIO at a bank: "My only development street that really works and has a tremendous output." Needless to say that I had fought many battles which the same CIO explaining why our tools and people were "accurately" priced….
Are the CASE-tools gone? No, there are still a few around even a few new ones riding on the Agile trend. But I think the real development in the tooling halted. The specs we made to allow for automatic application generation were rather technical in nature. Development made sure that the tools could manage new demands like web functionality and SOA but in my opinion did not show an evolution in terms of intelligent requirements gathering. Of course there are myriads of standalone gizmos for mind mapping, use case collection and prototyping but nothing integrated which what now should have been a 6th generation of CASE-tools.
Cause 2: ERP
With the massive introduction and success of ERP-solutions, the need for specifying you detailed needs rapidly disappeared. Yes, requirements planning and gap-analysis were introduced but satisfied themselves with a rather shallow functional analysis of the requirements. Often just enough to satisfy the business case for the ERP solution, rarely deep enough to know upfront that all "works as designed by somebody".
The main reason for many of the ERP implementations going true the roof on implementation cost and time is the lack of detailed business specification. To make the right decisions on installing, customizing and tuning your ERP-modules, detailed specs are a pure necessity. Let alone for converting and loading your legacy into the new ERP. Master data management was not by coincidence one of the functions of the leading CASE-tools.
Cause 3: IT-Management
Good developers used an accepted the specification procedures and tools, mediocre ones found a lot of reasons not to. Management should have intervened but didn't for many reasons:
- The good developers moved on and the mediocre ones staid
- The IT staffing and consultancy firms were never interested to invest much in advanced capabilities
- IT Managers never used advanced integrated technology themselves
- Integrated tools and solutions were expensive and were easy targets for direct cost saving
- The providers of tools became part of the big IT league and lost both their innovative powers and the ability to convince the IT Manager
- Shifting focus from make to buy to outsource
- There always was a budget to fix the failures after the point of no return was reached
Cynical? Ever commissioned the build of a house yourselves? Would you do it a second time without proper specs?
Ever seen any engineering project started without detailed signed and sealed blueprints? Why is IT so stubborn still not to adopt the same rigorous approach?
Let me know your thoughts.
back to top more blogs