He Who Gets Slapped – Leveraging the project requirements after analysis phase to avoid the tyranny of the urgent and help guide the project to a successful conclusion
Someone who totally avoids acknowledging a problem is sometimes referred to as “burying their head in the sand like an ostrich.” Even though ostriches don’t actually do this, this colorful phrase has been around a long time. Probably most of us have seen this type of behavior and have developed methods to avoid it or correct it on our projects. I believe a more common problem arises on projects when requirements are approved and then the team just wants to get on with the “real work”. Sure, the requirements will be used and referenced but not used to their full potential to help guide the project to a successful completion. In the 3rd book of Jonathan Swift’s satire, Gulliver’s Travels, the leaders of Laputa are so focused on the abstract that they can neither speak nor hear, yet alone lead effectively. There is no planned forward thinking. They rely instead on assistants to whack them on the head constantly to direct their attention to the right or to the left, to speak or to listen, to address the immediate concerns. When we run our projects, we should strive to avoid the tyranny of the urgent lest our projects become a series of fire-fights. Leveraging the requirements during the design, implementation and testing phases is a great way to mitigate the tyranny of the urgent.
First Things First:
Representatives from the design, implementation and test teams should be involved during the requirements analysis phase, along with representatives from other key groups appropriate to your organization (e.g. business, marketing, product customer support, translation, internal support, I/T, technical writing, consulting services, deployment, post-deployment field support, finance, pre-sales application engineering, and if your software is part of a larger system then potentially a whole host of hardware groups interfacing with the software). Representatives from each of these groups will provide a unique perspective on the requirements. For example, the business reps can help with the prioritization of the requirements by their values to the business. The architecture and design reps can tell you early on if the requirements are even feasible. The test team reps can tell you if the requirements can be tested thoroughly and how costly to test them. Input from all of these reps can be used to write the requirements as clear and unambiguous as possible.
The following are some ways that the requirements can be used to ask questions and provide guidance to downstream activities. These items below are SDLC model agnostic. E.g. they will work for both waterfall and scrum.
Leveraging the requirements for project management:
- Catch business requirements that are not adequately covered or not covered at all.
- Ensure that money is not being spent on items that have no assigned business value
- Ensure that money is not being spent on items that are out of scope for the release.
- When cutting scope, make the business-value priorities that were assigned to the requirements to make the best informed decisions to cut those requirements that have the least business value.
- What coding and testing is affected by a specific change in requirements?
Leveraging the requirements for design and implementation:
- Ensure the design covers all of the requirements
- Is the design effort focused on the highest priority requirements first?
- Ensure highest priority requirements being implemented first
- Are there tasks in the WBS that cover all of the functional requirements? What about non-functional requirements such as performance and usability?
- Which requirements are not yet covered by working code?
- Ensure that developers are working requirements and not on non-requirements.
- Provide frequent demos of product features in development, in priority order.
Leveraging the requirements for testing:
- Provide tracing (forward and backward) between requirements, test suites, test cases and test results
- Are the highest priority requirements being tested first?
- Which requirements are not yet tested?
- Are the features covering all “must have” requirements included in the release?
- Have all requirements been successfully tested?
These are some of the ways that the requirements can be used after the analysis phase. Don’t let the tyranny of the urgent slap you and your project team around. You put a lot of work into the requirements. Get busy and start using them to develop and release a successful product or service.
