Leadership

Document project ideas by creating business requirements

Consultant Ken Hardin talks about creating business requirements when everybody already has an idea of how a project will work.

Last week I began a discussion of a "tailored extreme" approach to project documentation I developed while working for a client who was not big on project documentation or a lot of cross-team meetings once development began. Part of the process -- jotting in a few pages of business goals and metrics -- was almost entirely CYA in terms of my perspective. Those things really needed to be in writing somewhere I could see them, even though they weren't being employed in what could be considered a formal project justification process. That had already happened in the company's very informal culture.

The next phase of the project, or at least of my documentation, was to develop a business requirements framework. Occasionally, I would inherit a bulleted list of ideas or requirements; other times, the requirements would be trapped inside the head of managers who had approved the project as a "go."

At this point, allow me to re-emphasize -- these were dot.com boom veterans who had very clear ideas about what they wanted for their business, a pretty large-scale Internet publishing site. The issue was not that there was no thought going into product decisions or design, just that these ideas weren't being documented and, as such, sometimes were not clearly communicated all the way down the project food chain. This is the point of documentation.

However, there was no point in pretending that I was entering the business requirements phase of a project in full discovery mode. The trick was to either cull or translate the mostly baked notion of the project into a format that I could later flesh out into something that approximated a functional spec.

I ended up with a business requirements outline that was a little down the line from a traditional requirements document. There's no point in spelling out "the system will allow users to input client mailing addresses" in a business where the VP knows the DB field label where that information will ultimately live. The key to good documentation is having just the right amount of documentation.

What I included in these business requirements varied from project to project. As a rule of thumb, the requirements ended up being about 25 percent of the eventual completed "tailored extreme" spec. I try to keep completed specs to four layers deep (e.g., the specific attributes of a production Web page's header meta would live in document section 1.2.3.4), and these business requirements outlines would never get deeper than level 1.2.

Even so, they ended up being quite detailed, at least by business requirement standards. Since in many cases the users knew what type of control or interface they wanted, it made perfect sense to go ahead and include that in the business requirements. After all:

  • a) These documents are always up for discussion and can be changed with feedback from any group, including Dev, and
  • b) Sometimes Dev codes what it deems best anyway ("extreme"), which of course can be a hit or miss. It's always good to have a record.

I tried to include business process flowcharts (which are just golden in almost any context), but refrained from including mock-ups of various interfaces -- this despite almost always having done extensive whiteboarding with my line-of-business contacts prior to submitting the requirements for review. My reasoning was that everybody in the process needs to feel invested, and the folks in Dev and QA can have an enormous amount to add the front-end design of any project. And (as I'll discuss next week) mock-ups have a sense of finality to them that you don't want to be transmitting at the business requirements stage in an "extreme" or "agile" environment.

Since everybody had an idea about a given project before the business requirements documentation began, this phase of the process went pretty quickly -- maybe two weeks, and that was working part-time on an initiative. Two reviews were usually all it took to wrap up the scope and direction, and then on to the fun part -- describing how things actually work.

About

Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRe...

9 comments
Tony Hopkinson
Tony Hopkinson

you come up with a project and then manufacture a business requirement. With, using, through, a vague doesn't bare close inspection reference to... No wonder we have bad rep with the business types. No business requirement = no project = no reason to waste resources documenting it.

TownsendA
TownsendA

A Business Requirements Document is standard COBIT practice. For those with ERP systems some is overdone but is good for governance and we IT people have the worst reputations for documentation. What developer/technical support likes to spend hours regurgitating what he did so someone else can steal his ideas?

Brian.Buydens
Brian.Buydens

Ken: Thanks for the article. I have recently gotten interested in Business Analysis as a formal process and have been looking at the documentation provided by the IIBA. I know that things aren't always done according to formal procedure but it would seem that by the project stage the business requirements should already be known and the project should be focusing on the best implementation. It seems that Business Analysis as a formalized study is kind of a new area and I would be interested in your and other people's opinions on the field, and what certifications are recognized by clients etc.

robinfgoldsmith
robinfgoldsmith

These are all product requirements/specifications, not REAL business requirements deliverable _whats_ that provide value when satisfied by the product _hows_. Creep occurs when people focus on the _hows_ without adequately understanding the _whats_. There is no better example than dot coms of seemingly cool products that failed because they actually provided no value, largely because the value never was addressed adequately. This deficiency preceded dot coms and continues unabated today.

avindia
avindia

Hi Ken, I work as solution architect(Infra) and I see requirement documents is somthing plays very important role to convert business requirement into technology requirement. I was looking for this topic for long time as everyone is taking only on PM level (Cost and timelines) Since Business analyst who interacts with Client to determine thier requirements,he should be able to discuss the requirement either face to face or over call before delivering Requirmet Metrics to work on Architecture. Do you have some templates you can share for Business requirements ,requirement document etc? Thanks and Regards Avinash

bill
bill

Isn't it surprising how putting something down in black and white focuses people's minds? Often I have written up what others thought was "the blooming obvious" to find that there were many versions of what everyone knew they wanted. I also touch base with the support guys at the beginning of a project to ensure that they have a voice, feel part of the project and we don't have to code in support & maintenance as an after thought - the "in-life guys" also bring gems like; don't forget archiving and last but not least printing......

TownsendA
TownsendA

Formalised study of Business Analysis is not that new. It was originally part of IT back in the days of punched cards and tape. It was overlooked and seen as a waste of time by some ERP systems and then the IT industry turned its back on it as a waste of time. Oh how we need them, skills learned here will never fade away.

Brian.Buydens
Brian.Buydens

While Business Analysis may not be new, my impression is that being certified in BA is new. (I could be wrong on this so I am looking for information.) Do you have advice on which certifications are more useful than others? Regarding COBIT, I read about it briefly and it seems focused on IT (which seems reasonable given this crowd) but I see BA as bigger than that. There have been times when I talked a client out of a new computer project because the business requirements didn't warrant one. (I may be talking heresy.)

TownsendA
TownsendA

Certifications by professional institutes like IIBA are new. They are developing their own BABOK like PMBOK was developed as well. It also regulates ethics and professionalism. In the old days organisations like IBM had their own BA's and certifications/courses. I find BA's of great use as a PM in my organisation. They interpret (One wonders if different languages are spoken) what the users want for the technical and application support persons.

Editor's Picks