Seven Tips on Designing & Implementing Methodologies

I have been involved in the development and implementation of many methods in my career. Often these are related to project management or change management, but I have also been involved in the development and rollout of consulting engagement management processes, new product development processes and improved software development approaches.

Obviously I have learned a great deal about this subject. I would like to share some tips about how it is best to approach the design and implementation of different methodologies, inside your business organisation(s), so that you are more successful in achieving your real goals.

A few months ago I wrote an article called Project Management Methodologies: Guidance or Rules?. This article follows on from that and gives further advice on the design and implementation of methodologies.

I have written this from the viewpoint of project management, but much here is applicable to any methodology implementation:

1. Be clear on goals: what are you trying to achieve?

There seem to be three main goals when organisations go about implementing a new methodology in an area like project management. The first is to introduce some form of standardisation, the second is to improve capability, and the third is to improve reliability of delivery.

These are related goals, but are not the same thing by any means. All of these goals have their place in organisations – but don’t fall into the trap of assuming by achieving one of these you will achieve the others. For example, often a standard project management approach is implemented. This has many benefits and usually results in some improvement in the reliability of delivery and may result in improved capability. But if, for example, you really want to improve capability, a methodology alone will not optimise your skills. This needs consideration of your resourcing, how you coach project managers, training, performance management processes and so on.

Start by clarifying your goals and then design your methodology and any supporting activity to achieve these goals. Don’t just think "of we have all sorts of problems in this area and any methodology is bound to sort them out".

2. Design it relative to your organisation’s real needs and capabilities

There is rocket science, there are simple practical tools – and there is every variant in between. Occasionally, you really need to implement a method that uses the latest and most complex thinking. But unless you do – don’t!

The point is that a simple approach will often give you 80% of the benefit for 20% of the effort. Every time you start to think about complex methods ask yourself: how much time and effort is it going to take to train this out and to get everyone using it? The thing about any methodology is that you are designing it to be used by the people in your organisation, and so it has to account for their real needs as well as their actual capability and capacity to learn and adopt a new approach.

Whenever I see really complex methods being suggested I challenge whether the approach is just being designed to cater for those really occasional complex pieces of work. These usually can be dealt with as exceptions. My general rule of thumb is focus on practicality and the needs of the everyday project. Don’t focus on cleverness for cleverness sake.

If I am honest, sometimes the most complex methods seem to be developed to play up to the ego of the methodology designer. There is no value in this for the wider organisation.

3. Be inclusive in designing the methodology

One way to design new methods is to get a group of wise men and women, and take them off to a meeting room or dedicated office. They sit in this office for some time, without talking to anyone else in the business and design the ideal method.

This can work, but I advise you to avoid this way of working if you can. Sometimes to get the focus and effort to develop a method this is essential. However, a more inclusive process of working on the development of the method on real projects going on in your organisation is usually better. This will both ease the change management challenge when it comes to roll out and give you access to a far wider pool of ideas. Lots of people have great ideas that will add value to your methodology.

4. Build in time for testing

With any new processes, tools, practices, templates, approaches or anything else you may change in the way people work – designing it on paper and using it in anger are very different. Even the best design approach in the world will forget some aspect of real life that will cause problems when the method is implemented. Problems can be gaps or omissions, excess complexity, or trivial things like the size of writing on a form, or the performance of a part of the method delivered over the web. Whatever the problems are, they can mostly be resolved by taking the time to test the methodology on some live projects and then fixing any problems raised.

Failure to do this will just lead to problems in real life. If the methodology does not work when it is first rolled out you will lose people’s confidence and face an uphill battle to get it accepted.

5. Work out how you will measure and monitor success

There is no point taking the time and investment to implement a new methodology unless you are confident it will be successful – and know when you need to intervene to make it successful. This means you need some way of checking up-take, compliance and ideally benefits from the new methodology.

If you are implementing a method in a small team then this can be done informally. But any large scale methodology implementation needs to consider governance as well as quality management of the methodology implementation itself.

6. Implementation is a change program – sometimes a big one

Rolling out of any significant methodology is a non-trivial activity. If you expect to just design it and then people will use it, you are mistaken! As with most other types of change, many people will resist a new methodology and ignore it for as long as possible. Some stakeholders will be very cynical – often including some important and powerful managers. Unless you actively assess and manage support and resistance, you are likely to struggle to get your methodology implemented.

When you are rolling out to hundreds of people, then it is not only a change project – but a fairly big one!

7. Think from the start how the methodology will change and evolves

Generally, you won’t get your methodology perfect from day one. In addition, even if you are clever enough to implement a really great methodology, someone will soon identify an improvement. You should put in place a simple, lightweight and easy way to get suggestions reviewed and included within the methodology. It’s always awful when improvements are either ignored, or subjected to an overly intense and long winded change control process. Embrace continuous improvement.

Generally, the changes suggested will not be to the basic shape of the methodology, but will be tweaks to various assets, such as templates, the methodology uses.

Embracing continuous improvement in methodologies is partially about attitude, but it is also about lots of practical details. For example, don’t produce a fabulous and expensive hard copy of your methodology – at least not with all the details. If you do it will soon be out of date and making changes will be very painful or impossible. Design it so tweaks can be included, communicated to the user community and rolled out quickly.

What’s Your Experience in Developing Methodologies?

This is a topic I find very interesting – and I would love to hear your views or experiences on designing and implementing methodologies. Please share them with us at Corporate Geek. Also, if you are interested to read more about methodologies, don’t hesitate to check the articles I recommend below.

Related content:

How to Align Strategy and Delivery in a Business Organization
Best Practice, Continuous Improvement and Progress in Project Management
Project Management Methodologies: Guidance or Rules?

- nice2 - sales1