Man, have I heard some horror stories lately – deadlines missed, functionality incomplete, millions thrown away. Sure we’ve all heard about similar situations and all know we need to apply the discipline of project management and develop a thorough understanding of user requirements to minimize the chance of failure. But perhaps it’s time for some folks to take a hard look at themselves, to see whether they – and not their vendors or vendors’ technology – are entirely to blame for the failures of certain systems implementations.
This is all of course old news to the tech savvy out there, but my mission, with this blog and in general, is to communicate to those who are not terribly tech savvy that there are reasons for frameworks, disciplined approaches, software development lifecycles and other forms of best practice. The cynicism most have toward many of these methodologies is no doubt a function of the misuse or misapplication of them that resulted in a bad experience. To be sure, one vendor I know of promotes the use of Agile development methods in their deployment of enterprise-class systems involving complex insurance operational processes that involve offshore development teams and multiple integrations with third party systems. To me, using an Agile framework for such a project is non sequitur – the remoteness of the development team alone sort of mandates the creation of fairly detailed requirements documents – a mandate that directly contravenes the Agile philosophy.
The lesson? Get to know more about these frameworks and insist that your vendors use them properly. Make an inquiry into vendor methodology a major part of your RFP process, and insist that contending systems vendors provide vivid descriptions of the approach to the project they propose to undertake. Further, make sure your own organization is prepared for the change that’s associated with adopting a vendor’s framework, and remains committed to the approach. Sometimes, a good look in the mirror goes a long way.