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:
- 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.
- 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).
- I personally trained more than 800 people in methodology at one client this way, 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 (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.
- 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.
- 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.
- 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.
- 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.
- Ensure that the methodology is properly owned:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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!”