How the Right Business Engagement Can Lead to Transformation “Happy Ever After”

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

Transformation can be challenging, and the most successful projects I’ve worked on are those where business users are engaged and involved from day one and on every step of the journey. Every organization 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 business’s day-to-day IT system use are often overlooked.

I’ve worked on projects where organizations 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 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 one, effectively selling the benefits of the new solution to win the hearts and minds of 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 for which they’ve had no input. 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 organization’s requirements when it’s delivered. They, after all, know how the organization functions and what works well with the legacy system, and where there’s room for improvement.

Key Stages of Business Engagement

So we’ve established that Business Engagement in IT Transformation is important, but when and how should this engagement take place?

1. Requirements Gathering
Users should be involved in gathering requirements. This is common, but 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 a part of project working groups from the various project workstreams—design, development, test, etc.—and 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 walk through the designs that have been created from the requirements captured in Stage 1. This allows users to provide 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 it has passed a significant quality gate. In Agile this could be an end-of-Sprint demo. In non-Agile projects, this could be following the completion of Development Test. The objective in both cases is the same: to showcase software functionality and allow the business a forum to provide early feedback and identify potential issues or enhancements. Users will be able to see core system flows and 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 one, 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 going 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 the scenarios 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 Business As Usual (BAU) activities and organizations don’t fully appreciate the value in assigning 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 two or even three people who can share this responsibility while maintaining a consistent approach between them. This lessens the burden on the individual and allows input from more than one person.

We need to remember that organizations don’t undertake technology transformations 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 one. If this is demonstrated effectively, most organizations would be hard pressed to disagree that the returns far outweigh the investment in order to achieve transformation “Happy Ever After”.