Key business users can be difficult to pin down, this article shares my experiences and some ideas on how to handle this situation.

Introduction

The importance of business user involvement in defining the project, crafting the stories/requirements, prioritising the order of work, providing feedback and performing UAT is stressed by all Agile methodologies.

Ideally business users would form part of the project on a daily basis, ideally from 50% to 90% of the working week over the entire course of the project. In reality, many companies cannot spare key business users for the duration of a project and certainly not for that length of time. Other constraints prevent business users effective involvement. For example, one of the projects I managed was based on the South Coast of England, yet the business users who would accept the product and who’s factories it would help run were based in the midlands and were often travelling around the country. Another project I delivered had business users in Australia while with the technical located in the UK – they were knocking off the day just as we arrived for work! Rather than grumble about lack of conformity with the Agile way, the pragmatic Agile practitioner finds ways to deliver a valuable product with sub optimal business engagement. This often involves some creative thinking.

Identify the Business Users

The business community cannot be allowed to withdraw from the project after issuing some vague requirements. They must continue to be involved in the project from start to finish. It has been my experience that business users will support projects provided you can respect their availability constraints.

Using the DSDM framework, pin point the Business Users who are commissioning the project you are going to deliver. The key roles to fill are the Visionary and Ambassador. However it would also be useful to identify Business Advisors who can be called upon to provide specific knowledge or support to the project.

Rules of Engagement

Establish how and when business users will interact with the project:

• An initial briefing on the project with as many supporting artefacts as possible. Make sure the business users can give you a clear explanation of the business value of the project and also understand what the key dates are – for example with VAT 2010 we had to be ready for 31st December 2010 and failure to make the systems compliant could have resulted in bad PR and a big fine from HMRC. If your company has a governance process in place then much of this information will be included in the PID or other governance documents. There needs to be some recognition that remote/scarce customer involvement increases risk or rework and some allowance should be made for this when planning iterations and increments.

• Go see for yourself. At least one member but ideally the whole project team ought to go and see the problem space. In the case of the manufacturing project, we were able to tour a facility near the office to see how the product was made and this helped the team to understand the how the deliverables would be used. The project we built for Australia
  simply didn’t warrant a visit, but as it interacted with the supply chain we were able to find some Business Advisors in the UK and they were able to help us understand the product set and key processes. Documents and Artefacts. Create process diagrams for the new system and the old system; obtain as much example documentation as possible (for example copies of customer orders). The objective is to have props available that the team can refer to during development – this will make it easier to understand stories and create test cases.

• Find out who the Business Advisors are – who can you pose questions to? More importantly how do you gain access to them – phone, email etc?

• Discuss how you can show progress to Business Advisors. The application we created for Australian customers was hosted on an internal intranet so we could release to this daily, notify them of changes by email so they could provide feedback on our work while we slept. We also arranged for phone and video conferences once a week which meant a late finish for them and early start for us. For other projects we have used ‘Show and Tells’ at the end of each Iteration or been able to agree that a customer representative will spend one afternoon a week with the project team. It is vitally important that users provide feedback to ensure you are developing the right software. For the manufacturing project we agreed dates in advance when the users would come to the office to review software and work with the team. By doing this, they were able to fit the project around their other commitments.

• User Acceptance Testing is a must. However, I have found Business Users either do not have the time, skills or interest (or combination of all three) to write UATs. One of my strategies for compensating for this during the development phase (and especially when business users are not readily available) is to obtain and process data used by the current system. The results are comparable and if the basket of tests is wide enough ought to capture the key interactions and processes. Before the system goes (in whole or in part as increments are completed) into production, the business users are going to have to test the software . Over the course of the project keep discussing UAT, help them to prepare test scripts and more importantly agree a time and location where they will perform the tests. The project team should run the tests as the software is built to drive out bugs and misunderstandings. Part of the UAT for the manufacturing project involved deployments to the Training Centre (where parts of the training course used the new software) and also to production where the software shadowed the existing system. We used some specially developed tools to compare results and we regularly reviewed these with key business users.

The Project Leader

A member of the project team – perhaps the Project Manager, Team Leader or the BA must become familiar with the business problem and clearly understand the outcome the business requires. They (with a nominated deputy) will also have cost interaction with business users. While I encourage code and test engineers to interact with business users when they are on site, remote operation makes this difficult and leads too many misunderstandings. In effect the Project Leader will take ownership of the project and drive the project to a conclusion – the rest of the team may regard
him or her as the customer’s agent.

Agree Iteration & Increment Plans

As with any Agile Project, slice the stories up into Iteration and Increment. The usual balancing act between early delivery and risk management should be applied (i.e. if you are going to fail then fail early). Once the project is underway, the Project Leader needs to work with the Business Visionary, Ambassador and Sponsor to review progress and the stories to be developed in each iteration. If communication is working, the Project Leader will have a shrewd idea of what should come next. The frequency and manner of these reviews may need some thinking about but they must happen to avoid a failed project. What is important is to ensure that feedback is properly used. If the users want to change work delivered (and they might) they have to prioritise this against features yet to be developed. If they want to put 10 story points of changes (be they new requirements or rework) into the project they have to take 10 story points out. (Assuming you are using a time constrained methodology such as XP, SCRUM or DSDM).

Release planning is another important part of the planning process. However as users tend to be less involved with production environments, this forms a more normal dialog with release management or production system owners. In my experience a set of procedures normally needs to be adopted and tests run – these may influence project delivery dates and hence the way in which your business users support UAT activity.

Conclusion

Not having active customer involvement is a key issue for many Agile Projects. The impact can be minimised by thinking about alternative ways to engage with business users. It may increase the work load of the project team but better this than a failed project.