Your methodology or mine?

You have a strategic project coming up…

…and you have flirted with several consultancies now to see who you might invite to the ball. Some you connect with, some you don’t, but there is this one firm that really gets where you are coming from, and you both want to take the relationship seriously.

But how to take it forward – your methodology or theirs?

What you and the consultant both really want is to build a lasting relationship with your business, but the business probably doesn’t come to your parties!  After all you’ll just nag them to sign off those hefty volumes of “as is” and “to be” statements, Use Cases, user stories, whatever.  Why do we make it so hard on the business?  Nearly all the business managers I speak to express dismay at the size of the documents, their hard to understand structure, and the ridiculous notion that once they have signed-off the document the business world plays “statues” until the system turns up a year later …and a year out of date.

A good follow up question is “does it really matter which methodology we use, if it gets the job done?”  Getting the job done means:

The project delivers the benefits that have been promised to the Board, within the time scales, budget and risk profile agreed.

Is your project methodology designed with this in mind?  …is your consultant’s?

I would argue that unless you are buying a turnkey project from a consultant then you should stick with your own methodology.  It is much easier for a consultant to learn your way of working than it is for your organisation to change its governance processes.

If there is huge advantage to using the consultant’s methodology then make everybody use it for this project and get agreement that your governance processes can be bent a bit to fit, as an exception.

Please bear in mind that a consultant’s methodology exists for only two purposes:

1. It’s the nearest thing to a tangible product that consultants have, and it allows them to differentiate themselves from their competitors; and
2. It is designed to protect the consultant and their reputation.  It fundamentally is not designed with efficient delivery of  your project as the #1 priority.

If the last point sounds harsh, take a look at your own methodology.  The bulk of it is there to protect your organisation on one hand; and the people delivering the project on the other.  Sign-off is all about protecting the people delivering the project.

Project delivery methodologies have been around since Roman times, and no doubt there were different consulting architects all claiming that their approach to designing a spa was superior to their competitors.  I’m no historian but I’m pretty sure that as well as the aquaduct, sanitaton, roads, medicine, education, wine… the Romans gave us the PID.

The problem is that although project methodologies have been modified and updated over the centuries, very little has been taken away from them!  Be honest now – how many of you, when faced with the “your methodology or mine” question opted for some kind of amalgamation of the two?  You probably rationalised it as taking the best bits of both.  Did it get the job done?

…or did it cause a bit of confusion amongst your project team, anger among your enterprise architects, and bafflement in the business?

To answer my own question then – in many ways it doesn’t matter which methodology you use if both of them are bloated and cumbersome and result in slow delivery of a system designed a year earlier.  What is interesting to me is how little of any methodology is focused on making sure:

the project delivers the benefits that have been promised to the Board, within the time scales, budget and risk profile agreed.

As a CIO, isn’t it time you sent your project methodology to Weight-Watchers to lose a bit of the flab?  Can you get it more nimble and focused on getting the job done?  If you do you might find it is the business who is flirting with you, and lets face it – they are much more attractive than well-lunched consultants!