Me too!

The continuous realisation of commercial innovations is the lifeforce of sucessful businesses. Also, there are few things as exciting as innovative and challenging projects. Such projects are critical when dealing with unique business processes, and highly competitive markets. However, many great change projects can be delivered using virtually no innovation and less risky approaches...

If your change project concerns commodity services, non-core processes or highly predictable areas of your business, then a "me too" strategy may be more appropriate than an innovative approach. In simple terms, "me too" means copying the best strategies of competitors or similar businesses in other markets. For example, don't create your own bespoke ERP solution, instead use a best of breed product and implement best practice processes using a standard approach. This strategy has some obvious advantages:

• There will be evidence that this works, and hence less risk involved.
• Other people do it first and you learn from their mistakes.
• You can more easily optimise process and minimise costs.
• The worst outcome is only the cost of a lag versus other players.

It also has some disadvantages. Some of these include:

• It is unlikely to delight your customers - they get this service everywhere.
• If it takes a long time to implement you will always be playing catch-up.
• It gives suppliers greater leverage.
• Higher labour costs and retention issues as the skills required become increasingly popular.

Overall, "me too" is a very popular strategy. Benchmarks show that it works. In the IT industry this strategy has been extensively promoted by the big manufacturers and consultancies, and has resulted in a "herd mentality" leading to the huge growth of the big software multinationals.

The trick for change managers is to understand its strengths and weaknesses, and to achieve the right balance of innovation and "me to", in order to match your organisations appetite for risk and performance.

Not another meeting

There have been thousands of articles on how too hold a good meeting.  However, it still amazes me how few change managers have actually read them.  These are critical skills, so I shall remind you:

• Plan your meeting in advance - set clear objectives and have an agenda
• Cancel the meeting if it is no longer necessary
• Invite the minimum number of people necessary
• Have a clear leader who owns the outcome
• Start on time, even if people are late
• Come with commitment, and engage in good spirit
• Encourage positive contributions and maintain a sense of fun
• Separate facts from emotions, and know when to drill into the detail
• Capture issues and actions - confirm the exact words
• Keep on track and stop diversions, cut people off if necessary
• Finish as early as possible, and seek feedback
• Always update your RADIO, tasks and actions.
• Follow up, follow up, follow up

There are many other good tips, I'm sure you have your own favourites.  Remember that meetings are held to either inform, engage or seek approval, but above all they must encourage and instigate action.

Play it again Sam

Sometimes a simple formula can be used again and again to solve many problems.  In change management you could try:

Rationalise ->  Standardise  ->  Consolidate  ->  Simplify  ->  Optimise

This five step strategy can be applied to subjects as diverse as logistics, manufacturing and computer operations.  For some managers this is the core strategy, and it is followed with almost blind faith.  It can produce big cost savings and operational effeciencies, and it nearly always generates large change projects.   Use it, but use it with care, and note the following areas of weakness:

• Many people fail to grasp the final step requires the creation of a culture of continuous improvment.  Without creating and embedding the "optimise" strategy an organisation can become "locked in" to the ouputs of big change programmes that become static and constraining.  For example - After moving everything into one ERP system, now it is too difficult and expensive to change anything...
  
• By building big process, people and technology solutions this strategy can virtually eliminate the creativity and innovation that comes naturally in small responsive business units.  You must create new ways to tap into this spirit, or loose employee engagement and buy-in.
  
• This strategy tends to lead to big investments, which may not be right for your organisation.

Above all remember that the world continuously changes and moves on.  By the time you have completed a cycle of this strategy, your business or markets may have changed so much that the outcome is no longer right, and a new start is required.  Slightly sub-optimal but agile may actually be better.

On the pitch

When faced with an issue or a difficult situation, it is often useful to ask "am I on the pitch, or in the stands?". Being on the pitch means that you are part of the team and playing the ball (i.e. taking action). If you are in the stands, then you are a spectator, and all your of words and opinions do not matter.

When you see others in the stands, call them down to the pitch, or tell them to cheer. Do not waste time on their opinions. Remind them that you can only score a goal if you are on the pitch! Similarly, if you cannot play the game, then don't pretend to be on the pitch. Get back to the stands and cheer others on.

Stuff happens

When you are managing change, stuff happens. The important thing is not to become too reactive, we must manage the issues and not let them manage us. In order to manage issues, consider this definition:

 A project issue is an identified problem or concern that needs to be addressed either immediately or in the course of the project, in order to successfully deliver the business objectives.

If it does not prevent successful delivery of your objectives, it may not be your issue! Also, you do not have to deal with every issue immediately. Always identify priorities and the "last responsible moment" by which an issue must be addressed. For issue management to be effective the following principles should be adopted on your project:

• All project team members and stakeholders must be able to raise issues, there should be no constraints in this process. Sometimes, people are hesitant because they are not sure if an issue is important. To deal with this consider introducing the concept of raising an "early warning" of potential issues, and put a management process around these.
• Rapid and appropriate action is usually critical to the successful management of issues.
• All issues should be assigned an owner, who is held accountable for resolution.
• Issues must be escalated quickly, if they cannot be adequately resolved at the project level. If in doubt engage your programme / senior manager asap.
• The issue management process must be formally defined in commercial agreements for products and services required by the project.
• Issues often result in scope change. It is important that when this occurs the change process is followed rigourously, otherwise poorly considered scope may be instructed.
• Issues are frequently first identified as risks that subsequently materialise. In this context they can be considered as failures of the risk management process.
• Never allow an issue to divert the team away from work that still can be progressed to quality. Compartmentalise the issue, assess the risk and impact, then focus a sub-set of the team on its resolution. Keep others focussed on delivery.

Keep an eye on these KPIs, to help ensure these processes are working. They are also useful measures to provide to your project board:

• Number of issues without owners
• Number of issues open for multiple reporting periods
• Percentage of issues due to failings in risk management
• Average time to close issues
• Average cost to close issues

Mythical beasts

In 1975 Frederick Brooks Jr. published "the mythical man-month", a series of essays on software engineering lessons from major programmes of the 1960's and 70's. For many years this was regarded as the classic work on software project learning, but today few people seem to read it.

The important lessons apply not only to software projects, but to all change projects. They remain true today. There are many excellent observations in this book, I would like to remind you of just two right now:

* Adding people to late projects only causes further delay.
* There is often a small optimum team size to solve complex problems.

In simple terms, as project complexity increases, project costs escalate and there eventually comes a point where adding further people or money simply cannot fix things. This point will vary depending on such things as the quality of management, experience of teams and tools involved. However, one thing is certain; as you approach this point the only way to achieve your objectives will be to radically redefine the problem and your approach. Anything less just postpones and increases the pain.







Often, one finds that complexity is progressively revealed during the early stages of a project, and estimates are repeated revised upwards. So build complexity measurement into your risk and estimating processes and measure it regularly. Look for the symptoms and be prepared think differently, and to kill these mythical beasts.