Floating Orange
Design. Write. Learn.

What I Learned This Week

Needs, Risks and Issues

I just sent this email to my team, and decided to share it with a broader audience to get your opinions:

 

Team,

Hope I'm not over-killing here, but I'd like us all to use a common language when referring to project "issues", etc. In my experience, this helps improve communication within the team and across different initiatives.

NEEDs: a.k.a., "to-dos", "open-items", "action-items" etc. These are specific actions we need to be taken by someone that will provide some piece of information that will allow the team to move forward on progress. It could be a need for access to a system. It could be a need for a marketing asset, or a business process answer. Whatever it is, it's absence impedes progress of the team, and eventually poses a RISK to the success of the project if the need remains unfulfilled. Every NEED should have a Description, a Reason, or Justification, for the NEED, a Due Date and an Owner. A NEED can have a Priority as well, but this adds complexity to managing your NEEDs. Yourcall on whether you want to include Priority.

RISKs: These represent dangers to the successful completion of the project (Business Risk Management, or BRM, would include positive risks, also called "Opportunities", but that is a different application of the concept). RISKs stem from unfulfilled NEEDs, and it's your call (based on schedule, dependencies, etc.) for when you are running out of time to get a NEED fulfilled. I am a big fan of prioritizing RISKs (unlike NEEDs), but typically stick to calling out the "BLOCKERs", which are the RISKs that will result in progress of some project activity being completely stopped. Avoid the temptation of calling everything a Blocker (like not getting an image for a webpage), as it tends to dilute the prioritization and ultimately, no one pays attention. When a RISK comes to fruition (your worst fears have been realized!), it becomes an ISSUE.

ISSUEs: These are now problems that may require a change in direction, scope, budget, or schedule. A Product Owner may now need to make a decision on whether to drop a feature, or move a release date, or pay more money to get something done. Typically, I like to let the Product Owner decide on the priority of an ISSUE, because it is her/his product that gets impacted.

IMO, a good NRI List is a PM's most important tool. Schedules will slip. Scope will creep. Budget will adjust. NRI's are how PMs keep a tight control on the Quality of what we are shipping. And from my perspective, although Schedule, Scope and Budget are all important, Quality is what we are ultimately judged on.