Devin Deen, project management trainer and certified Scrum master, explores ways to get RADical with your project, specifically to identify the right way to manage risks, assumptions and dependencies to ensure your project’s success.
Here’s a shot of the whiteboard for your reference!
Devin outlined how to get RADical with your projects. Specifically, he referred to the Risks, Assumptions and Dependencies on your project and how to manage them to keep your project on track. You don’t want any of those to turn into project issues. So first, Devin discussed risks:
- Invite the team and put them in a doomsday scenario frame-of-mind to sniff out potential risks. (Perhaps watch an episode of The Walking Dead to get them in the mood?)
- Identify what could go wrong, as well as the impact of each item.
- Define a mitigation strategy to LIM (lower the impact).
For a more detailed breakdown of risk management, check out Jennifer Bridges’ video here.
Devin next broke down what you need to do to address assumptions. Have you validated any and all assumptions you’re making about the project, particularly as defined in the Statement of Work (SOW)? Connect with end users, stakeholders, and your team. Verify that what has been scoped is actually the best action to take.
Finally, list all the dependencies you can find in your project. These are all the items that are out of your control, that are nevertheless essential to accomplishing core tasks and activities. What is needed in order to get the project completed? Your team can help define these too.
Pro Tip: Getting RADical is not a one-off. Integrate these steps as part of your regular team meetings and as part of your overall project management strategy. Also make sure you’re using the dependencies features in your project planning tool online, which will automatically adjust your plan when impacts to dependencies happen.
Thanks for watching!
Thank you for joining me. Today, we’re going to get RAD.
Now getting RAD sounds like it’s a real high energy thing. But actually, getting RAD is a little bit of black hat, lots of dark stormy clouds raining on people’s parade, and many, many half empty glasses. Getting RAD is something that you do at the start of every project during project planning, but also you should do it periodically throughout your project, weekly, sometimes even daily.
When I say get RAD, what I’m talking about is teasing out all the risks, assumptions, and dependencies that your project has to make sure that you can track and manage those items so that your project doesn’t get out of control. So those risk items, assumptions or dependencies don’t start bubbling up into becoming issues that you then need to manage.
Now, what do I do about getting risks identified? Now identifying risks, there’s really three things that you need to do when you tease out that risk from your project ream. Make sure they’re in a depressed doom and gloom type mode. You don’t want everyone cheerful when they’re thinking about the risks. You want them thinking about what could go wrong and why it could go wrong, how likely it is to go wrong, what the impact is if that item did happen and that item went wrong. And also, what is the mitigation strategy that you have to deal with that item to make sure that it doesn’t happen, or if it does happen, how to lower the impact of that item when it does become an issue. LIM is the acronym that I use. So make sure when you’re identifying your risks, you’re using LIM for that.
Assumptions. How often do I see a list of assumptions in a statement of work or a project charter that have not been validated? An invalidated assumption is a worthless assumption to have. When you list an assumption about your project, about your stakeholder, maybe your end-users, you need to make sure that that assumption is validated. Go ask the end-users about that particular item, and make sure that they validate what your assumption is on that item.
I’ll give you an example. Let’s say you’re going to use the color blue for some particular product that you’re going to develop. Maybe it’s a toy that you’re building. That color blue is the one that your project team thinks is important, and they assume that that’s the product, the color blue you’re going to use on that toy. But when you go talk to your end-users, maybe they’ve done a focused group on that color blue, and that color blue actually repels kids. Who knows? Make sure you validate that assumption. That’s the important part about it. If you don’t validate the assumption, it’s a worthless assumption to even list on your list, your RAD list.
Lastly, dependencies. These are key items that are outside of the control of you as a project manager, or your project team. They’re items that your project team must rely upon getting in order to actually do their work. When you’re doing Agile project management, we call that a “definition of ready”. That forms part of your definition of ready. What are the things that are necessary to have, the ingredients that you need to have on hand in order for you to do your project or cook your meal in that case? Make sure you list out all those dependencies and make your project team knows who to go talk to actually have that dependency met.
Once again, getting RAD is not a one-off event. It just doesn’t happen at the start of project, happens all the time, weekly, sometimes daily, in your project team.
I’m Devin Deen from ProjectManager.com. Get RAD early and often. For more project management tips and techniques and to try out our software, come join us at ProjectManager.com.