I recently posted an entry on a risk assessment tool you can download and use. Risk management (or more precisely risk avoidance) is a critical topic, but one that is often dull to read about and therefore neglected. One of the few useful and entertaining books on the subject is “Waltzing with Bears: Managing Risk on Software Projects” by Tom Demarco, Timothy Lister, authors of the ever popular “Peopleware”. This post provides a useful summary of their top 5 software project risks.

While not an agile focussed book, I find it interesting that of the top five software project risks identified in Waltzing with Bears, all have suggested solutions rooted in agile methods. Demarco and Lister rate the top five risks and their mitigation strategies as...

In my last post I suggested spending less time worrying about project metrics and more time on stakeholder concerns, so I thought a tool to simplify project tracking might be useful.

Having completed project estimating with the team, it is often necessary to convert effort estimates into cost estimates based on likely utilizations and then track actual hours billed against these projections. Today’s download is a simple burn-rate estimation tool that produces S-Curve graphs and let you track actual spend against burn-rate projections and planned budgets.

You can download the spreadsheet here:

Download estimation_and_budget_tracking.xls

Control vs Communication

When you first learn to ride a bike it is normal to grip the handlebars really tightly and look at your hands or feet as you concentrate hard on the new “riding” task and try not to fall off. The problem with looking at your hands or feet while cycling is that you will not see the rock or pothole in the road ahead until it is too late and so, despite your best efforts, you will fall off. It is actually safer to relax, loosen your grip on the handlebars a little, and look further up the road to spot obstacles in plenty of time to avoid them.

The same goes for project management, when we are new to the role it is normal to focus on the project plans, progress against the plan, and budget consumed too closely. We focus so much on these project management tasks that we fail to see the issues and risks (rocks and potholes) the project is headed towards, until it is too late. While plans, progress and budgets are all critical elements, we can bring more value to the project by releasing our obsession on these project metrics slightly and focussing more of our attention down the road to items like sponsor satisfaction and team morale. There is little point having a perfectly executed project plan and a full set of EVA metrics if the project gets cancelled or half the team quits.

Specification vs Collaboration
Closely linked to Control and Communication is Specification and Collaboration. We can try to specify everything down to the nth degree of detail and then hope we got the spec right and whoever is developing the product develops exactly to specification. Or, we can explain our goals at a high level and then work in closer collaboration with the developer to achieve our desired results.  Agile methods recommend the second option, getting the customer working in closer collaboration with the developer to ensure the right product gets built. This works well for many types of software project where it is difficult to fully articulate the complete requirements upfront. However, it is not just the software world that is switching to collaboration over specification.

Today’s aircraft are highly complex networks of sub-systems, parts and software; and Boeing’s new 787 Dreamliner is about as big and complex as commercial aircraft currently get. From its ground breaking remote diagnostics that communicate component usage, wear and failure statistics to the ground in real time via satellite communications; to its novel composite material wings that save weight, the aircraft is new and extremely complex.

When Boeing sent the specifications to the electronics supplier for the 777 (the predecessor to the 787) the document was over 2500 pages. The equivalent specification document for the 787 is a mere 20 pages, how is this possible? Boeing, who are experts in specification and control, learned that to tackle a project of this magnitude they had to form closer relations with their suppliers and learn how to co-create and collaborate like never before. While it would be wrong to say: “Gone are all the detailed specs” the major shift is to increased collaboration with suppliers and less reliance upon specification.

Many industries are tapping into the benefits of increased collaboration over contract negotiation that are also embraced by agile methods. With increased collaboration comes shared decision making as well. In the past, Boeing gave the orders like a drill sergeant, and suppliers complied. Rarely did it matter if the supplier had a better idea – Boeing wanted components built exactly to specification. This time, Boeing has given all of its partners a vote on matters that affect them. Boeing and its partners are reaping the benefits as they work together on solutions and adapt to realize unanticipated benefits.

So, if you get a chance to fly on a new 787 Dreamliner any time soon, consider the new collaboration process that enabled its creation (and let’s hope they did not lose any of those story cards!)

You can read more about emerging trends in collaboration and Boeing’s new work practices in Wikinomics: How Mass Collaboration Changes Everything. By Don Tapscott and Anthony Williams.

My recent posts on “Introducing Agile methods to Organizations: Mistakes to Avoid” (part 1, part 2, part 3) have been picked up by InfoQ for a mini-book. While this is great positive feedback for me, it is good news for you as readers too, as I will also post links to the new expanded version here so you can get access to the extra material.

Mini-books are available free electronically and sold in paper form through Amazon. They are short (60-80 pages maximum) and intended to serve a tech savvy audience with a concise, yet in-depth coverage of a subject.

I plan to work on this in May and June and will keep you posted as to how it goes and when the final version is available.

This post introduces a useful risk assessment tool you can download and use on your projects. While I created the spreadsheet formatting and presentation, the risk categories, questions and scores come from IEEE analysis of actual software project risks, so they have a reputable source.

The Risk Assessment Challenge
A problem with risk assessments is that risks are often relative to the observer. What might seem like an acceptable risk to you might be unacceptable to me. For many organizations it is difficult to get an objective view of their project risks across a portfolio of projects because different project managers have different risk thresholds. What a “Gung-ho” project manager rates as a “Medium Risk” project might actually be “Very High Risk” project to the majority of other project managers. Even more problematic, is when project risk assessments miss major categories of risks and are rated much lower risk than they should be. The risk profile tool I will introduce is a mechanism to help bring consistent risk assessments across an organization and ensure no major risk areas are omitted.