Categories
Business Process Tools Uncategorized Writing

Why Bother Writing Requirements?

We’ve recently been approached by two different companies about writing requirements. The first, a small company, wanted to develop a dashboard to replace a third-party application it was using. The owner, who had most of the information in his head regarding what the new dashboard should look like, what it should do, etc., suggested we send one of our writers to his location to study the existing dashboard, spend a little time with him and some of his key people to learn more about the functionality the dashboard needed to support, and “capture” this information so he could give the requirements to a developer or offshore the project.

During our initial conference call, he showed us the existing third-party dashboard and gave us some background as to what he wanted the new dashboard to do. We studied the material, thought long and hard about how we could best approach the material, and told him we would probably need about a month to put something together that he could actually give to a development company. He was thinking the document should take a few days, not 20, and since he hadn’t budgeted that much to the project, didn’t pursue it – at least with us. The dashboard, as far as I know, has not been developed. Neither have the requirements.

The second company was quite a bit a larger. It wanted to develop a web portal so its partner companies could submit equipment for testing and track the progress of the testing. A web development company was contracted to begin the project but there had been little progress. Again, most of the information required to develop this portal resided in the head of one person who had tried to “explain” to the developers what he wanted but alas, no joy. Regardless of how many times he “explained” what he wanted, the developers just didn’t get it. He finally accepted that he had to have written requirements if he were ever to get the project done and approached us. We agreed to write the requirements, work on process flow diagrams, and build a wireframe to clearly define exactly what the website needs to look and what it needs to do. Once we get his ideas on paper, he can then have the web developers begin coding the site. But not until then.

The coincidence of two companies – one with under 10 employees and the other, a global company, with thousands of people – approaching us for the same type of work struck me. So why write requirements? Simple: it doesn’t matter if you’re big or small, without requirements you can’t build the product you want. End of story.

Leave a Reply

Your email address will not be published. Required fields are marked *