The Top Five software Project risks

Risk management (or more precisely Risk avoidance) was a critical topic, but one that was often dull to read about and there Fore neglected. One of the few useful and entertaining books on the subject are "waltzing with bears:managing Risk on software Project S"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 a agile focussed book, I-find it interesting that's the top five software project risks identified in waltzing With bears, all has 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 Sche Dule.

waltzing ... Solution: Get The team more involved in planning and estimating. Get early feedback and address slips directly with stakeholders.

Agile Practice: On agile Projects The team are heavily involved in planning and estimating through activities such as XP ' s planning game an D wideband Delphi Workshops. By working in short increments the true velocity of the team quickly emerges and was visible to all stakeholders W more closely involved in the project. In short, the true progress are hard-to-hide and quickly revealed, giving feedback to the stakeholders.

Risk 2:requirements inflation

Explanation: As the project progresses more and more features this were not identified at the beginning of the project emerge that thre Aten estimates and timelines.

waltzing ... Solution: Constant involvement of customers and developers.

Agile Practice: Agile projects plan in the regular trade-off discussions on features and estimates at every iteration boundary. Changes and requirements inflation are accepted as a fact of software projects. Rather than utilising change-suppression mechanisms, prioritisation sessions is scheduled that allow worthwhile changes T o Proceed and initially envisioned features to is superseded if the business gives their authorisation. It has never been possible to squeeze a pint into a quart cups, but now at least we anticipate the likely issue and other have me Chanisms 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 Repor Ting at daily Stand-ups specifically to reduce the "bus-factor". When this "bus factor" (the impact to the project of a key member being hits by a bus) are reduced multiple team members Sha Re key information and the risk due to employee turnover are small. Also, often overlooked, is the fact of the when working in an engaging, rewarding, empowered, collaborative environment such As agile projects, people was far less likely to want to move elsewhere so the risk was often avoided as well as reduced.

Risk 4:specification Breakdown

Explanation: When coding and integration begin it becomes apparent then the specification is incomplete or contains conflicting require ments.

waltzing ... Solution: Use a dedicated Product Manager to make critical trade off decisions.

Agile Practice: Agile projects utilise the concept of an ambassador user, subject matter expert, or customer proxy to play the product man Ager role. The idea was that someone (or some group) need to being readily available to answer questions and make decisions on the PROJEC T. Traditional projects suffer specification breakdown when no one would own the role and conflicting assumptions or decisi ONS is made. Agile projects has some form of product owner role central to their core team composition to ensure decisions is made in A timely fashion.

Risk 5:poor Productivity

Explanation: Given Long project timelines, the sense of urgency to work in earnest are often absent resulting to time lost in early Proj ECT stages that can never is regained.

waltzing ... Solution: Short iterations, right people on team, coaching and team development.

Agile Practice: Agile methods recognise Parkinson ' s law and the Student syndrome apply to software projects. Parkinson's law says this: "Work expands to fill the time available" and Student syndrome: "Given a deadline, people t End to wait until the deadline are nearly here before starting work." By had short iterations, work was timeboxed into a manageable iteration (typically 1-4 weeks) and there are always a Sens E of urgency. Agile methods don't specifically address getting the right people on team, coaching and team development, but these is C Ore leadership roles applicable to both agile and traditional projects.

On Agile Solutions

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

So, while risk management are a dry and dull subject to many, waltzing with Bearsbrings the subject to life with V aluable pointers for software project managers and is a recommended read.

The Top Five software Project risks