Welcome to the second in a series of articles that seek to answer the question of why so many transformation initiatives fail and provide practical guidance for success.

Many transformation programmes mean changes to existing systems or potentially buying and implementing new technology. It’s very easy to get fixated on technology, especially if it’s new, shiny and expensive.

Running a procurement process for Tier 1 Cloud ERP or HCM technology (Oracle, SAP, Workday) can become all consuming. $£€millions are at stake and it’s too easy to focus exclusively on gathering technology requirements. However, effective transformation is about much more than implementing new systems.

Using the concept of Capability Requirement can ensure that you capture a holistic view of the needs of your organisation.

Capabilities describe ‘what we need to do’ as an organisation to deliver our vision. Capabilities are delivered by a combination of people, process and technology. They describe ‘how we best do what we need to do’. Consciously seeking out requirements that describe the culture that we seek to build, how people will work in the future and the processes they will use to deliver to their customers, ensures that a narrow, systems-focused view of the world is avoided.

Building up a complete picture of requirements drawn from across the business drastically reduces the risk of surprises in the later stages of the programme. This requires you to engage multi-functional teams of varying degrees of seniority. Shifting the focus between the problems we need to fix today and the requirements we have to deliver our vision of tomorrow provides further dimensions and depth to your requirements gathering.

A broad sweep of requirements will, however, need review and editing. Not every requirement captured will be valid, desirable or fully aligned to your vision. Judgement needs to be applied, which is where your governance structure comes in. If you have capable, empowered Process Owners and a well-defined design authority, making decisions on the requirements to accept into scope of your programme is relatively straight forward.

Requirements enable you to define the various phases of the programme and can be used to communicate with clarity e.g. we won’t deliver flexible benefits in Spain until Phase 2, so the current provider will need to be retained until then. An agreed set of documented requirements that everyone signs up to deliver is the basis for a well controlled programme. They set the criteria for design, testing and acceptance, and ultimately tell you whether the change and associated benefits have been delivered. Don’t make the easy mistake of rushing into selecting suppliers and designing solutions before you truly understand the requirements that you’re seeking to fulfil.

The Process Owners and design authority mentioned above are two elements of an effective governance structure, which, along with the thorny issue of decision making, is the subject of our article next week.

Can’t wait until next week? For your full 10 point Transformation Scoping Checklist click here.

Note: This article on requirements gathering is the fourth of ten critical success factors in scoping a functional transformation programme. Please click here to see our previous article outlining the importance of Sponsorship, Problem Definition and Preparing for Change.


Read Next

Transformation Checklist #10: Business Case

Where the rubber hits the road So you’re sponsoring a transformation programme and you and your team have spent the past six months setting up governance, understanding what needs to change, gathering requirements, selecting [...]