Common Project Risks and Agile Mitigations, Part 4, Project & Risk Management

Part 3 addressed the topic of creating an initial plan (i.e., planning and estimation). This part will address related categories of issues that can lead to project failure: project and risk management.

Project Management Related Issues

To hearken back a bit to the last part, consider some thoughts from Tom DeMarco [May] in noting how a “Lean and Mean” emphasis in companies has “goaded” managers and staff into unreasonable estimates and the need for overtime work. “Any failure will be viewed as a direct result of underperformance,” DeMarco says. However, underperformance is “not even a significant [project failure] factor” for most projects compared to simply having initially unattainable goals.

Now consider some remarks from Ed Yourdon, quoted in [May] saying, “Nobody seems to acknowledge that disaster is approaching” even when they recognize it. “There is no early warning signal.” May goes on to state Yourdon’s belief that, “Until more organizations abandon waterfall-style development in favor of processes that demand early working code or prototypes…this scenario will continue to be familiar.”

The particular issues related to project and risk management mentioned in the various survey sources include:

• Failure to apply (or understand) essential project management techniques and/or project control systems (e.g., tracking, measurement).
• Inadequate visibility of progress (not just resources used) generally due to status reporting being misleading (e.g., generally more optimistic than pessimistic) or not having effective means of tracing a software development from requirements to completed code.
• Not proactively managing risk or basing actions on “catching up” later (e.g., counting on overtime to handle contingencies).
• Lack of knowledge of the actual probability of success, late failure warning signals, and reduction in resources needed for the project.

The first of the issues noted above argues for traditional project management capabilities being needed. Yet, though such capabilities might, on the surface, be present, the latter three problems could still occur because of the things DeMarco and Yourdon mention. Part 3 mentioned some ways to try to address DeMarco’s concerns. In this part, Yourdon’s concern should also be addressed.

Applicable Agile Values and Principles

Again, all the Agile Values and most of the Principles seem to apply in one way or the other.

The first problem noted above could just as easily be an issue in an Agile project if the techniques and principles for how to conduct one are either not applied or understood. The key in an Agile project is that these techniques are very near-term, direct and based on visible indicators of what is happening every day rather than at weekly/monthly status reporting occasions. This promotes the Agile Principle of simplicity, especially in process and tools, applied to project management by taking advantage of close, regular communication among project stakeholders and regular reflection on and adjustment to plans and project conduct. Because of all this, an Agile project will not engage in “Project Management Chicken” where everyone waits to see who will be the first to have to admit they are behind schedule.

Another important concept is how Agile projects measure progress based on working software rather than tasks accomplished. While it is true that an iteration burndown may track task, the ultimate measure of success will be completion of the committed to functionality and its acceptance by the customer. This is Agile’s “highest priority” and, as in planning, employs short timeframes (e.g., a few weeks) as the cycle for ensuring project direction meets customer expectations. And, as the demonstration of achievement of iteration goals is a very visible event, surprises are very unlikely if stakeholders maintain involvement with the team(s).

Finally, as noted in Part 3, planning is organized to make changes easier, less costly, and very visible. Agile project management, then, is focused on how to best respond to change and address risks right away. Indeed, a risk-based approach to managing projects is very much in keeping with Agile principles. However, rather than try to defend against change and risk, Agile projects take advantage of the near-term focus and visibility to accommodate change and surface risks early. (Jim Highsmith has some good advice related to what he calls a “Planning and Scanning” approach to managing projects, encouraging us to “expand our anticipation practices to include both planning (working with what we know), and scanning (looking ahead to learn the unknown as quickly as possible).”)

Regarding surfacing issues early, I have experienced managers responding to an Agile approach with the feeling, at least initially, that all they hear about day after day are the impediments the team is dealing with and the issues that need to be addressed. However, after a while, they see that these are issues that usually get dealt with immediately and which go on all the time, but are often not made visible in traditional projects. It is the visibility of the issues that initially produces the discomfort but, as time progresses, then produces greater confidence that teams are managing work well and ensuring stakeholders are kept informed. In this way, if large issues emerge, they are recognized earlier and addressed more promptly. This does not necessarily make them automatically easier to deal with, but does mean you’ll be dealing with them earlier, rather than later, increasing the likelihood of dealing with them at the least cost to the project.