Welcome to 2012, a new year of projects and a good time to discuss the topic of requirements. With the advent of any project, there are foundational constraints a project is assembled to communicate an end purpose. Healthcare organizations are finding themselves swamped with IT projects these days. Many are grabbling with EHR, ICD-10, Business Intelligence, and the like. However, whenever considering these IT projects, one must consider the requirements.
Like the rebar in cement or the laminin protein cell’s importance to the human body, requirements are what give a project a cohesive launch point. The art of writing good business requirement is found in declaring “what” is desired with as much detail as possible without stating “how” to achieve the “what.” Having worked on both side of the project table, Business and System teams, has given me a well round view in regard to the gathering and documentation of business and system requirements.
This a first in a five part series surrounding writing sound, concrete requirements, how to identify and recover from the poorly written and employing techniques to gather aspirations. It makes good sense to do the research into “what to achieve” and here’s why. Requirements, depending upon how well they are written and/or researched, can give a project an ease of understandability or dispense an undercurrent to slow progress to the speed slower than an earth slug or worse, ensue confusion to halt project momentum and cause tempers to flare!
As said many times “What does not kill us, only makes us stronger,” and to many, writing requirements is a painful undertaking. The challenge comes with the following:
- Stating the not-so-obvious and relaying statements to others – seeing through another’s eyes
- Stating the “WHAT,” the end results – the goal to achieve
- Stating the “WHEN,” – better known as the SLA (Service Level Agreement) – the speed in months, weeks, days, hours, min, or seconds a goal is delivered
- Resisting the temptation to state “HOW” to achieve the “Desired WHAT”
My point is that my involvement in projects has more than exposed me to the Good, the Bad and the Ugly of requirements and how to turn the Bad and Ugly into the Good.
I welcome your views of requirement gathering as I move through the dialogue of the “WHAT,” the “WHEN” and techniques to gather and document requirements.
