How the right Business engagement can lead to Transformation ‘Happy Ever After’

IT Transformation is ever more in vogue nowadays as organisations look to improve efficiency and productivity by reassessing and overhauling their current IT systems. Technology changes rapidly, so to keep pace organisations are moving from onsite legacy systems to cloud based solutions which deliver benefits such as greater process efficiency, increased capacity, sophisticated data analytics and reduced costs, to name but a few.

Transformation can be challenging and the most successful projects I’ve worked on are those where business users are engaged and involved from Day 1 and on every step of the journey. Every organisation has SMEs (Subject Matter Experts) who have been using the existing legacy systems for years, therefore, you would think that transformation projects would be keen to tap into this knowledge and make these business users key members of the project team delivering the new solution. However, this is often not the case and individuals who could offer an intimate perspective on the organisation’s day to day IT business use are often overlooked.

I’ve worked on projects where organisations have underestimated the benefits of securing broad user engagement from the start of the project journey, instead being content to involve ‘the Business’ sporadically or perhaps only during UAT (User Acceptance Testing), when their feedback can provide only limited benefit late in the project. There is a common misconception that quality assurance equals testing, but quality needs to be assured from the start of a project and expecting testing to be a catch all quality gate can prove expensive. Ensuring that we’re building the right solution, comes way before we check whether we’ve built the solution right.

UAT itself can be a testing time in more ways than one, especially when users are invited to partake in testing without much prior project engagement and limited knowledge of the new solution they are being asked to test. Most of us are resistant to change by our nature, particularly when we don’t understand the benefits of the change and UATers (User Acceptance Testers) often find themselves in this situation. Users are comfortable with their legacy systems, imperfect as they may be; a classic case of better the devil you know. When they haven’t been personally involved in gathering requirements for the new system, the solution they are asked to test can seem very different, causing apprehension and negativity. It doesn’t take much for this negativity to quickly spread by word of mouth through the user community and this bad press can be difficult for the project to recover from.

So, what’s the best way to avoid this situation? I always advocate embarking on a journey with the business from Day 1, effectively selling the benefits of the new solution to win the hearts and minds of the future users. Thereafter, the user community should feel like they’re part of the team shaping the new solution being implemented and that they’re involved in every step of the journey, rather than receiving a product that they’ve had no input to. In this way the people who really know the day to day running of the business have the opportunity to ensure that the new system will meet their and the organisation’s requirements when it’s delivered. They, after all, know how the organisation functions and what works well with the legacy system and where there’s room for improvement.

Key Stages of Business Engagement

1. Requirements Gathering

Users should be involved in gathering requirements, this is common, but then typically once this activity is completed the requirements go into the project sausage grinder and it could be months before the user community is engaged again when UAT looms over the horizon. Instead users should be part of project working groups from the various project workstreams: design, development, test, etc which meet regularly, particularly at key project milestones, to review and feed into the new solution.

2. Design Reviews

Design review sessions should be arranged to walkthrough the designs which have been created from the requirements captured in stage 1. This allows users to feedback on how their requirements have been translated into the functional design and highlight any issues or omissions.

3. Build Reviews

Build review sessions should be used to demonstrate working software once its passed a significant quality gate such as Development Test. Users will be able to see core system flows and be able to provide early feedback on requirement coverage and any functionality and usability issues.

4. User Acceptance Test Preparation

One of the benefits of user involvement throughout the project lifecycle is that they can provide an additional perspective when it comes to UAT scenarios and scripts. Users are key here as they have intimate knowledge of their critical End to End scenarios from a business perspective, but because of the engagement from Day 1, they also have a good knowledge of the solution and this can be invaluable when working to produce comprehensive UAT coverage.

5. Training

Training on the incoming system is very important in any transformation project, but the timing of it can greatly increase the returns. Even if users have been involved from the start of the project lifecycle, training will empower them to use the new system in their day to day roles. On many projects, training is planned to occur just prior to go live, this makes a certain degree of sense, but if you bring training forward to take place before UAT execution, the benefits are increased. By doing this you get more bang for your buck as users have a better understanding of the new system and therefore the scenarios that they will be asked to execute, thereby reducing training related questions during testing.

6. User Acceptance Test Execution

UAT execution can be fraught with issues. I can remember more than one occasion where I’ve seen users almost in tears during test execution because of the fear and apprehension caused by sampling a new system first hand. Thankfully, because our user community has been fully engaged during our transformation project and have already received training on the new system, this shouldn’t happen. With our approach, the users aren’t afraid of the new system, because they’re familiar with it already and have had time to understand how they will use it. The investment earlier in the project lifecycle reaps rewards in everything that follows as we can be more certain that we’re building the right thing. Subsequently by the time we get to UAT, the likelihood of discovering major requirement gaps is greatly reduced.

This all sounds like common sense, doesn’t it? However, there are reasons why this happens so rarely. Business users, especially SMEs are generally busy with BAU activities and organisations don’t fully appreciate the value in seconding these people to project work for an agreed number of hours every week. Therefore, the needs of the day to day income generating activities often outweigh the needs of a project delivering a new system months in the future. Of course, there are ways to mitigate the impact of user engagement on BAU activities: instead of singling out an individual SME from each business area, identify 2 or even 3 people who can share this responsibility whilst maintaining a consistent approach between them. This lessens the burden on the individual and allows input from more than person.

We need to remember that organisations don’t undertake technology transformation every day, therefore the onus is on us as seasoned IT professionals to bring our experience to the table and highlight the benefits of securing the right business engagement from Day 1. If this is demonstrated effectively most organisations would be hard pressed to disagree that the returns far outweigh the investment in order to achieve transformation ‘Happy Ever After’.