This idea of evolving towards the true business requirements rather than the initially stated requirements (which are often flawed) is a cornerstone of iterative development. Some people use a guided missile analogy: when your target is moving you have to make lots of mid-course adjustments to hit your target. (However, missiles have lots of negative connotations, they are destructive and generally blow up and hurt people, not a good analogy for a project environment! However try to concentrate on their ability to steer towards a moving target and instead imagine they deliver a bunch of flowers once they get there, not an explosion)

Or, as my first PM used to say, “You cannot chase a dog with a train!”

Creating large, static requirement’s lists upfront and detailed project plans locks you more into a Traditional: Ready, Aim, Fire approach which works best for targets that do not move. The Agile: Ready, Fire, Steer, Steer, Steer approach may at first glance appear counter intuitive and lazy, but when we really analyze it we uncover a small degree of upfront aiming, (or at least best guess pointing-in-the-right-direction), and a more prudent approach to risk reduction.

We rely on the users to tell us where the target is moving to and whether our missile is getting closer to the target or not. Without this information we have no view of the target and a missile without an effective guidance system.

I think my users are on drugs! What sort of users do we want?
“User” here means some form of business familiar representative who can reliably inform us of the business needs for the solution. They may be an actual end-user of the system, or they may be a product manager or proxy-users telling us what the system should do. The characteristics of effective users are summarized by the CRACK mnemonic.

C – Collaborative – able to work with the team and communicate well
R – Representative – of their business segment, we want a good characteristic feedback
A – Accountable – to make decisions on the project
C – Committed – to the project, not frequently swapped for someone else who needs re-education
K – Knowledgeable – about their business area, able to answer questions and provide missing details

So remember, we really want CRACK users on our projects!

It’s not happening, now what?
So, what do you do when the users won’t play the game, or they are just plain busy elsewhere? First of all we need to understand that while full time customer / user involvement is the goal, it is a rare beast. It is not normal for organizations to have spare capacity for full time project work within their workforce. It has to be created through careful planning and backfilling of roles. Otherwise, it would indicate a headcount surplus and signs of bigger business issues than likely could be solved with some new software.

So, expect to fight, struggle and scheme to get good project resources and expect to continue this struggle throughout the lifetime of the project to keep them. Yet, if they are not available or disappear, what can we do?

1) Stop – We can stop the project, explain that user involvement is a prerequisite and without it the project cannot be successful. (It cannot be successful if you stop either, but hopefully the stop is temporary.) This is really an issue escalation strategy; by stopping we get stakeholder attention and an opportunity to explain the issue while everyone is listening. It could be seen at melodramatic attention seeking, and runs the risk of the sponsors finding someone else to manage the project or even another company to undertake the project. However, it may be an appropriate strategy in some circumstances.

2) Adjust to availability – if user input is the constraint that cannot be elevated or avoided then one approach is to scale the project back to run with the available user input. Sometimes explaining the cost and delay to the project of this throttling is enough to elevate the issue to a level where it is resolved, e.g. “The project will now cost an extra $400K and be delivered 3 months later than originally planned”, and other times it is a reasonable course of action to align the project with business realities.

3) Go less agile – If user input throughout the project is not viable, then perhaps we could get them for a month of focused effort to capture requirements and then intermittently throughout the project to answer questions and evaluate portions of the evolving system? This is where the majority of projects reside; it is suboptimal from a development perspective, and a slower, more costly way to develop. Without full-time access to subject matter experts (SME) the development team are forced to make assumptions and guesses about design and implementation everyday. The majority of these will be correct, but a percentage will be wrong and will require rework when detected. If they are detected quickly the rework should be small and cheap, if undiscovered for longer the rework larger and more costly. These problems still occur with full time SME’s but much less frequently.

The impact of a less agile approach is lower quality, longer timelines and higher project costs. If the project sponsors encourage or force a less agile approach through user withdrawal we have a duty to explain these likely cost of change impacts, quality issues and budget increases.

4) Pretend we are agile – It might be tempting to continue as if we were running an agile project and just fill in for the lack of user involvement as best we can through proxy users and best guess answers. However this is just “3) Go less agile” in denial, we cannot fake SME knowledge.

5) Turn it around – as ever, probably the best approach is the less glamorous, middle way of working with the stakeholders to try and improve the situation. Make the sponsors see the financial and quality impact they are having. Make the project environment appealing for the users so they at least don’t mind being there. Rather than just complaining about the problem, try to get creative about solving the issue by using the following strategies.

Strategies to maximize the likelihood of good user involvement

• Put users on the critical path – clearly show user involvement in project plans, review criteria, RACI matrices, anything project related that will involve user input.

• Add users to the Critical Success Factors (CSF) – clearly explain upfront in the Project Charters, Visions, and Initiation documents that without user involvement the benefits of an agile approach will be compromised and reduced.

• Use the project impact economics to justify backfilling roles – if we truly believe the impact of not having user on the project will cost us $200K a year, then it is in the project’s best interest to pay for backfilling user roles with temporary contract staff. Obviously we don’t want the temporary staff as our project resources, they will not have the business domain experience we need, instead we can free up our busy users by paying for staff to backfill their regular job. To begin with training temporary staff will have a net drain rather than net gain for user availability, but the idea is that once temporary staff have been trained, perhaps they could free up our SMEs for, say, 75% involvement on the project.

• Make user involvement easy not hard – encourage interaction by scheduling system evaluations and walkthroughs. Don’t just request feedback, guide them through the process. Help them enter last week’s data into the system and see where the issues are.

• Check up on it - If it is important then we should monitor it. We know coding and testing are essential and conduct reviews and collect metrics to help improve the process, the same should be done with measuring user input. Do not be sneaky about it, explain because it is so important we need to measure it, get the users involved in defining the metrics and then monitor usage. i.e. (number of transactions entered, observations raised, etc.) Discuss if seeding defects might be useful - if only 50% of seeded bugs are found are we missing half the indigenous bugs also?

• Reward it – just as we need frequent recognition for development contributions, we also need frequent recognition and thanks for user contributions. They can be easy to omit as they often report to different managers rather than the project manager, but we need to recognize their contributions. Make sure they are invited to team events; offer to give a project based perspective to their annual review process. Create user based goals and celebrations for the project, such as: one month’s data processed, 100 observations submitted, most bugs found, etc. In short, examine what we are asking users for and reward that behaviour.

User Related Problems to Watch For
Like other project members, users generate their own unique set of project issues and problems. Here are some common ones to watch for

Too Little Feedback – you issue some software for review and it must have been perfect. There are no change requests, defects, or clarification questions; Geez, we must be good! Actually no, it is much more likely that it has not been reviewed or only received a cursorily scan. No software is perfect, especially early iterations of something. If you receive little or no feedback it is most likely because the software received little or no review. Be suspicious of poor feedback, go and investigate what review was undertaken, how much test data was entered, etc.

Old Code Feedback – Related to “Too little feedback” as we approach the release date, we may suddenly start receiving feedback on screens and reports that have been in the system for many iterations. This is a sign that early releases were not reviewed properly. Only as we approach release are the users taking things seriously. The problem here is that there will now be a rush on defects and change requests towards the release date. The software “cost of change” phenomenon means these changes are more expensive to make now than if they had been reported earlier. Also, our velocity metrics will be skewed as the true rate of progress has been artificially high due to late defect and change reporting.

The wrong users – Good user resources are extremely hard to find. Everyone wants to hang onto the most practical, results focused, articulate members of the business workforce, yet these are the people we want to be lent to our projects. If when you ask for a resource there is an immediate “take Billybob, please take Billybob!” reply, then chances are you probably do not want Billybob on your project. Instead ask who the best person to represent the business would be, then work with the business to somehow make them available, either through backfill, delaying the project until they can contribute, or justification via explanation of the economics of project delays or omissions.

Remember, we do not want user input, we need it; the best user input we can get.