Home > Uncategorized > Bad Requirements – My Fault or Yours?

Bad Requirements – My Fault or Yours?

As Josh mentioned in his last post, he’s been reading The Mythical Man Month by Frederick Brooks. One of the things I remembered best from the book was that projects commonly fail because of bad requirements. As a developer this point is very important to me – it means that when a project fails it’s somebody else’s fault.

Who’s really responsible for requirements? 

 

The entire team is responsible. This should be true for all aspects of a project – everyone owns everything.

 

In many organizations only one or a couple business analysts are responsible for writing the entire requirements document. The rest of the team does not get involved with requirements and no one asks many questions when they get them. The developers use their own assumptions when a concept is not clear or an edge case is not covered. The testers also make their own assumptions about how things should work and then argue with the developers whether or not something is a bug.

 

It’s no wonder that projects with smart people can produce utter crap.

 

Bad requirements can kill a project, so there’s a lot of pressure to get them right. That’s not a very good motivator for getting your BAs to start producing requirements. Even for the agile teams there’s another major demotivator: an entire team of brilliant people are going to point out everything done wrong in the requirements. Being corrected is very humbling, especially so when the person being corrected is supposed to be an expert.

 

There have been times where I, a developer, wrote requirements and handed them off to the BA when it seemed that fear or anlysis paralysis was stagnating progress. I made sure to clarify to the BA that what I did probably wasn’t perfect and their expertise was needed to correct it. The response was practically immediate and we had our first set of solid requirements in no time. Life Lesson: It’s a lot more fun to be the corrector than the corrected. I don’t mind being the guy that gets corrected if it means we get our work done faster and my teammate gains more pride and statisfaction in their work.

 

If everyone is responsible, when should everyone get involved?

 

Here’s a question I’ve been meaning to ask more in interviews: When is the right time to bring your developers and testers onto a project?

 

The right answer: It depends.

 

Just kidding. It depends is the expert’s answer for everything. I’m looking for something along the lines of: Get them on board right away.

 

This is important, so let me say it again. Bring your developers and testers on board as soon as possible.

 

Why even a great BA shouldn’t be expected to take on requirements gathering alone

 

Well, your BA should be someone that understands the problem domain extremely well. Either one of the superstar users or their supervisor are great picks. They know all the important problems and they have a very personal stake in creating the best tool possible.

 

Unfortunately, these BA folks typically doesn’t think like a geek. I’m not saying that they aren’t technically savy. No, I simply mean that they don’t obsess over what could go wrong.

 

If you have designated professional BAs in your organization, you’re getting a slight hybrid – someone who can learn some of the problem domain and sometimes thinks like a geek. And sometimes you have to go this route because you simply can’t afford to free up a user/supervisor who knows the problem domain well because they’re too swamped with their regular everyday work. Consider this when you are filling future BA job positions – prefer to promote your internal superstars rather than hire someone external. It might be a huge pay jump from a Customer Service or Data Entry role, but these kinds of folks often know the business as well as or better than anyone else.

 

Anyway, I was saying we need some what-could-go-wrong thinkers to help mold the requirements into a masterpiece. Throw the geeky developers and testers into the mix and you’ll have most everything covered. They’ll ask questions like:

“What happens if the user accidentally submits a form before they’ve finished filling it out? Can they correct it after that point?”

or

“What if a user tries to edit the same account that another user is already working with? Would it be helpful to let the user know who else is working on the account so they don’t step on each other’s toes?”

These are the things a geek personality thinks about. These kinds of what-might-go-wrong thoughts make geeks miserable at dinner parties but absolutely critical for outlining project requirements.

 

(Side Note: I’ve twice gotten to work with BAs that were supervisor types that could think thoroughly in what-might-go-wrong mode along with the developers. These people do exist but are extremely rare and their names always begin with an ‘L’ and end in an ‘a’.)

 

Don’t do the wrong thing for the project and excuse it as “saving money”

 

Speaking of what-might-go-wrong thoughts… some of you might be wondering how in the world a tight project budget could afford bringing on developers and testers so early. After all, requirements can’t possibly consume everyone’s time. Management will never approve paying everyone to sit on their thumbs all day!

 

Your developers and testers can keep busy as soon as they know a small subset of requirements. The developers can start coding and testers can start writing test scripts. But also think about how much wasted effort is saved by having better requirements. Your developers and testers will also better understand the value of what they’re delivering and, if they are creative and motivated, can add a lot of innovation to the product.

 

I’ve seen the altervative and it still gives me nightmares. The worst is when after development the testers are handed the requirements document and told “OK, you’ve got two weeks to test this thing!” It will take at least two weeks for a normal human to understand a project let alone be familiar enough with it to test the dark corners of the UI.

 

In closing, don’t forget: Great requirements are the first step toward a great project. Take ownership in them and do your part to make the team successful.

Advertisements
Tags:
  1. August 13, 2008 at 9:52 am

    I used to think requirements were the job of the BAs or SMEs or someone besides me (the developer). Now I agree with you, Marc – the requirements are everyone’s job. If I want the project to be successful, I have to do my part to create good requirements.

  2. Eric
    August 13, 2008 at 10:40 am

    Hey Marc, great post. I have a couple of comments..


    If you have designated professional BAs in your organization, you’re getting a slight hybrid – someone who can learn some of the problem domain and sometimes thinks like a geek. And sometimes you have to go this route because you simply can’t afford to free up a user/supervisor who knows the problem domain well because they’re too swamped with their regular everyday work.

    In some organizations (not all), but namely ConAgra Foods, I’ve found the hybrid BA to work best, because they were able to pick up the business needs of each operating unit quickly while at the same time understanding the capabilities of the technical side and the general level of efforts to accomplish certain tasks. This always made for great requirements, usually without much ambiguity or incompleteness which I’ve found more frequent from not tech business user BA’s. When we did have a question, we asked the BA. If they didn’t know the answer, they’d check with the business and get back, but we didn’t have to manage that. It was bliss! Every techy, anti-social developers dream. But I concede that this model doesn’t work for everyone, everywhere and generally for it to work, you need a really smart BA, who can quickly learn the business domain for the requirements they’re writing.

    (Side Note: I’ve twice gotten to work with BAs that were supervisor types that could think thoroughly in what-might-go-wrong mode along with the developers. These people do exist but are extremely rare…)
    I think ConAgra was hoarding them all when I was with them back in 2004-2006.

    Take ownership in them and do your part to make the team successful.
    tru dat, don’t finger point. Participate and share successes and failures.

  3. November 8, 2008 at 11:29 pm

    “One of the two most common causes of runaway projects is unstable requirements.”

    http://www2.computer.org/portal/web/buildyourcareer/fa035

    It seems like Fred Brooks isn’t the only one who believes bad requirements can hurt a project.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: