We all know about he negative ones (a.k.a. Threats). They’re the ones that threaten to rain on our otherwise sunny parade: A critical project resource falls ill; the new version of a vendor’s module isn’t as compatible as advertised; a firewall refuses to let traffic through during a major infrastructure implementation.

Most of us are also aware of the standard responses to negative risks: Avoid (schedule critical work outside flu season); transfer (engage the vendor’s professional services team to integrate its module); mitigate (run a mock implementation to find surprises ahead of time and reduce the likelihood of the risk occurring); and/or accept (develop a contingency plan and brace for impact).

It’s the positive risks (opportunities), though, we tend to forget about — which is like playing Snakes and Ladders (is it still called that?) without the ladders.

What if in-scope work finishes early? This could translate to a big advantage on a fixed-price engagement with an incentive fee for finishing earlier. What if there’s a possibility of reducing development, integration and on-going maintenance costs by simplifying the design? What if we could create a buffer in the infrastructure implementation schedule as contingency in case implementation doesn’t go as planned?

By investing time up front with the team to plan for positive risks, we can be prepared when opportunity knocks.

You could exploit an opportunity by making sure it happens (use senior resources to complete work earlier without sacrificing quality); enhance it by increasing the chances of it occurring and/or the resulting positive impact (just how much can we simplify the design through peer reviews and refactoring?); and/or share the opportunity with someone so both benefit (share an earlier implementation window with another project in exchange for sharing a key resource from our project). Of course, as with negative risks, we can simply accept the fact that Lady Luck may pass our way, and be prepared if she does by keeping scope/schedule/cost flexible.

The risk planning approaches above can be applied to everyday life: Picking up relatives at the airport? Building a deck? Planning a birthday party? What could go wrong? What could go right?

I applied these techniques when planning a motorcycle ride from Toronto to Alaska and back last summer: I planned for the very real possibility of running out of gas on The Alaska Highway with a combination of avoidance (topping off the fuel tank whenever possible), transferring the risk (CAA, where feasible) and mitigating by carrying extra fuel. On the positive side, I left my schedule loose enough to accept opportunities that might come up — such as a much-needed, off-road riding course during a stopover in Calgary.

If we are focusing on just the negative risks, we are only addressing one side of risk planning. Sure, there are snakes ahead; but let’s be prepared for the ladders as well.

Created by Robert Grady, FURPS is an acronym for:

Functionality:   This is the one most of us jot down when defining requirements. It answers the question, “What do I want the end product to do?” In addition to considering product features and capabilities, remember to think about what level of security is required.

Usability:         Who will use the product? How will they use it? What look-and-feel do you want? What about help screens and self-help “wizards”? One often overlooked area is that of user documentation and training–often sub-projects unto themselves!

Reliability:        What is your expectation in terms of system up-time? What do you consider an “acceptable” system failure? How quickly should the system be able to recover from a failure? What should the mean time between failures (MTBF) be?

Performance:   Consider the functional requirements you have defined. What level of performance are you expecting? Think about speed, efficiency, availability, accuracy, response time, recovery time, and resource usage.

Supportability:             How easy should it be to test the system; and how would this be done? What about maintenance–what’s your expectation in terms of system care and feeding? How configurable should the system be? What about installation–who should be able to install it?

Grady’s FURPS definition actually includes a “+” (FURPS+) lest we forget to consider:

+ Design Constraints: Anything the design team should be aware of in terms of how you would like the system designed?

+ Implementation Requirements: For example, do you expect the implementation team to adhere to a standard?

+ Interface Requirements: Any legacy or other external systems the product should interact with? How / When should this interaction occur?

+ Physical Requirements: Material? Shape? Size? Weight? (This one’s more geared toward hardware requirements)

I’ve just scratched the surface in this post–each of these areas easily warrants a dedicated article to elaborate on details. For a far more detailed explanation than I could ever provide here, check out Robert Grady’s book, Practical Software Metrics for Project Management and Process Improvement, (Prentice Hall).

Take communications management, for example. Maintaining control over project communications is critical on any project—get it right and you’ll succeed; get it wrong and things will fall apart pretty quickly. Technology can help; but any communications management system still requires constant maintenance to be effective. Especially email. As we all know, email requires regular house keeping–a task that is… well, it’s mundane.

While I don’t have the solution to the world’s email challenges, here’s a gem I find helpful:

For many of us, Microsoft Outlook is pretty-much a staple for gaining control over communication. However, while many use Outlook’s email functionality as a mechanism to receive-open-read-reply/forward-file email, its powerful email organization capabilities are often unknown or forgotten.

Enter Outlook’s “categories” feature. Categories are colour-coded tags you can assign to significant emails to keep them visible and help with searching. You can assign categories to email by right-clicking on the “Categories” heading at the top of most mail folders: Select an email; choose a category; and your done.

Outlook comes with default descriptions for each category (Red is “red”; Yellow is “yellow”); and you can re-label the category to whatever works for you. Here’s a list of the categories I have set:

• Orange – “Change”
• Light Green – “Decision”
• Purple – “Issue”
• Light Blue – “Reference”
• Yellow – “Risk”
• Red – “SOS”
• Green – “Status”

For more information on how to configure colour categories in Outlook, check out this Office Online article.