Design By Committee and Other Bad Ways to Plan Development Projects

It's no secret that successful IT and development projects require careful planning and requirements gathering. But striking the balance of whom to gather those requirements from is like walking the razor's edge: without enough input from key players, you can eventually end up in utter ruin.

Michael K. Campbell

April 2, 2009

6 Min Read
a group of business people smiling inside conference room

It's no secret that successful IT and development projects require careful planning and requirements gathering. But striking the balance of whom to gather those requirements from is like walking the razor's edge: without enough input from key players, you can eventually end up in utter ruin, and when too much input is solicited, you may never get started.

My Recent Difficult Experience

I ran the universe, job interviews would be different. Instead of primarily focusing on alphabet soup and asking candidates to solve problems or talk about their technical proficiencies, I'd place more emphasis on what candidates have learned from past mistakes and failures. I've actually done this when helping clients hire candidates for various positions, and the results have been very telling - as they can provide a decent insight into motivations, drive, candor, ego, and the like. I also think that failures and mistakes provide a huge number of possibilities for growth.

Related: Good Development Project Planning: Establishing Project Champions

Along those lines, I recently encountered ... um... a powerful opportunity for growth. And, if I'm being honest, this opportunity for growth was actually the largest failure of my professional career. So, what did I do wrong? Simple: I gathered requirements for a development project without getting input from all of the right people. With an insanely tight deadline in place I made the mistake of gathering requirements only from line-of-business LOB) users of the final product. To be fair, these users were definitely subject matter experts and I spent a good deal of time with them. I even videotaped several hours of meetings to make it easier to go back for clarification of various needs when working through actual implementation. But while these users had the tactical vision under wraps, they didn't have enough of a strategic vision for how this application, and its rollout, would play into key initiatives currently under way.

In retrospect, not getting full buy-off on requirements and deliverables was such a colossally stupid move that I can barely even contemplate how I did such a thing, nor can I barely even stand to mention it. I think that my optimism and focus on solving immediate problems at hand blinded me to seeing the bigger picture. The universe was only too happy to make sure I learned my lesson from this whole affair - to the point where I completely lost my shirt on this project. So, while it sounds dumb that I would even have to say this out loud, I'm now 100% sold on the fact that I'll never, ever, ever, ever again engage in a development project that doesn't have a fully delineated SOW with buyoff from all key players and stakeholders in the project's success.

Design by Committee

Obviously, failure to include key players when planning and implementing development projects or IT initiatives is bad. Perilous in fact. But over the years as I've participated in development efforts, helped with IT initiatives, and worked on technical evangelism projects, I've seen the opposite be just as dangerous - where too many players had input on the shape and outcome of the project to the point of causing excessive amounts of paralysis and thrashing.

In fact, I've experienced this phenomenon so many times now that I've started to liken it getting a group of 15 people together to order 3 pizzas. To make sure everyone is satisfied, everyone in the room takes it in turn to mention 2 or 3 toppings that they would like. Only, as it always invariably works out, the last person to provide input is either a vegetarian, or allergic to something like cheese or tomatoes. In other words, sometimes consensus can be crippling.

As a case in point of the damage that consensus can cause, remember how (a while back) Microsoft embarked on a $300 million marketing push to address potential mistrust and bias against Windows Vista? One part of that plan involved hiring an army of Windows Vista 'Gurus' to work at Best Buy and Circuit City in order to "answer customer questions and defend Vista's reputation against skeptics". Frankly, that didn't sound like a bad approach. Where that plan went off the rails though was in how much Microsoft was willing to pay these Gurus: $20/hour. In other words, the last group to specify their preferences for this proverbial pizza were the bean-counters - as we all know that $20/hour doesn't equate to 'Guru' caliber specialization in any IT endeavor. By keeping compensation low, Microsoft basically made sure that they wouldn't be able to attract the kind of talent that would combine technical prowess with the interpersonal skills needed to address potential customers without coming off as scripted automatons, arrogant jerks, or just plain old really creepy nerds. In fact, I'd wager that the end result of this whole endeavor was a complete failure - and I'd attribute that failure to “design by committee.”

The Importance of Getting it Right

I bring all of this up, because given the economic climate that we're currently in, getting the balance right can not only make the difference between success and failure, but could definitely play a huge role in helping organizations manage cost overruns and wasted energy and effort. The problem is that I'm personally too focused on development and wrangling with tough technical problems that I'm actually clueless when it comes with best practices for determining how to get the Goldilocks ('just-right') degree of input when gathering requirements and determining SOWs.

Related: The Best Laid Plans

My hunch too is that many IT professionals and developers are in a similar position. What's more, with reductions in force and some of the cut-backs we've seen, capable project managers who specialize in these kinds of issues are potentially going to be less available than they formerly were, which places a larger burden on us to help make sure that we're striking the right balance. And given the cost of failure in today's climate, I'm personally convinced that learning the hard way isn't the right way to go about figuring this out.

Call to Action

But sadly, at this time, all I've got are horror stories and anecdotes about where I've seen this process of establishing who to include (or not include) go wrong. That, and I've got some questions:

  • How do you go about defining who should be involved when it comes to requirements gathering and defining a Scope of Work?

  • How can you tell if you've missed someone (before the cost of re-including them skyrockets)?

  • What do you do when a shareholder, group, or subject matter expert isn't included but swears that they should be?

  • What do you do when the parties mentioned above start pulling rank, or exerting additional force for inclusion?

  • Would making departments or department heads pay part of development or rollout costs from either actual allocated budgets or some form of rationed 'focus points' help improve issues, or would it just create needless bureaucracy?

  • If you can get programs from the previous question to work, how do you prevent the creation of siloed applications that eventually cost more to integrate and grow?

  • What has worked for you in the past?

  • And, be honest, what hasn't worked in the past?

  • Are there any books, references, blogs, or other resources that you've found helpful in determining who to include when it comes time to gather requirements or create (and approve) an SOW?

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like