23 Apr With tech implementations, it's NOT the methodology, stupid
Methodologies are often presented as the stuff of legends. Sit in any presentation by one of the large implementation companies, and by the fiftieth PowerPoint slide you’ll likely be convinced that the methodology being presented will create a flawless implementation, nearly run itself, and eventually bring about world peace in our time.
Each company presents its methodology as unique and special. When they are questioned about the competition, images of six-year-old kids fighting on the playground still come to mind: “My methodology can beat up your methodology!”
Is there any method to all this methodology madness? On some level, a methodology plays an important part in any project. Similar to a road map, the methodology maps out what tasks should be completed during certain stages of the project’s lifecycle, and should provide a “toolkit” of ready-made templates and skeleton plans to save reinventing the wheel.
Like maps however, different methods are more appropriate for different tasks. Just as you would not take a highly detailed topographic map for a drive across the country, any company advocating a “one methodology fits all” approach should immediately be regarded with an element of suspicion.
The dirty little secret in the implementation business is that all of these methodologies are nearly identical. Most are based on a standard Systems Development Lifecycle (SDLC) model, providing for well-defined and demarcated phases from planning and analysis to testing and implementation.
Again, returning to our map analogy, endlessly debating methodologies, or strongly advocating one “brand” over the other, is akin to arguing the merits of AAA versus Michelin road maps. While a methodology can provide a solid overall framework for a project, if you are not comfortable with the staff that will be provided for your project, or do not feel the implementation company has adequate skills, the best methodology cannot make up for shortcomings in these more important areas.
Again, if you’re embarking on a road trip, the best maps in the world will not help if you have no car, driver’s license, or gas.
So what is one to do when comparing methodologies? All of them will sound reasonable, since they all are derived from the time-tested SDLC. However, there are some nuances to be aware of:
A huge advertised benefit of a large implementation company and its particular methodology is the “toolkit” component, with pre-delivered documentation to complement the steps outlined in the methodology. Ensure that this actually exists, and more importantly gets used on your project. When firms are billing at an hourly rate, there is a large incentive to “reinvent the wheel” on every project for the sake of increased billings or resource requirements, even when the company has likely completed similar templates on many previous engagements.
Understand that the methodology alone probably contributes to about three percent of the success of a project. The quality of decision making, talent of the implementer, project and program management, and a litany of other factors make far more difference. Do a little research and you will likely find no implementations that were successful based on methodology alone.
The other side of the coin is that if you find a vendor with particularly talented staff, extensive experience in your implementation area, and an excellent management team, do not let a weak methodology sales job weigh heavily on your decision. A sad fact of implementation life is that many of the components of a methodology will fall by the wayside when the going gets tough, and only excellent management and leadership will save the day.
If a potential implementation partner spends hours trumpeting their “proprietary” methodology while brushing aside questions around staffing or project experience, run quickly in the opposite direction. A methodology alone never makes for a successful implementation.
Previous articles by Patrick Gray
• Patrick Gray: Fire your CIO? If he’s not implementing strategy, show him the door
• Patrick Gray: Five steps to buying the right package software
The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC.
WTN accepts no legal liability or responsibility for any claims made or opinions expressed herein.