In my last post I gave an overview of risk and a risk management approach. In this post, I’ll discuss five common risks from a requirements perspective.
Perhaps one of the largest risks that we consistently see on projects is around business objectives – either not developing them or a lack of consensus among stakeholders. This should be at the top of your list of areas to examine for risk. This is an area that is sometimes difficult to develop risk responses for – if stakeholders don’t believe they need to develop or agree upon business objectives, how do you convince them? Education can help, but (unfortunately) so can experience.
A second category to check is scope creep. This is closely aligned with business objectives, since making sure you align your requirements with business objectives is the preferred method to ensure that you don’t get gold-plating in your requirements.
Another area to look out for schedule risks. How realistic is the schedule? Does it allow sufficient time for analysis and synthesis of the requirements you gather? Is there time to ensure proper requirements validation? What are the potential impacts to quality and project success if not?
Another category is particularly common for the requirements team – organizational risks. There could be several areas to check – resource availability, political, funding, and prioritization of projects. Resource availability is perhaps the biggest problem Product Managers run into, since unlike the Design team (for example), we cannot do our jobs by ourselves.
The last category of risks to consider is quality. Since we all know that getting requirements right is a critical success factor for project success, ensuring the quality of the requirements is key. What pro-active steps will you take to guarantee the quality of your deliverables?
Hopefully these ideas will serve as a start for you to begin thinking more about risks. Please feel free to comment on the message board about additional ideas you have.
