In Part 4 of this series, I outlined the Requirements Kick Off meeting which is different from the Project Kick Off. As part of the Requirements Kick Off I suggested that you explain the techniques you’ll be using and the timeline and resources that you need, which can easily be communicated by preparing and reviewing your Requirements Work Plan (or Requirements Management Plan).
Obviously, this is prepared in advance of the kick off meetings, and is an effective tool in helping you to not only plan your requirements work, but to provide an estimate to your project manager as to how long you need to complete your activities. Without thinking through the plan, your estimate is as good as a guess.
Preparing the Requirements Work Plan gives you a chance to take a step back, analyze the scope of work, and determine the best techniques and approach to facilitating the requirements work.
Even for a small effort, take the time to think through these steps and actually make a plan. Whether you choose to formalize a document is up to you, but in my experience it is a very effective way to communicate and formalize the approach for the entire project team.
Here is the table of contents from one of my documents:
Note: This was for a rather significant project effort and is therefore 13 pages. However, I was able to easily modify this document into a 3 page format for a smaller effort I’m currently working on without losing any beneficial details.
Let me start by saying that the information in this document is specific to the requirements work to be completed. While many of these items (for example Assumptions and Constraints) are also part of an overall project plan or methodology, this should be the subset of information that impacts requirements. Work with your project manager to ensure that the overall project information contains the relevant information from your document as well.
Let me briefly review what goes in each section of the document:
This is intended to capture the purpose of the Requirement Work Plan document itself, not the purpose of the project. For me, the purpose of this document is to provide a plan that outlines the activities, processes, timing and resources needed to complete the requirements work. I call out that this is a working document that will be updated as needed throughout the process.
Provide a little bit of background on the project to orient and remind team members as to the goal of the effort. This is also a great place to recap the Guiding Principles you identified as part of the Project Kick Off activities.
Document the items that are in scope for the current effort. Include a prioritized list here if you have it. This is your chance to be very clear about what will be included. It is best to find out now if your stakeholders have the expectation of additional items, rather than later down the road.
Out of Scope
If there are major areas of functionality that you can clearly define as out of scope, document them here. Particularly if there has been discussion around a specific area of functionality and a decision was made to exclude it, reiterate that decision here. I also usually add a statement indicating that anything that is not specifically identified as in-scope is considered out of scope. Again, set the expectations now to minimize any unmet expectations later on.
These are not the assumptions for the project, but rather are any assumptions that need to be clarified for the requirements effort. For example, “Requirements activities will only be conducted for the items identified in the prioritized in-scope list.” I know, you’re thinking this is overkill at this point. But as I’ve stated before, I’d rather err on the side of over-communicating, and the purpose of this document is to communicate the expectations for the requirements effort.
Identify any dependencies that will impact the requirements effort. For example, are there any other stakeholders that need to be consulted or approve the requirements other than the project team members? You can even use your RACI matrix as a prompt to help you.
Document anything that may impact your ability to successfully complete the requirements activities as defined. Are your primary stakeholders also working on other projects and therefore may not be readily available? I also document any scheduled time away from the office for vacations or conferences for all of the key stakeholders.
This is where you document the actual process and techniques you will use to complete the requirements work. Explain what will happen with each step so your stakeholders know what to expect. For example, in the Business Requirements Session(s), will you be using a group facilitation technique? One-on-one interviews? Provide a brief description of each technique so participants will know what to expect. Remember, they may have never done this before.
Clearly define what the deliverables or outcomes will be of each step in the process. Will a document be produced? Will approval be required?
For each step in the process, identify what resources will be needed and when. Include both required and optional participants and the expected effort. While you may not yet know the exact dates, you can draft this information and complete it as you know more. I like to use a table format when it makes sense, as it’s easy to display a lot of information quickly. Here is an example of what it might look like.
You may have also noticed in my table of contents that in this particular case I broke up the effort across four iterations. This was described in my process and approach and the specific items to be covered in each iteration were detailed in section 4.3 of the document. This shows how you can leverage this type of document regardless of the methodology you choose, as the purpose again is to describe the approach that you will be using.
I include this section sort of like an appendix. It reiterates what requirements are and acts as a reference for your stakeholders to remember what level of detail you are trying to achieve at this point in time. Include any additional information that you think would be helpful to your team. Think about the person who may not have been part of a project team before and possibly even missed the project kick off meeting. What would help them stay oriented during requirements activities?
What other information might you include in your Requirements Work Plan? What’s missing from this outline? In the next post in this series, I identify one major area that should probably be included. Any guesses?