I have, after several months of leading developers, come to a realization: requirements are not enough.
How many of you have heard a developer say this at one point or another:
“Why on earth would they want it to do that?”
Waterfall requirements gathering has become a very sterile task- identify what must be done. Don’t get into the weeds. Describe the problem. Let the developer solve the problem. Where this goes astray is that, like the worker on the assembly line who inserts tab A into slot B and passes the item down the line, the developer is simply pulling a lever to make it exactly as described. They have no idea what the goal is, so they can’t troubleshoot, they can’t add value, they can’t even tell if it does what the user intended- which is often different to what the user said to the business analyst. User stories can be the same way. What you end up with is a flowchart of a process, but you don’t know necessarily really know what the user meant to accomplish.
A good business analyst can get at what the user’s intentions are. The problem that I’ve found is that often the business analyst may know what the user’s intentions are, but he has no idea how the existing system is solving the user’s problems. Or, worse, the analyst sees exactly how the current software is solving the problem, but misses the fact that the current system has already been determined to not be solving the problem in the best way (after all, that’s why you’re replacing it, right?). What the business analyst usually has is how the user thinks the software solves the user’s problems. There may be large, significant chunks of logic hidden deep in the system that have broad implications, none of which the user or the business analyst is aware of.
What this leads to is the analyst documents what the user wants, the developer hacks up the system trying to make it act exactly that way, and the implications of that to the rest of the system or to other systems are not what the user expected or predicted, and in the end, you have unhappy users- because you did exactly what they wanted.
My point is that too often business analysts capture the “what” of the problem perfectly, perhaps even the “how”, but not the “why”- and you need the “why” to determine the best “how” of solving the problem effectively. Since we have started working on connecting developers to the “why”, we’ve seen massive improvements in our organization. Software quality is up, software that does what the user wants is being built faster and better, we have developers whiteboarding new ideas and designing next generations of the software we have today that will clean up many long-standing software issues. We’re quickly evolving into pitching solutions to the business’ problems to them before they’ve reached the point of deciding to ask for our help. Why seems to be one of the magic bullets involved in spanning the gap between being an IT organization that does things when asked to being an IT organization that thinks. All because we started explaining why to the people who do the work.
Agile programming is changing things somewhat. Sprints are sometimes too short to understand the whole problem, but the fundamental issue is getting fixed- all the right people are getting in the room together and talking. During my career as a project manager, I emphasized to people over and over one mantra: projects have been done for thousands of years, and most of those times without our modern tools. Provide good enough communication, use no tools, you still have a chance to get the project done well. The tools support and help and should be used, but they are no substitute. Use every PM tool in your toolbox, fail at communication, and the project has zero chance of success. None.
The concept of appropriate communication can apply to your project management, your business management, software management, or anything else. Explaining why engages people and involves them in the problem. Why is powerful. It can innovate. It can bring up issues with the original design or process before it goes into place. It creates a more team-oriented way of thinking about the solution.
My point is this: bring why to the table when you engage people. Include it in your project charter. In requirements documents. In meeting requests (how many times have you gone to a meeting with no idea why you were requested to be there?). It’s a valuable tool. Use it.