In the previous post of this series, I talked about performing stakeholder analysis and identifying who needs to be involved and when. And for those key stakeholders, the ones you’re going to be working with during most of the requirements, you’ll want to set the foundation right from the Project Kick Off.
The Project Manager generally facilitates the project kick off, but on smaller efforts you may be wearing this hat. Regardless, don’t miss the opportunity to address items more specific to the requirements phase of the project, in addition to the standard areas that need to be covered. Work with your project manager to incorporate these items.
They main thing is to make sure that all of your key stakeholders are in the kick off meeting.
If not, you could end up bogged down in re-work and your stakeholders still not understanding the importance of each step of the process. Remember, communication is the key to keeping your stakeholders engaged. And if they’re not there, they are not getting your message.
There are 4 items I suggest you consider working with your project manager to add the Project Kick Off Agenda:
- Assumptions and Guiding Principles
- Approach and Process
- Next Steps
Assumptions and Guiding Principles
Particularly when you are working with a group of people, decide up front how the group will make decisions. How will differences be settled? If you get stuck at a decision point, what will the group base their decisions on? What should the group be held accountable to? These are what I call the Assumptions and Guiding Principles. I break these down into 4 categories:
Identify the primary business goals or factors that should help in determining and prioritizing scope. For example, if a business driver is to increase efficiencies in turn around time, and you get stuck on a question around a business process, you might encourage the choice that is the most time efficient. But you might not spend time on requirements that do not further this goal.
Identify those items that everyone needs to understand and can take for granted. For example, on one of my projects we had the following assumption: “Individuals will still be managed and held accountable to their responsibilities even when certain aspects of their job are automated.” This allowed us to get through stumbling blocks when there was a question over enforcing strict business rules in the system versus allowing greater flexibility.
Another great example, “We will focus on areas of improvement that would be difficult to live with for the long term. Items we could “live with for 3 years” will not be in scope.” This allowed us to focus on the most important needs first.
Identify any system-related items that you want to set as assumed information. For example, define areas of functionality that are handled by other systems and therefore not in scope of your current effort. Or maybe there is a current limitation in another system that will be addressed concurrently by another project. Add an assumption that those system modifications will be in place for your effort, so you don’t lose time with past or current problems that will no longer be an issue.
What is it ultimately that your stakeholders want? This is bigger than scope. This is that ultimate motivator for even embarking on this project or series of projects. Is it to provide seamless, fully-integrated, end-to-end processes using an automated system? Or “have all necessary data “served-up” to users”? (Yep, those were guiding principles for a project going from a paper-based to an integrated system solution.) What is the bigger picture reason for this project?
You may not be able to get the information you need with the limited time in the Project Kick Off. That meeting is just the starting point. You may need to schedule additional meetings to complete this work, or add it to the beginning of your requirements sessions.
While these sound elaborate or time-consuming, don’t forget that the amount of time and attention you give to these activities should scale with the size of the overall project. If you’re about to embark on a 12-24 month project, these activities could take hours. But if you’re working on a project that will be complete in a few weeks, you could get this information by soliciting it via email, or at the beginning of your first requirements session. Don’t feel like your only choice is for this to be elaborate or nothing. Find the right balance so this adds the benefit you need for the appropriate amount of effort.
TIP: I write these on large poster size pieces of paper and bring them to every requirements meeting. Keep the Assumptions and Guiding Principles front and center so they are the most useful.
Approach and Process
Explain the high-level process overview. Remember your stakeholders may have never been through this process before, and even if they have they may need to be reminded. Don’t assume they know what you’re going to expect of them, and what they can expect from you.
Explain what techniques you’re going to use to:
- Understand and finalize scope
- Elicit high-level requirements
- Perform Solution Analysis
- Work through Detailed Specifications
I’ll cover these items in a little more detail in an upcoming post (and forthcoming ebook) about Requirements Planning. But the main idea here is to communicate what they can expect. The more they know in advance, the better prepared they can be mentally to be fully engaged in the process.
You’ve likely covered quite a bit of information in a very short timeframe. So end by telling your stakeholders the one next thing that is coming. This may feel like a little bit of hand-holding, but don’t underestimate the power of making everything really obvious.
Be sure to ask for questions. Don’t ask “Are there any questions?” Better yet ask “What questions do you have?” Assume there are questions. Don’t assume they understood everything you explained. This starts the open communication that you’ll need for your stakeholders to feel heard and engaged in the process.
Now It’s Your Turn
What questions do you have? Are you actively involved in the project kick off, setting the stage for requirements? What do you do to set the stage and engage your stakeholders from the very beginning? Do you think this information adds value? Or does it just add unnecessary time to getting going?