Throughout my career I've been involved in numerous requirements gathering exercises. Whether its for the formulation of strategy or the requirements for the development of software, understanding and capturing users' requirements is key to the process. Over the past while however, I've come to repeatedly see that the process used by many organizations is flawed. It focuses too much on the need for documentation. The process focuses far too much on the creation of documents. All too often the process morphs from capturing requirements (which is valuable) to the creation of documents (which is of low value). In many cases, unfortunately, the documentation becomes the deliverable. This fundamentally misses the point of why we're doing the requirements caption: so we can align IT to the business. Instead, the creation of documentation becomes too rigid, a mere exercise in checking boxes and finishing some templated approach.
Now don't take me the wrong way, I'm not saying that documentation isn't important. What I am saying is that the documentation shouldn't become the end-game focus. It's not the deliverable! Nothing hampers a project more than creating the "perfect documentation" and then missing the true value - that you've captured the true business needs and they are adequately provided to the next phase of the project. Perfect documents don't add value. In my opinion they take up far more time to create than the value they deliver.
So what to do? Over the past couple of months, I've refined an application I created to capture requirements. It's a database driven application I created in Filemaker Pro that allows me to capture requirements on my iPad or iPhone as I receive them. This has proven to be quite useful as it is adaptable to the situation. In working sessions I capture the requirements via the tool. It works well, but in many ways, it is like the normal process we are use to. Instead of scribbling in a notebook, I enter it into a digital form. Here, however, the tool allows me to depart from the traditional approach. All requirements entered are tagged as they are fed into the database. I have numerous tagged fields, such as section of the document, type of business need, whether they are issues or needs. This tagging allows me to later run various reports which in effect auto-generates the documentation I need. That makes the process more efficient.
Where the value really becomes apparent is when more than one person is feeding the database. As someone else from my team captures a requirement they feed the database. This dynamically populates the database, and provides the raw materials for the documentation. The capture of user requirements begins to happen at multiple touch points. Like a network that becomes more valuable with a great number of devices attached to it, now the capture process becomes more valuable as the number of contributors increases. Previously when the focus was the document having more people work on the requirements capture meant creating issues for the team: version control, integrating documents, transcribing notes. With the mobilize capture tool, the more contributors you have capturing requirements, the richer the end result.
By creating this capture tool, I also found that the process became fluid, breaking out of its rigid confines. For example, when I was at lunch with a stakeholder, having a casual conversation, I picked up an interesting business nuance. An issue he'd been having that came about in conversation naturally. I captured the item at the restaurant table via my iPhone, which has a copy of the requirements capture app. That item was automatically added to the repository back in the office. This changed the role of documentation: rather than making it the focus (the deliverable) it gets pushed to the background. It eliminates that dysfunction on traditional projects where the requirements documentation gets in the way of the real process of understanding the user requirements.
Lastly, the real breakthrough was what I found at the end of the process. I created documents easily and got stakeholders to sign-off. That was good. I would have considered that a real win given that the process ended up being fluid and about requirements and the documentation was an easy output rather than the ongoing focus. What floored me though was what came next. The development team asked for a copy of the requirements repository and began to build off of it to best align the requirements to what they were building. They created custom reports to best suit them for their process. They added elements to the repository so they could track the inventory of their own code. Further, the strategic process I was continuing now got to take requirements from the previous project and start to cross reference them to other strategic priorities. In a sense, we are creating a networked collection of requirements - real intellectual capital.
It's been exciting and I look forward to continuing to develop this concept and the tool as a part of my ongoing process for understanding business requirements and mapping them to IT initiatives and application development.