Greg Vaughn's Blog

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.

Comments

• Requirements and outsourcing
  We have all read the announcements: leading US technology employers are making noise about opening development centers abroad. Conversely, they rarely announce the failure of an overseas venture.

  I have heard about some minor successes with outsourcing maintenance of obsolescent software. But do US businessmen really think that they can adequately convey their requirements for new software to foreign-language developers whose workday begins at 9 PM and ends at 5 AM? I for one would like to know how.

  Posted by: tsnee on August 14, 2003 at 08:50 AM

• Good question and further thoughts ...
  If you think about software in terms of the "simple" challenge of transfer of information, what the user wants, into what the developer produces, then outsourced development must provide some real difficulties for certain types of project. Any project where the requirements are in anyway open or unknown must be a real challenge. Having worked on a couple of these type projects, it is really difficult. You have to prototype like mad, you have to specify everything in pin-point detail, changes are tough and because it was in a subcontracting situation, impact assessments are everywhere. It really was difficult. What interests me, is how many outsourced projects are really working and delivering ? tsnee's question really.

  There must be a large number of failures. It's just so difficult. Anybody, got any good research/stats here ? Do projects that have Greg's type of business commitment issues, stand a chance ? I don’t believe so.

  Still, some projects must be working (especially as outsourced development isn't new to the industry) and the financial incentives (read: cheap labour) for large companies will be too compelling for them to ignore. Sure it's going to cost them a fortune to get it right but they have a habit of getting want they want ...

  To conclude, agile processes must be reasonably well position here, especially if they leave open the ability to use significant levels of detailed specification. Essentially, the "front" team will need to be very creative in terms of they way they get the detailed specifications produced and then the construction team will need to be very tight in terms of producing the software in line with the specifications. Interestingly, you could imagine taking elements of XP and applying them to the work of both teams. Just because there are specifications doesn't necessarily mean that there can't be innovative ways of performing the work.

  The real challenge is in the "transfer of information" from the "front" to the construction teams. We solved some of these problems by having design workshops where the two types of team (and yes the other teams like QA etc too) met and trashed out a high level design together. This was a deliverable from the workshop for which both teams were responsible. Obviously, this involved travel (not much fun these days) and still suffered from some of the usual communication issues once the teams were back in their home countries. The detailed specification helped here.

  Anybody else have any experiences to share ...

  btw, sorry about the length of the post! Greg, I hope you don't mind. Btw, guess ... I'm not working at the moment!!

  Posted by: robin_shorrock on August 14, 2003 at 02:30 PM

This work is licensed under a Creative Commons License.