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

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-solving ,  Problem-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:

• • During an ITT / RFQ process, the consulting companies don't really fully understand the full scope. The bid process is a process of throwing questions and answers over a wall - which is a recipe for disaster,  in terms of communication. "We'll sort those details out during the project"...but remember that all the devil is in the detail! 

  • The customer does not see all possible solution or have all the facts and most likely don't really know what they actually want -  the bid often describes the wrong problem - is not asking the right questions to get the right solution in the first place!     So to summarise:

• 1. incorrect problem descriptions!

  2. incorrect questions!

  3. incorrect solutions! 

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:

• • The true costs of the complete project are not really understood as each consulting company is afraid to tell the truth about the real costs as they believe the competitor will offer something cheaper. They then disquise the truth as assumptions and conditions which don't surface until it's often too late. 

  • The bid process becomes a financial exercise rather than a 'common sense' exercise (i.e. pick the cheapest one and throw the expensive ones out) 

  • Where are the business drivers? Are the business case and capital expenditure proposal really credible or is this project just a wishy-washy idea from some new high-flying manager - who just needs to prove himself? 

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] )

• • Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.

  • Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.

  • Schedules: Too tight, unrealistic, overly optimistic.

  • Planning: Based on insufficient data, missing items, insufficient details, and poor estimates.

  • Risks: Unidentified or assumed, not managed.

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:

• • Getting stakeholders to accept the changes needed to bring the projects back on track-whether they are changes in scope, budget, resources, etc.

  • Poor communication and stakeholder engagement; lack of clarity and trust.

  • Conflicting priorities and politics.

  • Finding enough qualified resources needed to complete the projects.

  • Lack of a process or methodology to help bring the project back on track.

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:

• • New business direction or new business strategies

  • New or improved business processes

  • New product developments or product launches which required significant changes to existing processes or an introduction of new processes

  • Changes or influences from the external markets, such as the deregulation of the gas market in the UK in 1992, lead to new business opportunities by introducing new services

  • New technological changes leading to new business opportunities and improved customer services (such as the implementation of a centralised call-centre)

  • Re-engineering projects triggered by a need to cut costs and improved completive advantages in the global markets. Usually requires harmonisation of business process across all international business units and implementation of an integrated ERP system such as SAP, IFS

  • To achieve real competitive advantages  through processes optimisation projects to become enable the organisation to become more responsive to changing markets and to become more customer-oriented

  • Organisational integration projects after merger or accusations  

  • Combination of the above

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:

• Change Management,  which is an ITIL standard for managing change requests in IT organisations.

• Training of end-users

• Changing of management teams

• HR management

• People management

• Firing employees

• Soft people activities in a project such as training of end-users, hiring of new resources

• Process redesign 

• Fluffy,  soft,  nonsense stuff.

• Project Contingency - if we run out of other budgets - let's use this budget

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 :

• Business & Organisational Transformation Practitioner BOTP

• Business Process & Organisational Transformation Practitioner BPOTP

• Business & Organisation  Transformation and Readiness Facilitator" (OTRF)

• Organisation  Transformation  Facilitator (OTF)

• Business Transformation Facilitator (BTF) 

• Project Transformation Facilitator (PTF)

• Transformation Facilitator (TF)

• Readiness Facilitator (RF)

• Change Facilitator (CF)

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:

• 1. Identify the important project life-cycle phases for communication and identify communication 'arenas' . Each project phase normally requires a change in communication approach, a change of target group focus and also a change of arenas and channels where and how the communication needs to be done . The arenas for communication will change during the life-cycle of the project such as the time to communicate to  project team status meetings,  workers council meetings, steering group meetings, corporate board meetings, local unit board meetings, local management meetings, customer and supplier meetings, etc

  2. Segment the complete project 'market' into communication target groups e.g. corporate management & stakeholders, local management & stakeholders, end-users, etc.  as a few examples - but also don't forget the actual project team (especially if spread over many locations) and future operational support organisation. Also certain end-users may be located in different places/countries and be part of a local roll-out plans, therefore require quite different communications at different times.    

  3. Determine communication channels for each segment.  I found a project website (with RSS feeds option),  wiki's and blogs to be very powerful communication channels and much more effective and interesting  than sending emails. Users then have more control of the information they receive. Don't forget more personal channels; such as face-to-face meetings, local arenas and also use local newsletters and notice boards. In some organisations not all target groups have access to websites and are able to use computers

  4. Differentiate the communication content to ensure relevance for each target group. i.e. Don't send technical jargon, intended for the project team,  to all end-users or assume all end-user need the same information at the same time

  5. Timing and channel of appropriate communication to the correct target group is important to get right 

  6. Local Language is important - even within International organisations where everyone believes that English is the corporate language! The end-users usually don't!  Consider this aspect when building project webpages for international projects; especially in regards to communications to end-users

  7. Build an international change network to support the coordinated communication effort. It's almost an impossible task without this contribution

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