Requirement Elicitation = A Perpetual Process

For many years, requirement elicitation tasks have been misrepresented as having a traditional (plan-execute-close) workflow. This assumption about elicitation didn't come about after a detailed analysis of the task itself. It was a byproduct of traditional thinking about project management tasks. Even with the emergence of iterative agile workflows, stakeholders still tend to think of requirement elicitation as a linear process performed and completed before the "real" project work takes place. 

Brenda and I doing the "rail ride" just outside of Tillamook Oregon. (loads of fun!)

Brenda and I doing the "rail ride" just outside of Tillamook Oregon. (loads of fun!)

As wonderful as a business requirements document (BRD) can be to adequately setup a project for success, its value potential is diminished (if not completely removed) when it is excluded from iteration efforts. The real danger is that once the requirements have been completed, many project teams completely ignore the remainder of the requirements lifecycle.

This comes about because the needs, wants, constraints, risks and related scope components can often change as projects execute. The "requirements" tend to become the "suggestions" and the project manager, technical teams and even quality assurance make undocumented ad hoc decisions about what is best for the project. 

Why do they do this, you might ask? My best guess is because the illusion that the project is moving forward because the team continues to report (verbally) how busy they are.

Another valid question you may have is, “where is the business analyst during all of this?” Typically, they have been assigned to work on another project to build a business case or BRD that will ultimately have the same fate as I described above.

Instead of the BRD being a document that is stored in some seldom visited location on a network shared drive, it should become a “living” resource in which all project work is managed. This is why project components such as Kanban boards, user stories and managed iterations are so effective in guiding complex projects to success. No one person has the ability to "jump the shark" in regards to what is needed for the project. 

I have to say that my confidence in the traditional requirements process in waterfall environments is eroding quickly. Unless waterfall project management is strictly enforced by the leadership within the organization, it seems that the requirements lifecycle tends to struggle and projects suffer because of it. 

© 2018 Dwayne Wright