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 youll 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 questioned about the competition, although using slightly more flowery language images of six year olds 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 projects 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 of 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 can not make up for shortcomings in these more important areas. Again, if youre embarking on a road trip, the best maps in the world will not help if you have no car, drivers 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 3% 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. Copyright 2006 Patrick Gray |
