Mission Impossible: Requirements
Mr. Big Shot at AverageCorp has just given a four sentence vision statement of a new software project. Your mission, if you choose to accept it, is to understand what in the world he's talking about and make him happy with the resulting software.
This blog entry will self destruct in 30 seconds....
This entry is a follow-up to my Fundamental Problem with Extreme Programming, the great comments it generated, and Philip Brittan's XP, User Champions, and Software Vendors. It's great seeing the conversations flow. It helps me to refine my own ideas as I get feedback from a larger group than just the folks I meet in person. I've also recently read a free requirements chapter of Christopher Duncan's book, The Career Programmer which I've just added to my reading list.
Like Philip, I have been in a situation with a self-appointed project champion who knew the business and was extremely interested in software. It was great to develop on that project for a while, but things went south very quickly when she started throwing around political clout she didn't really have and ended up leaving the company. Be aware of the failure mode of this approach. We became scapegoats when she left even though we'd done everything she asked of us.
I've known very few software projects that fail due to technical reasons. It's almost always political. It is usually an issue of either not understanding the business needs, or writing the software to please the wrong person(s). Because of this, focusing on optimizing the efficiency of the pure development effort, like XP, doesn't really help the underlying issue. Those of us typically introverted, logic-ruled developer types are going to have to determine to learn something about corporate politics. Yes, I actually believe that though I do not relish it.
What this means is that we're going to have to identify the head person that needs to be happy with the software, get some high level of understanding of what it'll take to do that, plus get him to delegate the details to someone or some group that we'll spend a lot more time with to wring out the details. Convincing him to spend his business people's time on this is going to require something akin to espionage. We've got to get inside his head and figure out how to present things in such a way that they further his individual goals. Also, keep in mind that his personal goals may not always be in line with just improving the corporation's bottom line (the logical position we techies like to argue from). In some cases, he'd get more political clout by having control of a bigger budget. We've got to learn what motivates him and adjust our approach based upon this knowledge
I'm not advocating dishonesty, but we techies need to step out of our navel-gazing tech-only mode and learn something about those topics that we typically say with a sneer on our face or while rolling our eyes -- politics, marketing, business processes, chain of command, etc. This is going to vary from project to project, and therefore a one-size-fits-all, the true cost of requirements are in your face, approach of XP doesn't work. It can work in the rare case you've got a project sponsor who's open to it, but your toolbox needs to have more options available to you.
I also have the feeling that demonstrating to the business sponsors that we know what they want politically in addition to the software technicalities, and learning to speak their language can also help with the issue of having our jobs outsourced. The real issue of requirements is figuring out what it'll take to please the person in the right political position. Enterprise software is never developed in a political vacuum, and we can either choose to accept that fact and work within its framework, or continue in our frustration and gripe amongst ourselves at how things should be done.