“Do The Right Thing” – PMI® Requirements Management Webinar Recap
Last month I presented a webinar to the PMI® (Project Management Institute) Requirements Management Community of Practice: “Do the Right Thing: Adapting Requirements Practices for Agile and Traditional Projects.”
The Requirements Management CoP has grown exponentially and will continue to do so, especially since the PMI recently announced the new Professional in Business Analysis certification (PMI-PBA). This growth was reflected in the full webinar room during the live event. During the webinar, I shared requirements discovery and delivery principles and practices along a gradient from traditional to agile.
As you review the deck, there are some key points to know:
- A purple checkmark on a slide indicates that a practice applies regardless of where your project stands along the gradient from traditional to agile.
- I used A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition to provide a framework for PMI members to consider as they adapt their requirements practices.
- Context counts. Every project and product is different. It’s essential to customer, business, and technology stakeholders to establish that context among all product partners.
- CRACK (slide 40) stands for collaborative, representative, authoritative, committed, knowledgeable. It is an acronym from Barry Boehm and Richard Turner’s Balancing Agility and Discipline.
- Please. Let’s talk about requirements discovery (a.k.a. elicitation, analysis) in a manner that conveys the creative and collaborative work that is. By the same token, let’s stop calling it what it isn’t: We don’t collect or gather requirements!
I wrapped up the webinar by challenging those more on the traditional end of the gradient to adapt goals and practices from agile. Likewise, I challenged agilists to draw from some of the wisdom of traditional requirements engineering, as appropriate. The table below describes just a few examples.
|
PMBOK Guide Knowledge Area (KA) |
Questions for those using |
Questions for those using |
||
| Integration Management |
How can you lighten up your project chartering? What are ways you can monitor progress towards delivering value on an ongoing basis? How can you engage product partners in scoping and envisioning? |
Do you have a product charter? Does everyone on your project have a shared vision of that product? Do you have a team charter that clarifies working agreements and how you will continually improve? | ||
| Scope Management |
As agile methods are one of the best ways to manage scope creep, how can you inject ongoing validation of product delivery? What are ways you can recognize healthy scope creep? (for some ideas, see “Rope Your Scope: Reining in Scope Creep: Parts 1 and 2.”) |
Do you understand the scope for the Big–View of the product? What quantifiable metrics are you using to test that you are building the right product (a.k.a. validation)? | ||
| Stakeholder Management | How can you use acceptance criteria to obtain a more specific and shared understanding of stakeholder needs and expectations? Can you use rituals and practices from agile discovery and delivery to elicit feedback from customer and business stakeholders sooner or on an ongoing basis? | Do you know who your product partners are (customer, business, technology) for all planning horizons–not just the Now–View? |
You can review the deck here:
As you check out the slide deck, ponder these questions: What are some ways you’ve adapted your requirements practices? What are some ways you wish you could? Feel free to leave your answers below so we can keep this conversation going.
Leave a Reply