Interests - Organisational Change Management (OCM) / Business Transformation Management

 

This webpage is under construction and will be published under http://www.lulu.com/uk/publish/books/?cid=nav_bks

ISBN: 978-1-4710-8568-0

Introduction

I have been passionate as an organisational "change practitioner" in various degrees for most of my professional career in Design Engineering and Management consulting.

 

My passion was accelerated in 1990,  during my M.Sc. in Organisation Integration and Computer Integrated Manufacturing, at the CIM institute, Cranfield University, Cranfield, Bedfordshire, UK.  

Fortunately, Cranfield's CIM institute recognised the importance of teaching the 'soft stuff' together with the 'hard stuff'. Our professors told us, students;

 "You can't successfully integrate  IT/IS systems or production systems without integrating the whole organisation first"

 So luckily we had the pleasure of Dr. Victor Newman as a lecturer, who is a renowned military and industrial Physiologist. He is an author of books on organisational cultures and during my time in Cranfield Dr. Newman used us, students, as 'guinea-pigs' to help him to fine-tune his latest problem-solving processes and team-building theories; which he also built into our courses and then later published in his books:  Made-to-measure problem-solvingProblem-solving for results and  The knowledge activists handbook.  I strongly recommend putting these excellent references into your "change practitioner's" and project manager's toolbox.

A door into industrial psychology, organisational cultures, management trait theories, team building  problems solving was opened up for me. I put these to the test during my final year's thesis in 1991, titled " A Systemic Approach to System Integration"; sponsored by Haburton Geophysical Services in the UK. 

As a hard core engineer, this opened up an exciting new door for me.  

Since then,  I have built up many years of experience as a management consultant and key account manager responsible for many project agreements within various industries. Was employed for the last 15 years by a leading Norwegian consulting company as a change practitioner within international SAP projects in Europe and various other IT/IS projects in Norway.

I have now started my own consulting practice based in Germany in the Euroregio border area.

Objectives of this webpage

I have found that keeping a daily blog of my experiences,  whilst working as a change practitioner,  has helped me to review key events in a structured way. Using some of my own medicine enable me to identify some root causes of certain successful events and some failures as an important learning exercise. 


Some of the relevant professional experiences I've added here, including some of my own theories on what I think Organisational Change Management (OCM) should be about.   

 

Many change practitioners, consultants, and senior managers have seen too many business transformations & change programs stumble into some sort of success and far too often into failure.  When running the 'lessons learned' workshops we normally already have recognised  99% of the ideas for improvement. We already knew these before the project even started. Why is this?

 

It is often quoted that 70% of all change programs are failing and the figure is increasing.  Just because these are the statistics, it doesn't necessarily have to be that way, as long as you are getting good advice and the client organisation takes heed! 

 

So why are change projects actually failing? 

Hopefully this webpage will give some answers to this questions. I start the discussion by reviewing some important change program kick-off activities - which I believe need to be implemented before any project even starts up (Yes! BEFORE). I strongly believe this will help to avoid some common root causes of most 'change program'  failures. 

So why are Business Transformation projects actually failing?

I start the discussion by reviewing some important change program kick-off activities - which I believe need to be implemented before any project even starts up (Yes! BEFORE). I strongly believe this will help to avoid some common root causes of most 'change program'  failures. 

1. The first problems are triggered by the fact that most large-scale change projects legally need to be sent out as an ITT / RFQ where many 'professional' consulting companies reply with a 'book' containing suggestions, many assumptions &  constraints with threats of change-orders ($$).  

 Main issue here are:

2. The second problem is that there are too many political 'sharks' between a few genuine consulting companies. The 'genuine' consulting companies with 'ethical' consultants make real and truthful offers - but these are often rejected and never  make it past the first hurdle - mainly because the costs are far too realistic and not what the client expected or wants to believe. 

It's therefore important for companies to develop true partner relationships with consulting companies and build trust with them fully over many years. This takes a lot of time and only works after working closely together on many projects. An important step to building trust is to ensure the  KPIs and business drivers of the consulting company are in the client's favour. Trust is quickly lost if the consulting companies' KPI is measured on maximising revenues rather than maximising project savings, quality, and on-time delivery. A motivator for a project savings KPI could be sharing the savings. If this is not sorted out from the start then you don't have a partnership agreement - you have a shark that will find every excuse to extend the project! 

The Main issues here are:

3. The third problem is that the sharks have under-priced the offer -  just to get a foot 'in the door'. This then forces the customers to ask these 'Partners' to refine their offer. Some do - some don't accept this. If they accept to do this,  then they end up with a project with some of the following traits (ref:  CIO analysis: Why 37 percent of projects fail By Michael Krigsman - March 15, 2011-  [report in pdf] )

Not a very good start to a  project is it? ....and not really surprising that these sorts of projects have a high probability of failure! 

The problems usually end up with the project manager and Organisational Change Management team to resolve. The most common obstacles that interfere with recovering failed projects are:

I totally agree with Michaels Krigsman analysis. We have all seen this before and we all know it's a project managers' and change practitioners' nightmare ! 

So why aren't companies reviewing this stupid process?

Why do these big companies always manage to fool themselves that they have such a great supply selection process and the best solution?  "We can always manage to get the price reduced by 30%". In reality, the bid manager just walks off with a great bonus and is very happy. He has just thrown the already doomed 'square-shaped' project over-the-wall to the project management team for them to try and squeeze it into a round hole. Yeah, sure; Dream on!  

This is a classic case of what Peter Drucker, Tom Peters, Edwards Deming, Lord Kelvin, and others  stated  "What get's measured gets done - Measure the wrong thing  - then the wrong thing gets done! "

I strongly believe that most of the root causes of change program failure actually starts within  this area - long before the project has even started. 

This topic is addressed in more detail in the following sections. ...

See also the references section for some stimulating discussions on this topic. 

Please note that on this website I share some of the approaches I've used and, where possible, also some forms,  templates, presentations and accelerators that where perceived as being 'successful'. 

 

Any constructive comments and reflections are appreciated.

What type of project typically triggers an organisational change?

In all the projects I've worked on, the triggers for organisational change have derived from:

Organisation Change Manager (OCM), Business and Organisational Transformation Manager (BOTM), Change Practitioner (CM)

Let's be honest - most organisations don't have a clue what "Organisational Change Management" (OCM) is all about or know what it actually means. I believe there is a real communication problem with the  term OCM and other abbreviations used to describe this role in a project. 

Organisational Change Management is a term that's often confused with:

OK, you could argue that some of these tasks need to be done in all projects, but this is not what I do, or what is really intended to be done by a "change practitioner"

I strongly believe whoever came up with this term is at fault here. I expect it comes from people who themselves are somewhat confused. "Organisational Change" is partly a correct term, but I prefer the terms "Organisational Transformation" or "Business Transformation",  "Organisational Transition" or even perhaps, "Organisational Readiness Preparation".  Let's face it, the real task of a "change practitioner" is to ensure the new 're-engineered' organisation is 'ready' to work according to the new processes - on their own - as quickly as possible.  

Yes,  you'll notice I use the term 're-engineering' quite frequently during these texts; even though it has been overused / abused / misused in many projects and therefore has left a bad taste in many managers' mouths, and the term Business Process Virtualization looks very similar on the surface. My own definition is the redesign of the business process steps;  according to the requirements of the new IT/ERP solution being installed. This doesn't necessarily mean process optimisation either as most IT solutions have fixed process steps (assuming no enhancements)...but I refer this to as the most optimised process using the solution that is being installed.

The organisational transition however needs first to be aligned with the business transition and business process transition so these are other terms that could be used.

 

I expect the term "management" in OCM, came about by someone who needed to feel more important. The problem with the word 'management' is that everyone in the project then expects that any change is managed by the  "change practitioner",  so they personally don't need to get involved and worry about this soft stuff. 

I therefore prefer the term "facilitator" or practitioner as in reality, it's the clients' organisations' responsibility to implement the change and not the consultant, as the consultant can only facilitate this change process. 

Some possible role names could be :

To avoid confusing this even further, I'll use the term 'Change Facilitator (CF)' during these texts.

  

There's no such thing as an IT/IS driven organisational change projects ! 

Too often I hear that this SAP project or that IT/IS project needs change management support. 

This may well be the case, but it's funny that no one talks about a certain 'process optimisation project' (with new processes and KPIs) needing OCM support,  to ensure planned value capture during a 12-month roll-out,   to remain competitive in the market.  

 

In these cases, the first thing I do is to interview the client's top management team to try and understand the real 'business drivers' behind the IT/IS 'change project'  and to see if everyone in the organisation really has the same vision and objectives. 

Unfortunately too often,  I see no clear business drivers, just a simple 'wish' to implement a new IT/IS solution. Although all arguments from the management team can be very convincing and the  solution sounds like a great idea, these are often not supported by any real business plan, business case or business drivers. Believe it or not,  this has also been the case for many very large ERP implementation projects!  


Without a clear link to the business vision and a well-documented business strategy (business blueprint), including clear KPIs for each core business process,  then the required organisational changes just won't happen! 

 You may as well give up now! 

At this stage, I advise the client to go back to the drawing board and develop these strategies. I then return again when they are ready. In certain cases, the client is happy for some support here too. I can't accept a project that starts on the wrong foot, as these projects are just too painful and life is just too short for such things. 

Companies should be really aware of this, as some freelancers or disreputable consulting companies, who win such projects on a 'time-and-material' basis, just love this mess. It's a guaranteed overrun or even worse - failure, which means even more increased revenue for the consulting company when fumbling to put the client back on track.

Linking Business Strategies to IT/IS  Projects 

So how do you link IT/IS to business strategies to OCM strategies?

This section is under construction too -...being continued....

 

Developing a Communication Strategy

The development of a communication strategy is an important part of the CF activities.  The effort of course depends a lot on the magnitude, scale and duration of  the change program, but is important for small projects.  

In larger change projects the communication requirements are often over-simplified as the biggest contribution a communication specialist brings to a change management program is actually the integrated communication strategy and communication plan  i.e. the entire communications roadmap that is aligned with the project and change program. This can be quite a large task to implement and for a program could require an additional part-time or full-time resource to keep on top of the communication needs. 

In my last change project, which was an international SAP project running over many years, I found the following areas to be most important as key activities within the roadmap:

It may seem obvious but the most important aspect of communication is actually to communicate -  and in a consistent way. This is often however neglected,  mainly becomes it becomes a rather tedious exercise in longer-term projects and programs, making this an even more challenging task. No one likes project websites that aren't regularly updated. Also don't assume everyone in the project team teams knows what's going on; as they usually don't ! 

 

Communication of the project plan

Communication of the plan is key to any project to avoid team members being confused about what they should be doing now and their impact to other dependencies. 

However, one of the most difficult tasks within a complex project is to communicate the plan, dependencies and progress to the project team, steering committee and stakeholders in a simple way. Ideally this needs to be done visually and on one slide. I’ve always been a fan of a visual one-page status report to convey overall project status. 

 

Google has over 13 million pages that describe project status reports. If you read all of them (I haven't), you’d sure to find a lot of discussions on the purpose of status reporting, key components and numerous templates. I’ll save you the time reading 13 million pages and provide three useful formats to include in your project or program status report deck. The key to these formats is to use visual reports to convey status rather than reading lengthy missives on this week’s project status.

My unscientific observation is people skim rather than read an entire status report or presentation. I’m sure you’ve had the experience where an executive, customer or key stakeholder skims through the first few pages of your meticulously wordsmithed presentation only to stop at the one key slide that holds their interest. The entire purpose of the status report is to inform the project stakeholders of project progress and have a conversation about the scope, resource and timeline concerns. Having a conversation using paragraphs of text is difficult for both the presenter and the audience. Visual formats help make the conversation easier.

Clark Campbell even wrote two books on using a one-page status report for both information technology and non-IT projects. Be sure to check out The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper and  The One Page Project Manager for IT Projects. I’d also readily admit a one-page status format may not meet all stakeholder communication needs. To address different communication needs, I’ve used the following one page visual reporting formats to improve the status reporting.

A Status Based Work Breakdown Structure

The figure below depicts all the reports, interfaces, conversion programs, enhancements and forms (or screens) required to be developed in a systems project. Each deliverable in the WBS can be colour-coded based on progress, issues and risks. The color blue is used to indicate a completed deliverable, yellow indicates an at-risk deliverable, red indicates a late deliverable, and green indicates the task is on schedule. A quick glance of the graphical WBS indicates the project’s interfaces and screen development have the greatest number of problems and the conversion branch is also at risk. By adding a visual layer to quickly summarize status, project teams can focus on the issues affecting the impacted work.

The graphical work breakdown strucutre was developed in Mindjet MindManager. Using MindManager, project managers can import MS Project data, assign task start and end dates and display red and yellow indicators based on the current date. I’ve used this visual status reporting format on larger programs and found it helpful in reporting a summarized status of the complex projects within a program.

A Graphical Timeline View

Every project status report needs some type of time-phased Gantt chart to indicate progress against due dates. Prior to MS Project 2010, Gantt chart reporting was difficult to easily depict meaningful tasks in a graphical one-page view. Fortunately, with MS Project 2010, you can create a timeline view and add select tasks rather than adding every task or milestone in the project. The following link contains my tutorial on how to create a timeline view in MS Project 2010.

The timeline view is a useful view however, large scale projects and programs often have many workstreams and phases that require an integrated view. MS Project 2010 users can create multiple timeline views and embed them in a single PowerPoint slide or a manual phased-based Gantt chart can be created in Visio, Excel or another graphic program. The challenge with these solutions is they all require tedious graphic manipulation when the project data changes. If you are looking for a configurable, one-page snapshot based on your project schedule, then take a look at Chronicle Graphics OnePager Pro tool.

With OnePager Pro, I can quickly develop a one-page snapshot, report baselines, critical path, % complete and add my own annotations. If the underlying project data changes, I click a button and the graphical data is updated. Try doing that with a complex chart in MS Powerpoint and you’ve just wasted another day tweaking and shifting data and Gantt bars manually.

References

Beyond the Wall of Resistance (www.beyondresistance.com)

Luc Gallopin

McKinsey & Company,  

Surrounded by liar's

http://www.amazon.com/gp/product/1885167725?ie=UTF8&tag=lucsthouonorg-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1885167725

OnePage project Management

http://www.tacticalprojectmanagement.com/project-management-tips/improving-project-status-with-visual-reporting.html

http://www.amazon.com/gp/product/047027588X?ie=UTF8&tag=amakarcom-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=047027588X