Why did the requirements document fail?

Why shouldn't you give a 100 page document to your cat-sitter? Writing a documentation and sharing that with your cat-sitter might seem like a better idea. In the "information stone-age" of the early 90's, software delivery was based on a requirements document created as the first phase of the waterfall model. It seemed like a good idea back then. In this analysis phase, a long document was written. This document contained many details about what's being built, ahead of time, as well as an executive summary and product description and possibly many other sections. The requirements document was then approved and signed, and it represented a commitment. Requirements documents assumed that it's possible to know every eventuality up front and that priorities would not change. Obviously, they were not cast in stone. They were often revised, and sometimes even drastically changed. 

Now, imagine our cat-sitter getting a 100-page requirements document with many sections. What are the chances that she misses or misunderstands something? Software developers cursed with a massive documentation feel the same.

According to Paul Vii and most other experts, waterfall was the most popular product management model in software development. In the first phase of waterfall, usually named analysis, the business analyst and the product owner will put together a set of requirements. Why has this approach failed? 

• The waterfall model's requirements document can lead to dysfunctional communication, lack of collaboration, and understanding. The emphasis is often put on negotiation. Cat-sitting and software development share the hate for contract negotiations, and walls of text are usually a source of a few misunderstandings. I hope that you appreciate the irony of arguing against writing long texts, while my arguments are part of a long text in a printed book.
• The requirements documents are intimidating, not just for cat-sitters, but anyone involved in a project. When you get a requirements document, the first thing that might cross your mind is whether you will ever be done with this, or what exactly you will deliver at the end.
• Documents usually don’t break down projects into tiny functionality bits, and some functionalities can be lost among thousands of lines of text. Now, imagine if the location of the cat food was on page 74, paragraph 8. Remember, there is no easy way to contact you.
• Such a document places our process above people. In our case, it would seem as though we cared more about the paperwork than the cat-sitter and her interactions with our cat.
• Even if you could create the best masterplan ever, unforeseeable things can and will happen. Rigid documentations and plan-following mindsets will make responding to change backbreakingly hard. What if your cat explodes while you are away? You cat-sitter will flip through your lengthy documentation over and over, not finding anything about exploding cats. Although cats very rarely, if ever, explode (unless you are playing the Exploding Kittens card game), in software development even more unexpected things can be produced by the machine-spirit.
• Even the best ideas will need continuous improvement, to stay competitive. If you regularly go on holiday, sooner or later technology will make most of your cat-sitting requirements document quite obsolete. With the Internet of things connected to your cat bowl, you will not need a cat-sitter to feed your cat manually. They can simply download the app to their phone.
• People want to work on making the world better, not spend time creating or understanding a long documentation. The cat-sitter wants to concentrate on making your cat happy, not lawyering a comprehensive documentation.

As you can see, our problem will not be solved by telling the cat-sitter what to do or writing a comprehensive documentation.

In Chapter 2, User Story Map – Requirements by Collaboration and Sticky Notes, we will see how maps and improved communication will address the problems of rigidity, lack of collaboration, and inflexibility of traditional requirements documents.

This book will teach you many User Experience Map types so that you can pick the right tool for the situation. The examples in the other chapters are product management, usually software development problems. I certainly don’t expect you to build software for your cat-sitter (at least not in this chapter.)

There is a communication technique much older than the writing technique. You guessed it, some 40,000 years ago our ancestors started to draw. At first, they didn’t draw maps, but that changed more than 15,000 years ago. A prehistoric map of the night sky on the walls of the caves at Lascaux, France, testifies this. Obviously, the creators of that map preferred hand drawing over sophisticated software products, so we will also start with hand-drawn maps.

To solve the cat-sitter's communication problem, let’s draw a map using pen and paper. Often sticky notes or other small pieces of paper are used because it's easier to rearrange them. We will create sticky notes based user story maps in Chapter 2, User Story Map – Requirements by Collaboration and Sticky Notes, but here, we will just use a sheet of paper. Don’t worry if your drawing skills stop at stick figures. Maps can be composed of some simple lines and a few written words. Some people do this instinctively during meetings. The most important thing to remember is that although mapping is a powerful tool, maps should never replace conversations.

It’s easy to overdo mapping, hoping to reduce the need for conversation. Remember that the map is not a substitute for a conversation. It will also not work if you overdo it, as it will be confusingly complicated for others. It’s a tempting idea to draw a map so detailed that you can simply send it to the cat-sitter and get done with it. Don’t do that, it’s a terrible idea. I have seen agencies creating journey maps as a deliverable and e-mailing it to project stakeholders. Although they can look great, they rarely--if ever--meet the goals or solve problems alone, without a conversation.

We agreed that you will draw a map, and you will have a conversation where the map will help. You could also create the map during the conversation if you are an experienced mapper, but most of the time it’s better if you have the first version ready for the conversation, and create a new iteration together with the stakeholders--in our case, the cat-sitter.

Before you start drawing, you need to decide what to draw. It’s perfectly fine if your approach and strategy are not crystal clear at this stage.