Discover

In the first phase, a project team is discovering all they can about the problem space, and about potential elements of a solution. Questions are mostly open-ended, and you are working to get the general lay of the land.

The Discover act primarily requires boundless curiosity – much the same thing a puppy exhibits when they are let off their leash in a new space. You need to run around in all directions at once, discovering and testing boundaries, sniffing anything that might be interesting.

At the beginning of this act, you won’t yet know enough to even formulate such a list, but should have the goal of being able to start such a list. By the end of this act, you should have a fairly comprehensive and specific list of open questions that need answers.

Requirements

• Stakeholder Identification
• Requirements Elicitation
• Requirements Documentation
• Requirements Analysis and Prioritization
• Verification and Validation
• Requirements Management and Change Control

Content Audit

A design team ensures that they produce, edit and archive content at the right time and for the right audience. Such deliverables include marketing communication. While designers may not be directly responsible for content strategy, they should ideally work closely with personnel who are. 

Risks & Mitigation

BAs struggle with the time it takes to conduct the analysis and assessment. This is often because the requirements risk assessment is left until right before we are ready to obtain approval of requirements and are treated like an afterthought or something that provides no value other than to tick a box on the project documentation checklist to pass audit. It is much more time consuming and less valuable to do this than to build it into the elicitation process. It is known that most BAs are already having these discussions with their stakeholders as they are eliciting requirements, so why not tackle them at the same time rather than have to discuss them again later? Formalizing the process will put more structure around the discussions to decrease the chances of missed requirements.

When identifying requirements risk, the BA is looking for potential exposures or areas where there could be exceptions to the process, or failure points. The same way testers look to break the system or product, BAs are looking to break the requirements and identify fixes for them before it happens in the real world. Examples include:

• Have all paths through a process been identified?
• Have error conditions been identified?
• Do we know who updated a transaction and when?
• Can we easily correct incorrect transactions?
• Is there a potential for unauthorized users to access the application?

Document Analysis

A requirements risk assessment from a comparable project can be used to identify potential exposures. Reviewing past lessons learned can also be a valuable source of potential requirements and project risks. If it was a problem before, then it could be a potential problem this time.

Interface Analysis

If there are multiple handoffs between teams or systems, each handoff is a potential exposure. If the process is handed off to a third party vendor, what happens if the communication link is hacked? Is there a potential for something to be missed between the handoffs from one team to another?

Interviews/Workshops

Although the BA is accountable to ensure the requirements risk management process is being completed, it is not their sole responsibility to identify all the potential exposures in the product or solution. Similarly, although it is the PM’s accountability to ensure a project risk assessment is being conducted; it is not the PM’s sole responsibility to identify all the project risks in a project. As BAs are interviewing or conducting requirements workshops with stakeholders, BAs should be identifying possible failure points and documenting these exposures in a requirements risk log to walk through the process of ensuring they will be addressed either through the project or through a business workaround, should it happen in the production environment.

Analysis Review

Ideally, your review should include one person from every area of the business impacted by the requirements, good examples include marketing, operations, product management, customer service, and IT.  Often times you’ll need more than one person from a group because of the decision makers within that group.

When you sit down to review a requirements specification in a meeting, you know that people are actually reading it. You also will find that one comment leads to another and that can help discover new requirements before it’s too late. Besides, a review meeting cultivates a certain accountability – if you ask your stakeholders to look you in the eye and confirm they are ready to take the next step with the project.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.