June 29, 2009, 5:18 PM — We all like to think that we understand our users, and that we listen carefully when they explain what they need. Armed with that certainty, we go off to design an application that scratches every itch the users described. And we are annoyed when they announce that, to their own surprise, what the developer delivered wasn't what the users wanted after all.
That's not always because your understanding was imperfect, but because few of us humans know the difference between "What I want" and "What I need." Often this distinction doesn't occur to us until we've made a few bad choices, which is why divorce lawyers earn a pretty good living.
Proponents of Agile methodologies will nod along with the above and mutter, "Isn't that what I've been saying all along?" (About the need/want issue; I'm not sure about the lawyers.) But I've recently bumped into a non-computer example that drove the message home for me.
It's a case of the busman's holiday: One of the things I do for fun (or at least to serve the community) is edit the monthly newsletter for a local all-volunteer nonprofit organization. That gives me a certain degree of dispassionate observer status, because every month I see (and correct the grammar in) the club's board meeting minutes, as well as the newsletter's other articles. I follow the club's projects, including its recent plans to move into a new building under a local government sponsorship. (I'm intentionally coy about its identity, here, as I don't want to embarrass anyone publicly, and the example doesn't need specifics.)
The guy who volunteered as Project Manager is very much of the old waterfall school. For several months, he's been proudly demonstrating to the club members how Gantt charts work and what "critical path" means. But I realized that in the past six months, about the only thing that has been produced is pretty charts, meeting reports, and a couple of architectural layouts (the latter generated by another volunteer who clearly has a workable vision for how it might all come together). There are real physical things to be built and installed in the new building, but as far as I can tell, not a single one of them is started.
Meanwhile, the club president, whom I like a lot, has left it up to this Project Manager (I'll refer to him as "Stan") because the president (let's call him "Joseph") wants to see the new building project "done right." I admire Joseph's delegation intent, but I'm beginning to see just how Waterfall projects go south. (Never mind that the situation is exacerbated because this is an all-volunteer organization. I spent many years as a computer user group activist, and learned from raw experience just how much is different when "motivating people" does not involve financial remuneration.) The bottom line is that nobody in this project could recognize whether or not it's been "done right" until the very end (i.e. when the doors open on the new building), by which time it will be too late.
All of Stan's energy has been put into organizing "What has to be done." Very little, as far as I can tell, has been put into identifying the different constituencies who need to be satisfied, and figuring out how to make them happy. The result is that Stan's plans are cast in concrete when the municipal authority says they require Such-And-So, then the concrete is blasted out when the Building Architects make a change... and nobody has asked, "What will make people actually pay to come into this building to see what we're displaying?" or "We have a small group of volunteers who joined the organization to indulge in their hobby. How can we make the new building serve their needs?"
I foresee bad times ahead.
I could write at length about what it takes to find out what is needed-and-wanted, and what happens in volunteer organizations when the members' needs are ignored (in fact, I did, before I deleted a big block of text). But the point I want to make is that a "Project Plan Is God" approach can only serve a bureaucracy. It can serve the end user only by accident. The users (whether it's the club members or the building architects) become secondary to "compliance with The Plan."
That wouldn't be so bad, except that a project being "done right" can only be judged by whether each of those groups-of-users is happy at the end. And since they don't know what they want (only what they think they want), they need developers (and project managers) to give them frequent opportunities to look at the results and make course corrections. And then adjust the deliverables in response as necessary, as the players find out what truly is required, by which date, and with what priority.
So to (at length) come back to my original point: even if you know all about the problem domain (that is, you understand the nature of the business problem), both you and the users operate on assumptions. Those assumptions may not hold true for every case, and specifically those assumptions may be inaccurate for this particular project. There is no way that Stan can predict every problem the club will encounter, the more so because of the battling agendas of all the parties involved. But by putting all his emphasis on "creating a plan," he loses sight of the purpose of a plan: to make sure that the project goals are met. With no allowance for the inevitable changes, either Stan will spend all his time updating his project management software, or the Plan will soon have no relationship to the actual project status.
This particular nonprofit isn't my problem, really. But I hate to see well-meaning people set themselves up for failure. And right now, that's all I can predict.
