Business requirements are like sheep. I bet they are roaming free inside your organization right now. To have successful IT projects that truly address the needs of the business, the requirements (like sheep) need to be gathered using the right tools and guided to safety.
They must be gathered.
Sheep may travel together or wander off on their own, but eventually they need to all be pointed in the same direction, walking toward the same goal. When it comes to making a project successful, all user requirements have to be accounted for. Those requirements express the must haves, needs, wants and wishes for your project.
They may already be documented, but a great many may reside in the minds of your stakeholders. Maybe the requirements are for a new process that does not currently exist. In the end, the only way a project can be proven successful is if the end results fulfill the business requirements. They must first be gathered – pulled from the bushes, called from afar and assembled. A thorough BRD (business requirements document) may be the perfect pen in which to keep all those sheep, uh . . . requirements.
They benefit from the right tools.
Just like the shepherd’s crook, the right tool can make the work of gathering easier. Your requirements must be documented and agreed upon. Using tools like Excel or Team Foundation Server to create groups of functionality, or features that group user stories together can be very effective. Each requirement or story gathered from a user can be corralled into separate features to better organize them for later.
These user stories provide the backlog of work to be done and can be paired with acceptance criteria to ensure success. The backlog can be used to generate and prioritize project tasks and help to drive the effort toward a well-defined end. The business requirements should drive the work, and the right tools make sure that our well documented requirements are being fully addressed.
They must be guided.
So it’s not enough to gather all the sheep and point them in the right direction. They have to be guided and cared for – fed, watered, groomed and nurtured. Creating a backlog of user stories is a great first step, but those stories must be guided throughout the life cycle of the project. The term “grooming of the backlog” fits our sheep metaphor pretty well.
Requirements will change over the life of the project. They may grow and mature or even become obsolete. Maybe you pick up some new sheep as you go. Maybe some try to wander off when you’re not paying attention to them. Depending on your project methodology, you may gather as many requirements as possible up front or choose to gather them as you go. Either way, you must be prepared to deal with changes in scope, definition and order.
They must be protected.
The keen eye of a good shepherd is always on the lookout for potential threats. The wolves are watching and waiting for their opportunity to pounce. The primary threat to requirements, like sheep, is losing them along the way. Good requirements shepherding demands that requirements are seen all the way through the project life cycle, from eliciting to documenting to prioritizing to developing to testing and on to user acceptance. The business analyst is the shepherd to own the sheep and own their well-being.
Making sure your requirements are gathered well, watched closely and carried all the way through your project is a key to success. Fully understood and vetted requirements will lead to a concise scope, happy stakeholders, higher user adoption of your software and increased ROI. I’ll be talking more about how to use TFS as our tool of choice for shepherding requirements, so pick up your shepherd’s crook and come along.
