Why Partnering with Real Users Matters
Many development efforts are conducted in a way that fails to recognize the need for a partnership between IT staff and the business users, or even (amazingly) the need for a partnership between the IT team as a whole and the business team as a whole. Here are a couple of examples.
Myth 1: "We don't need the end users—their manager is already here"
One traditional approach recognizes the need for a general partnership between IT and the business, but does not recognize the need for working with real users. Here, an IT manager, and maybe a couple of members of the IT staff, sit down and talk with a couple of business managers at the outset of the project, meet with the same managers every several weeks, and then at the very end of the project, spring the application on the actual users and hope people like it. One problem with this approach is that because it fails to treat the people who are actually going to use the software on a day-to-day basis as equal partners in the effort, there is an increased risk of a disconnect between the users and the software. While managers used to do the work that their reports now do, they don't do it anymore, and they are therefore a very imperfect source of information about the actual tasks that are to be supported. Moreover, their descriptions, even if correct, will be general summaries of user tasks, and not detailed, concrete data of the sort that is needed to satisfy real user needs.
Another problem is that this approach doesn't treat the IT staff as equal partners either. They don't end up with a strong sense of ownership of the system, as they get all their information secondhand from the IT manager. (And really, it's "thirdhand" information since the IT manager doesn't get the information directly from the users.) When an engineer has a question about what the system is supposed to do, he or she asks the IT manager, and now everything rides on the IT manager actually knowing the right answer, which may or may not be the case. It is much better if every team member is sufficiently equipped to disagree with the IT manager on the nature of the business tasks, based on data coming from real users, because this raises issues that can be resolved against those users. Otherwise, there is too much risk that the IT manager doesn't quite get it, and nobody will find out until the real users see the app in production. This is the wrong time to discover that the IT manager didn't get it.
Myth #2: "We don't need to meet with the business as long as we have the requirements"
A second traditional approach fails even to recognize the need for a partnership between the business side as a whole and IT as a whole. In this approach, an IT manager, and maybe some IT team members, will have an initial meeting with the business managers, and then disappear into a room for several months. When IT finally emerges, the final product typically has very little to do with the tasks at hand. The business users are unhappy, their managers are unhappy, and IT looks (and, alas, in this scenario, rightfully so) incompetent. And chances are good that the users end up being stuck with the system anyway. The main problem here is that there is no feedback mechanism to control the IT team's progress and outcome, and without a detailed understanding of the business, IT will get it wrong.
