My article last year on ‘Why Projects Fail’ referred to projects that were ill conceived, poorly defined, lacking in customer need, had vague or unreliable sponsorship, and needed stronger governance.  In this article I touch on one of the other reasons why projects fail - namely business readiness (lack thereof). The objective of business readiness preparation is to ensure a smooth transition from the project to the business-as-usual (BAU) environment.  In particular, it aims to mitigate any risk that current BAU may be disrupted once changes are effected to products, services, systems, processes, or structures.  In my experience, business readiness is the most overlooked part of project and programme delivery. A mentality of ‘hit and hope’ or ‘not my job’ often seems to pervade the field, which explains why CIPD (2003) found that 40% of organisational change projects fail to deliver the expected benefits because of a failure to ensure business readiness.  This despite the fact that in my experience organisational change projects are more likely to assess and ensure business readiness than any other project type.

"40% is close to flipping a coin about the ultimate and enduring success of your project or programme, so why would you do that after investing so much time and effort into the initiative?" 

There are many possible explanations why business readiness is not done, or not done well.  One reason is a mistaken belief that projects end on go-live and it is then up to unnamed others to ensure that the deliverables work or fix them.  Another reason is that the topic is not given enough emphasis in most project management methodologies. Though PRINCE2 and MSP do talk about business change managers with responsibility for making things work post-implementation, they do not provide a process for assessing and ensuring readiness.  Similarly - and despite being my preferred approach to software product development - agile environments often fair even worse than waterfall methods for readiness, even though the principles of agile state that the autonomous, self-managing cross functional product development team is fully responsible for outcomes and client satisfaction (which surely implies that readiness is all yours?). Again, the lack of a defined process and necessary emphasis in the literature is partly to blame, as are organisational structures that separate product development from operations /  BAU / service delivery. [NB do not rely on the presence of a ‘senior user’ or similar on your project board to ensure readiness.  Project boards are often more ceremonial than useful.] So how to assess and ensure business readiness?  I recommend using a pre-defined framework to do the assessment, the results of which will drive the necessary project, implementation and post-implementation activities.  There are several frameworks available, and most will help you improve your current approach.  Frameworks are commonly a checklist of factors to be addressed; or, a diagram that decomposes downwards from a top level of 7-12 factors to lower level factors and tasks; or, a flowchart. There are also some useful software tools that encapsulate factors, processes, tasks and documentation (including reports).  My own headline factors include awareness (colleagues, clients, partners, suppliers etc), support / resistance; feasibility, capacity; capability; staffing; accountabilities and responsibilities; training; policies, processes and procedures; and, systems and infrastructure. How well you are doing business readiness at the moment can be assessed using a process maturity approach, where level zero means it is not done at all; level 1 is ad-hoc or chaotic; level 2 is ‘repeatable’ (at least to a certain degree); level 3 is ‘defined’ (ie documented); level 4 is ‘managed’ (uses metrics to assess the impact of the change on BAU); and level 5 is ‘optimised’ (subject to continuous improvement).

"So isn’t this just common sense?"

Obviously not common enough to prevent 40% of projects failing to realise their full benefits.  Such failures highlight the intellectual, emotional and experiential gap between projects and operations that can exist in organisations.  One way to approach business readiness is with a risk management hat on, in which you ask yourself “what is the worst that could happen to this firm and its clients as a result of my project implementing a solution that does not work in BAU?”.  The answers will range from a withdrawal of whatever was implemented, with extra money and effort needed to fix the problem; all the way up to the firm losing a critical number of customers and closing down (it happens). To conclude... In conclusion, business readiness is a critical and oft neglected factor in business change.  All programme and project managers need to be expert in this important area of their work.

  • To visit Cliff Moyce’s new website , please click here

Image Source: Thanks to for the original image.


If you’re seeking advice on outsourcing and implementing systems development staff for your organisation please contact Jenrick IT on 01932 245 500.