Implementing a methodology – 10 do’s and don’ts

An old friend sends me the outline of a delivery 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 perspective, interests and needs.
    1. 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 in the case of Agile, role).
    2. I personally trained more than 800 people in methodology at one client this way, and they grudgingly agreed that it was money well spent.
    3. 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.
    4. The training has to be full of useful nuggets (e.g., 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/leads 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.
  3. Build the process for tailoring the process into the main process (e.g., in release planning or Iteration 0 ).
    • Make it a high priority item in training (for senior management too).
    • Reward managers for being insightful and innovative.
  4. Scale the methodology thoroughly.
    • E.g., a one-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.
  5. Make the waiver/exception process as simple as possible:
    • Quick, clear lines of authority (ideally as local as possible).
    • If you give the team radical autonomy as to process (e.g., if you’re implementing Agile), also ensure their accountability for results. No authority without equivalent responsibility.
    • 5 questions maximum. 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?
    • Rapid response guaranteed.
  6. Ensure that the methodology is properly owned:
    1. There should always be someone to go to for a decision on what is really meant or needed by a specific procedure or item, or to approve an exception.
    2. 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.
  7. 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.
    • Methodology SMEs also provide a powerful conduit for communicating new ideas between groups.
  8. 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, self-help, 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.
  9. Build an effective lessons learnt system that completes the loop from team experience to the methodology and back (through rollouts and training) back to projects.
  10. Finally, pure stick:
    • Tie their pay, promotion 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!”

By |2018-03-20T13:40:25+00:00Monday, June 8 2009|Categories: Agile, All, Bureaucracy, Process and method, Quality, Waterfall|0 Comments

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.