Risk 1: Inherent Schedule Flaws: The Top Five Software Project Risks

Building and maintaining software can be a risky business.
Most enterprises rely on software

– so extra cost, delays, or the inability to realise goals can have serious consequences.
Larger risks that can sabotage long-term projects require immediate attention. And that
means putting the emphasis on risk management. Here, we'll elaborate the top ten risks
involved in software development.
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 and 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 utilising change-suppression mechanisms, prioritisation
sessions are scheduled that allow worthwhile changes to proceed and initially envisioned
features to be superseded if the business gives their authorisation. 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.
Not recorded
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 post provides a useful summary
of their top five 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:
RISK
Project Initiation
The initiation phase is a critical time for projects, and it is important to start out right
and set objectives. Knowledge areas playing an important role in success here are
scope management, in defining scope as well as setting ownership, and managing
time and cost, for high level estimates.
The planning phase is the road map for the project—and where requirements
definition and schedule development take place. It is essential to take the time to
plan properly, but we see some projects rushed through this phase in a misguided
attempt to save time. In fact, the project planning phase has the highest occurrence
of issues recorded for troubled projects. Critical knowledge areas for this phase
include scope (definition), time and cost (estimation and scheduling), and risk
(identification).
Unclear Business Problem and/or Success Criteria

We ask each project to answer the question: What problem are you trying to solve?
Often project team members do not offer consistent responses to this question or
they offer differing perceptions of what business problem is to be solved. The project
may be moving forward while solving the wrong problem. It is very easy to get
caught up in implementing a solution that is elegant, or interesting, or simple, or just
familiar, without stopping to ensure that it is appropriate for the true need, or even
that the true need is understood. Another gap in understanding the business need is
the lack of clear criteria to measure success. Projects experiencing this difficulty are
unable to articulate what constitutes success for the project
Multiple People as Project Manager (Or No Real

Project Manager At All)
When a committee attempts to function as the project manager, it is unlikely to
succeed. While in theory it may be possible for this arrangement to work, we have
witnessed many difficulties ranging from delays in responsiveness and decision-
making to a lack of unified issue resolution. More commonly, though, the role of
project manager is assigned without sufficient authority, which leads to an inability to
acquire true commitment for deliverables. Even a project with a well-documented
robust project management process may not actually allow the project manager to
execute the stated authority over the scope, budget, or end-to-end management of
priorities or resources on the project. The function then becomes primarily
administrative support handling facilitation, tracking, and coordination, leaving a void
in the management of the project. Occasionally, we find projects where the team
members are unable to identify or name the “one” in charge.
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 and 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.
Up-front or ballpark estimates are by definition less than completely accurate, but we
often see a significant amount of over-optimism on the effort required for the project.
Although further definition typically increases the scope and complexity for any
project, allowance for these unknowns may be inadequate or missing. Then,
because the change is seen as clarification rather than outright scope addition,
extending the date first estimated is not agreed to. As a result, once the full detail is
known and implemented, it is likely to be late and over budget.
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 utilising change-suppression mechanisms, prioritisation
sessions are scheduled that allow worthwhile changes to proceed and initially envisioned
features to be superseded if the business gives their authorisation. 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 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 utilise 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 recognise 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 time-boxed 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

Risk 1: Inherent Schedule Flaws: The Top Five Software Project Risks

Uploaded by

Copyright:

Available Formats

Risk 1: Inherent Schedule Flaws: The Top Five Software Project Risks

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Risk 1: Inherent Schedule Flaws: The Top Five Software Project Risks

Uploaded by

Copyright:

Available Formats

Building and maintaining software can be a risky business.

Most enterprises rely on software

Risk 1: Inherent Schedule Flaws

Risk 2: Requirements Inflation

THE TOP FIVE SOFTWARE PROJECT

Unclear Business Problem and/or Success Criteria

Multiple People as Project Manager (Or No Real

Risk 1: Inherent Schedule Flaws

Risk 2: Requirements Inflation

Risk 4: Specification Breakdown

Risk 5: Poor Productivity

You might also like