This is one to file under the “duh” category. It’s a fairly simple and straightforward approach to working with users on a project and ensuring their participation. On large scale projects (this does not truly apply to agile because a strong agile team doesn’t suffer from this problem) it is typical for users to a) lose interested, b) have more important work to do or c) just not care. This is obviously an issue that can plague a development team because if the users don’t actively participate (provide input to requirements, review requirements, participate in demonstrations, etc.) when the project is over the software won’t work the way the users wanted it to. So how do you solve this problem?
Assign each area of functionality to a user who takes ownership of it. Preferrably this user is someone who knows the subject extremely well and does it on a day to day basis. What benefit does this provide?
- You don’t have to chase the user around for information – they want to provide it to you.
- They always show up at demonstrations because their co-workers will eventually be using the functionality they own.
- They always show up at demonstrations because they have pride in their work!
- They review the deliverables the IT team has for them because its’ also their hide on the line – not just the development teams.
- When problems arise because functionality doesn’t work the end-users, they don’t come complain to the development team, they go to their co-workers. Why is this a benefit?
- There is usually better communication among co-workers then “outsiders” like developers.
- From an IT perspective, it can easily be shown that no gold-plating occurred and no analyst took measures into their own hands and “guessed” at what the end users wanted
- It takes subject matter experts out of the primary role and puts them in an advisory role. SME’s know the processes back and forth, but they don’t work with them on a daily basis and don’t know the exact steps that users take to accomplish any given task.
And if the users don’t want to take ownership of a feature? Maybe the feature shouldn’t be in the software to begin with because no one cares enough about it. Take some time to think about this and you’ll see that it is a win-win situation for IT and the business.