5      UAT AS TRANSITION

In this central chapter of the book we stand back from the detail of preparation and, before we immerse ourselves in the detail of our step-by-step approach, take a look at the bigger picture. Where does UAT fit in the larger scheme of things? What are its core functions and attributes? What overall contribution does it make?

THE IS LIFE CYCLE AS A SERIES OF TRANSITIONS

In the introduction we presented the idea of the IS life cycle and here we reproduce the life-cycle model we included there as Figure 5.1.

The model reminds us that UAT is not just the end of development; it is the beginning of the period of service use. The life-cycle image provides a clear sense of how things change over time and where the effort and cost go, and these are important to bear in mind.

But UAT also acts as a gatekeeper for another key transition: it marks the change of ownership of the ideas embodied in the software from the development team back to the users. Remember there was another of these tricky transitions earlier on, between requirements and development. Actually the transition was from the users’ understanding of what they needed to the developers’, using an RS as the translation document and the symbol of exchange.

So another way to look at a life cycle is as a series of transitions from one state to another via transactions. Generation of the RS was the first transaction; UAT will be the second. There are more significant transitions ahead. Once the system is implemented and initial teething problems are sorted out, the system will transfer into routine maintenance and this will entail a transaction between the development team and the maintenance team.

Figure 5.1 The IS life cycle

There will then be a period of enhancement and improvement while the sponsor seeks to get the maximum value from the IS with the help of the user community. Once this has been achieved a further transition occurs to transfer ownership from the sponsor to the business to manage any further enhancement together with the maintenance team. Notice that each of these transitions involves a transaction between two groups: users to developers to create the RS; developers to stakeholders at UAT; developers to maintainers when maintenance begins; sponsor to the business when routine business use begins. Figure 5.2 illustrates these transitions.

Figure 5.2 A map of transitions

The point of all this is that these transitions are the points in the project when change occurs, where value is released and where problems can occur. They are the critical points in the overall life of the IS.

The reason we are particularly interested in transitions is their capacity to cause problems. That is one reason why we prepare very carefully for them. We have explained how much effort goes into the transition from ideas into a RS (and how rarely the transition goes smoothly even then), and in Chapter 4 we touched on the significance of training as a means of preparing for the UAT transition. We will rely on training again to ease the transition into service use.

Figure 5.3 Preparation for transitions

PLANNING FOR TRANSITIONS

UAT is the key transition that we will focus attention on, but it is worth noting briefly that the series of transitions we have identified all need careful preparation. Two activities need to be happening continuously throughout the life cycle to enable and encourage the difficult changes in perception that end-users, in particular, will have to face: these are communication and training.

This is not the right place for a detailed discussion of either of these activities, except to say that their significance justifies detailed planning to ensure that the right activities occur at the right stage. Appendix C provides a slightly more detailed look at how training can be managed as a perception-changing process throughout a project in relation to UAT. A communications plan structured similarly would also be a valuable tool for keeping all parties not only informed but prepared for the next step.

UAT AS A TRANSITIONAL PHASE

The ultimate goal of UAT is that the current status of the system is understood and either we know the system is ready to be deployed or we understand what needs to happen for the system to be ready for deployment. An unsuccessful UAT will mean that the deployment of the system is placed in jeopardy.

UAT is the key transition point between ownership of the project by the development team and ownership of the system by the business because it sets up the whole phase of in-service use (potentially 10–20 years) during which the system will deliver value.

Figure 5.4 illustrates UAT as a transition phase. As we showed in Figure 5.3, transitions need preparation because they entail changes of perception and process – changes that humans find difficult and stressful – so we need to build up to them over a period. The preparation for UAT is a vital part of achieving effective UAT and this in turn impacts directly on the quality of the accepted system. We want to be able to verify not just the quality of the system but how well it serves its user population, how well it enables business objectives to be achieved and how well it will cope with changes and updates in future.

Remember that this ‘in-service use’ of the life cycle accounts for around 80 per cent of the total life-cycle cost and the extent of that cost will depend on two parameters:

•  the quality of the system as accepted (because this is the base for all future changes and development);

•  the buy-in of the end-user community (because this, more than anything else, will impact on how much business benefit is eventually achieved).

We know that end-user buy-in is important to the success of the IS yet end-user buy-in is a difficult thing to define and to achieve. We need to achieve the willingness of the user community to accept ownership of the system (warts and all) and a commitment to work with it to achieve what the business needs from it. Without this buy-in every minor defect can be a ‘show-stopper’ and future change can be very difficult to achieve.

UAT AS AN EVENT AND UAT AS A PROCESS

In order to enable the UAT transition to be smooth and effective, the preparation needs to be started early. End-users who have never tested a system before need to be trained – and training in this case covers not only unfamiliar territory for them but also requires them to think differently about the systems they use. The changes of perception this requires cannot be achieved in a one-off training course just before UAT begins; they will take gentle introduction, reinforcement and gradual extension over a period so that the change of perception is not just superficial. As we will see in the next few chapters, end-users will also have tasks to do to prepare for the UAT ‘event’ including planning, analysis and design, as well as familiarisation with the system, the business processes and perhaps some tools so that the test execution and reporting stage can be completed effectively and efficiently.

Figure 5.4 UAT as transition

The UAT ‘event’ is actually a process that begins very early in the life cycle, and many of the key decisions and preparatory actions need to occur well before the ‘event’ if UAT is to be successful.

As we step through the stages of the UAT process it will be important to bear in mind the timing of the actions we describe and of the training that might be needed to enable them. There are many views on when the UAT process should begin, but the process we will describe is at least as important as the development process and should, in our view, begin at the same time. It will progress at a slower pace and consume much less resource, but it is a process that, like training, should be running in parallel with development from beginning to end.

Some questions to consider (our responses are in Appendix B)

The project you are working on is acquiring a COTS-based suite of applications configured to meet your company’s needs, but there are some known potential gaps in functionality. Implementation is scheduled for 12 months ahead and a UAT team will be formed 1 month before UAT.

a. As UAT team leader elect you have been asked to review the plans. What feedback would you give?

b. As a nominated end-user tester for the UAT team, what would you propose?