Implementing a methodology - do's and don'ts

An old friend sends me the outline of an IT methodology he is being expected to implement by a big client. It’s the usual bureaucratic behemoth and he asks me what can be done to make it work decently. My reply:

"Thanks for this. I read as much as I could bear and skimmed the rest. I can see why they’d hate it!

Going by this description, I had a similar problem at a large client financial services where I spent 2½ years implementing a global consultancy’s not very lovely methodology. They hated that too, but we eventually got grudging support and even commitment.

I guess that you could summarise what I would do as follows:

1. Insist on taking training very seriously – train everyone from top to bottom of the company, tailor the training to their exact needs, and as far as the delivery teams are concerned, don’t let anyone tell you can do this in less than a day for the introduction and a day for each major development stage (or discipline, perhaps). I personally trained more than 800 people in methodology at one client and they grudgingly agreed that it was money well spent. I think this which as because the training included lots of ‘whys’ as well as ‘hows’. That way people were constantly given the message that there really is a compelling reason to do this stuff, that this really is for your own good – as engineers, as professionals, and as people who don’t want to waste their own time or other people’s. The training has to be full of useful nuggets (eg, 40% of all software engineering is waste and rework, primarily for lack of decent processes), war stories, realistic exercises (ideally one big case study) and methods for finding that magic 80/20 position.

2. Encourage PMs to create tailored versions of the methodology for themselves. This is easy and reasonable and builds ownership. Given that it means cutting out waste and rework and building in the uniqueness of local areas, your client should want it too. After all, if the generic methodology includes stuff (as it always does) that doesn’t make sense in a given project context, they shouldn’t have to do it. And make sure that you build the process for tailoring the process into the main process (e.g., as a project initiation activity), make it a high priority item in training (for senior management too), and reward managers for being insightful and innovative.

3. Scale the methodology thoroughly – with a two-page checklist for truly tiny pieces of work, and a serious approach to low-risk work that really does require only a light touch. But never say that the process is optional. It is never optional. It is simply adaptable. Build in get-out clauses for compliance, take the maintenance people’s problems with project-size methodologies seriously, create massively simplified tools appropriate to very low risk situations. Make sure everything is driven by a clear sense that real risks are being managed rather than a formal procedure being complied with. But never let them do nothing – that’s just the thin end of the wedge.

4. Make the waiver/exception process as simple as possible. Quick, clear lines of authority (ideally as local as possible), 5 questions maximum, rapid response guaranteed. I would suggest simple answers to questions like:

• What do you want an exception/waiver from?
• Why do you want it?
• What will you do instead?
• Why is that better than the standard process?
• What residual risks does that create?

5. Ensure that the methodology is properly owned, so that there is someone to go to for a decision on what is really meant or needed by a specific item, or to approve an exception. This is crucial if the system is to continuously improve itself – someone has to have it as a high-priority responsibility to actually improve it.

6. Support users constantly by training a methodology expert or two (one of my clients had 6-7 for 600 engineers) providing training, internal consultancy, project management consultancy, explanations and ideas for quick wins. They also provide a powerful conduit for communicating new ideas between groups.

7. Build an decent wiki (not a fixed website) that provides high-level process flow models to remind people what to do, and which can be drilled down for more details, online forms, etc. This paper you sent me is a prime example of a format people just won’t read – even I felt ill just looking at the endless levels of heading number. On the other hand, it’s not a bad script for a training course, so it’s not wasted. Even something as simple as online PowerPoint presentations are very effective, although they tend to offend web purists! I have a couple I built for Citibank, Churchill Insurance, Amex, Accenture, etc., if you’d like the see them.

8. Build an effective lessons learnt system that completes the loop from project experience to the methodology and back (through rollouts and training) back to projects.

9. Finally, pure stick: Tie their bonuses to compliance with the methodology, as confirmed by an independent assessor. Brutal, unpopular, initially counter-cultural in many companies but amazingly effective. It provides a somewhat perverse way of dealing with the inevitable feeling on the software engineer’s part that they have little interest in complying other than simple obedience to a very dubious corporate rule – if all else fails, fine them for non-compliance. Having dealt with thousands of IT people, I can only say that it has its place in the methodology implementation toolkit.

I dare say that some or all of this could be sold to anyone who a) hated methodology enough; b) had no choice about complying; and c) could afford the likes of me to make it work!"