Accelerating transformation and reducing risk: avoiding the known pitfalls

Michael Taragin shares his insights on how transformation programmes can be accelerated and risks reduced by taking pragmatic steps to avoiding the inevitable (yet often preventable…) pitfalls that plague complex transformations.

At any given point, there are a huge number of transformation programs being run in every country and in every domain. There are programmes being run in-house and by suppliers including product companies and service integrators. Scope, budget, risk and complexity varies from one extreme to the other and whilst each project is different, they are unified by one thing: a playbook of common pitfalls.

Whilst an exhaustive “how to avoid the pitfalls” guide would be close to impossible to document, my experience of numerous programmes has resulted in me always focusing on four key areas that are a) incredibly common in their occurrence and b) have an uncanny ability to take organizations by surprise. By ensuring that these key areas are suitably factored into both contractual development and planning activities, the opportunity for long term success is greatly increased.

Define crystal clear programme scope and maintain sharp focus

Critical to the success of any programme is clearly defining scope. Trying to hit a moving target is very difficult and as such, proceeding without locking down scope is a recipe for disaster. Sadly, it’s all too common for teams to continue discussing and debating what to do and how to do it. In addition, with the potential new features and capabilities of the new ecosystem, teams often adopt the “candy store” mentality, wanting it all and of course, wanting it now, with little regard for the practicalities. Human nature is to be apprehensive of commitment and signing off that “this is exactly what I want, and no changes can be made...” can often be an incredibly difficult activity for senior leaders.

The impact of this is obvious: requirements keep changing, forcing delivery teams to add more work or redo work already delivered, driving up the budget and extending the timeline. And often introducing new and previously unconsidered risks. As such, it is critical to have a clear process to handle change. Making sure the right support structure is in place must be a prerequisite before embarking on the journey and defining a suitably frequent review of the progress, deviation and challenges is imperative.

Plan early for a drama free programme kickoff

Watching a train building up momentum and getting to full speed can take a significant time, especially if it has many people on board and heavy cargo. For the train to arrive on time, planners have to take this into account, not just the total distance and maximum speed of the train.

This metaphor applies well to transformation programmes. Programmes are dependent on numerous factors and getting them coordinated and integrated into a well-oiled machine takes time. I’ve often found that organisations often (and inadvertently) ignore this and assume that, for example, output during the first month will be the same as the third month. All too often the end of progamme week one shows the project behind schedule and at risk. Whilst plans often look great on paper, the realities of executing against the plan can often be overlooked. For example, hiring thirty people in a week, or backfilling current resources to make them available for the transformation programme are real challenges. Equally, simply ensuring that the plan, activities and dependencies are well communicated and thoroughly understood by all stakeholders means that a successful kickoff is much more than simply a milestone underpinned by a brief “all hands” call.

Create the best possible environment for successful customer testing

One of the most important phases of any transformation program is customer testing: validating that what was specified has been delivered and to the right level of quality. This phase is not easy and requires the right people to be supported with the necessary tools and given sufficient time to validate the deliverables. Sadly, customer testing is often an area that presents numerous opportunities (at least on paper) for ‘streamlining’ in troubled programmes. Sadly, shortening, de-scoping and oversimplifying are all too common and this most critical of phases can often leave those engaged in the testing feeling short changed.

My experience is that judicious pruning of customer testing is a wholly bad idea and clients must focus on really taking advantage of the time allotted to customer testing. One of my (many) sources of annoyance in this area is the disjoin between customer and supplier testing preparation. All too often, customers begin planning preparing the testing activities once the supplier is well underway with their delivery. This wastes valuable time (sometimes up to 50% of the allotted testing time) which could have been far better utilized. The goal needs to be simple: aligning teams such that the moment the supplier has delivered, testing execution starts. All planning, scripting, resourcing, setup, hardware allocation and so forth should be handled prior to the start date of customer testing.

Focus on an uneventful go-live

In transformation programmes, boring is good. And never more so than in readiness for go-live. Like the Design phase completion, here too, people are anxious to commit to readiness. Are we truly ready? Have we checked everything? Have we thought about every possible scenario that can happen once we are up and running? Do we have all the fail-safes in place? Obviously, the concerns go on and on, however what does not go on and on is the time allocated for this step.

The simple comprehension that go-live must be planned and properly executed is a big win for the programme. Defining what needs to be validated, how to get it validated, who can perform this, when can it be performed and so forth are all key aspects. Understanding that there will be hiccups is a realistic view and therefore building a framework to decide what is a showstopper and what is not will be vital. Putting in place mechanisms to handle issues post go-live is a must. The ability to sign off on readiness is an artform and one that needs to be suitably considered beforehand, beginning during the sourcing process and well before the project is underway.

Conclusion

These risks can never be fully mitigated, but setting up a programme for success is not rocket science. Sadly, realism is often outgunned by infectious optimism and whilst having a positive outlook is laudable, having an unrealistic one is dangerous. However, by collaborating and discussing these issues at length from the outset of the sourcing programme, long term success is a much more likely outcome.