Who's paying for this?

...so why are we talking to the users?

I like working with users as they often give really good feedback. They're the ones who have to live with the software every day so tend to be very clear about how it helps/hinders their work.

Is it naive to think that making users happy by meeting their requirements is the primary goal of a software delivery, though? In my experience, which is not in COTS software development, the end users are not paying for the software - their boss is. Yet we often grant users great import, perhaps because their feedback is more immediate and tangible. Granted, it is unlikely that giving users unusable software is going to prove successful. Conversely, giving users exactly what they want is also unlikely to be a success. For a start, it could well prove financially prohibitive (eg, technically difficult)!

I consider one of my responsibilities as an architect that of keeping delivery focused on what matters. Sometimes this may mean giving the users what they want, sometimes it may mean telling the users what they're getting (and helping smooth the transition). After all, change isn't always just about transparently replacing the technology.

I'm sure I'm not the only person who's worked on software that has delivered what users wanted but has never seen the light of day. Were the users wrong or were we simply speaking to the wrong people?

About the author

Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at JPMorgan developing front-office trading solutions.

While getting on well with server-side Java, Kevin's also a keen Swing developer (and possibly masochist).

E-mail : kevin.seal at codingthearchitecture.com

Re: Who's paying for this?

In my experience, users haven't necessarily been wrong, but often they were not in a position to see the whole story. Interestingly, users also aren't always the best place to go to define the usability requirements. However, I have worked on systems where talking freely with a trusted power user has been invaluable. In return, they often end up getting their latest pet feature implemented ahead of schedule. Overall I think the project gained from their close co-operation. I hope the person footing the bill agreed...

Re: Who's paying for this?

There are a lot of factors at play, especially in larger projects and organisations.

In your post, I interpret 'users' as a subset of 'stakeholders'. Depending on the political situation, users may or may not be important to overall viability of a solution.

Into the mix of stakeholders you of course include the sponsors, but also the IT staff (if that department is particularly influential they can even reject the entire solution) and others seemingly on the periphery, but who often wield big sticks.

Another problem can be around ineffectual sponsors - especially important if you're replacing an existing system. Getting the code done is often the easy bit; getting a department of 200 users who currently use a combination of X, Y, Z and manual processes to adapt the new system takes a hell of a lot of energy, influence and political bravery (you'll naturally be answerable to any cockups or problems). You can be sure that at least some of those users will hold influence with management and they will waste no time in complaining about the new system's problems; real or imagined.

One more thing, related to the adaption issue, is that version 1 of any release invariably contains a bunch of tradeoffs, compromises and 'TODOs'. Getting that balance right, in terms of features required to attract and keep users' attention is never easy.

Add a comment Send a TrackBack