June 18, 2008 – 7:12 am
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?”
Modern 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.
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. 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, but not the “why”- and you need the “why” to determine the “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.
This is not a new concept. In my brief “old” career, I was exposed to these concepts all through the manufacturing industry. Those companies who innovate and brought their employees on the floor into the why of things were seeing cost improvements, new innovations, better productivity, and happier workers. The concept can apply to your project management, your business management, software management, or anything else. Explaining why engages people and involves them in the problem. They can innovate. They 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.
Like this post? Buy me a cup of coffee.Popularity: 90% [?]
These icons link to social bookmarking sites where readers can share and discover new web pages.
Posted in Analysis, Operations Management, Process Management, Requirements Management, Software Design | 2 Comments »
