« Deciding When to Intervene on Projects
An Outsourced Model »

The Top Five Software Project Risks

August 2, 2007 | Author: PM Hut | Filed under: Agile Project Management, Risk Management, Scheduling

The Top Five Software Project Risks
By Mike Griffiths

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 article provides a useful summary of their top 5 software project risks.

While not an agile focused 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…

Risk 1: Inherent schedule flaws

Explanation: Software development, given the intangible nature and uniqueness of software, is inherently difficult to estimate and schedule.
Waltzing…Solution: Get the team more involved in planning & estimating. Get early feedback and address slips directly with stakeholders.
Agile Practice: On agile projects the team is heavily involved in planning and estimating through activities such as XP’s planning game and Wideband Delphi workshops. By working in short increments the true velocity of the team quickly emerges and is visible to all stakeholders who are now more closely involved in the project. In short, the true progress is hard to hide and quickly revealed, giving feedback to the stakeholders.

Risk 2: Requirements Inflation

Explanation: As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines.
Waltzing…Solution: Constant involvement of customers and developers.
Agile Practice: Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary. Changes and requirements inflation are accepted as a fact of software projects. Rather than utilizing change-suppression mechanisms, prioritization sessions are scheduled that allow worthwhile changes to proceed and initially envisioned features to be superseded if the business gives their authorization. It has never been possible to squeeze a pint into a quart cup, but now at least we anticipate the likely issue and have mechanisms in place to address the matter as part of the project from its early stages.

Risk 3: Employee Turnover

Explanation: Key personnel leave the project taking critical information with them that significantly delays or derails the project.
Waltzing…Solution: Increased collaboration and information sharing on the team.
Agile Practice: Agile projects practice information sharing techniques such as pair programming, common code ownership, and frequent reporting at daily stand-ups specifically to reduce the “bus-factor”. When this “bus factor” (the impact to the project of a key member being hit by a bus) is reduced multiple team members share key information and the risk due to employee turnover is small. Also, often overlooked, is the fact that when working in an engaging, rewarding, empowered, collaborative environment such as agile projects, people are far less likely to want to move elsewhere so the risk is often avoided as well as reduced.

Risk 4: Specification Breakdown

Explanation: When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements.
Waltzing…Solution: Use a dedicated Product Manager to make critical trade off decisions.
Agile Practice: Agile projects utilize the concept of an ambassador user, subject matter expert, or customer proxy to play the product manager role. The idea is that someone (or some group) need to be readily available to answer questions and make decisions on the project. Traditional projects suffer specification breakdown when no one will own the role and conflicting assumptions or decisions are made. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion.

Risk 5: Poor Productivity

Explanation: Given long project timelines, the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained.
Waltzing…Solution: Short iterations, right people on team, coaching and team development.
Agile Practice: Agile methods recognize Parkinson’s Law and the Student Syndrome apply to software projects. Parkinson’s Law says that: “Work expands to fill the time available” and
Student Syndrome: “Given a deadline, people tend to wait until the deadline is nearly here before starting work.” By having short iterations, work is timeboxed into a manageable iteration (typically 1- 4 weeks) and there is always a sense of urgency. Agile methods do not specifically address getting the right people on team, coaching and team development, but these are core leadership roles applicable to both agile and traditional projects.

On Agile Solutions

It should really be no surprise that agile methods have techniques built right into them to address each of the top software project risks. They were created out of the experience of what worked well for practical software development. Given that these problems occur time and time again on software projects it is natural that their solutions should become baked into the DNA of agile methods.

So, while risk management is a dry and dull subject to many, Waltzing with Bears brings the subject to life with valuable pointers for software project managers and is a recommended read.

Mike Griffiths is an independent consultant specializing in effective project management. Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum, FDD, XP, DSDM) for the last 13 years. He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN). He maintains a leadership and agile project management blog at http://www.LeadingAnswers.com

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Thursday, August 2nd, 2007 and is filed under Agile Project Management, Risk Management, Scheduling. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Some comments on item #3: Employee turnover

In my opinion, keeping the project information distributed throughout the team is the responsibility of the project manager or the management in general. Because, in my previous project, we had a contractor working on a key project for quite a long time. We have asked for some additional resources(people) for backup but of no avail. One point in time, he really had to leave the company because of long contract durations. He ended up documenting what he knows well in paper. The person who took over still had to go over a lot of things to really catch-up but the documentation really helped.

On the other front, in another project, we had a strategy where the developer has to prepare a design document describing briefly the following and reviewed by a subject matter expert before he starts development:

1. What is the problem reported?
2. What is the suggested solution approach?
3. What are all the things that need to be modified?

This document really helped any new team member who comes on board.

Magesh Puvananthiran wrote on August 27, 2007 - 2:00 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories