What Are Your Chances of Project Success? [From the Archives - First Published in 2003]

ScottGraffius_Com - From the Archives - Chances of Project Success - 2003 - LwRes



black_spacer_lr_sq_v3

This article was first published on 12 July 2003.

black_spacer_lr_sq_v3

The Standish Group provides research reports valued by those in technology management. In their
Chaos Report and the follow-up Compass Report, Standish reported the top 10 criteria for project success.

This unique self-assessment is based on Scott M. Graffius' professional experience and Standish's findings. You're invited to take it to identify your project's success potential.

Note: This tool is tailored for projects utilizing a waterfall or hybrid approach and is not applicable to agile projects.

User Involvement

  • Are the right users involved?
  • Additionally, are the right users involved early and often?
  • Are there good relationships with the users?
  • Is involvement easy (frictionless)?
  • Are the users’ needs uncovered?

___ total items with a “Yes” x 3.8 = ___.

Executive Management Support

  • Is the right key executive(s) involved?
  • Does the key executive(s) have a stake in the outcome?
  • Does the project team have a stake as well?
  • Is there a well-defined project plan?
  • Is it understood that failure is a possibility?

___ total items with a “Yes” x 3.2 = ___.

Clear Statement of Requirements

  • Is there a concise vision?
  • Is there a business case?
  • Is there a functional analysis?
  • Is there a risk assessment?
  • Have metrics been identified for tracking and reporting?

___ total items with a “Yes” x 3.0 = ___.

Proper Planning

  • Is there a problem/pain/opportunity statement?
  • Is there a solution statement?
  • Have the right team members been assigned to the project?
  • Is there a firm specification/requirements?
  • Are there attainable milestones?

___ total items with a “Yes” x 2.2 = ___.

Realistic Expectations

  • Are the specifications/requirements clear?
  • Prioritization of needs? (While the default plan is to fulfill all requirements, the importance/value of each one should be quantified or qualified so that the most important items are prioritized.)
  • Are there small/manageable milestones?
  • Is change manageable (through a change management process or otherwise)?
  • Can the project be prototyped or delivered in phases or incrementally?

___ total items with a “Yes” x 2.0 = ___.

Small Milestones

  • Is the 80/20 rule observed (focus on the 20% of features that result in 80% of the benefit)?
  • Is top-down design used?
  • Are time limits set?
  • Is a prototype tool used?
  • Can progress be objectively measured?

___ total items with a “Yes” x 1.8 = ___.

Competent Staff

  • Has a gap analysis on skills been done (and needed skills identified, if applicable)?
  • Are the right people on the team?
  • Is there a training program or otherwise an opportunity for team members to level up their skills?
  • Are there appropriate incentives?
  • Is the team appropriately skilled/equipped/available to see the project to completion?

___ total items with a “Yes” x 1.6 = ___.

Project Ownership

  • Are roles for team members defined?
  • Are roles for those involved with the project but not a member of the team (such as sponsors or executives) also defined?
  • Does everyone have a good understanding of they will collaborate and contribute on the project?
  • Are incentives tied to success?
  • Is everyone involved committed?

___ total items with a “Yes” x 1.2 = ___.

Clear Vision and Objectives

  • Is the vision shared?
  • Is the vision aligned with the organization’s goals?
  • Are objectives achievable?
  • Are objectives measurable?
  • Are sanity checks/gates in place?

___ total items with a “Yes” x 0.6 = ___.

Focused Staff

  • Are there incentives?
  • Is there a focus on the deliverables?
  • Does each team member have part ownership?
  • Is everyone working together?
  • Is confidence being built as the team progresses?

___ total items with a “Yes” x 0.6 = ___.

Add all of the points to obtain the final score. Total score is ____ out of a maximum of 100 points.

Results range from 100 to 0, with 100 being the ideal for the project's success potential.

It is suggested that projects with a score less than 90 are revisited, and that challenges or impediments are resolved.

black_spacer_lr_sq_v3

How to Cite This Article

Graffius, Scott M. (2016, January 2). What Are Your Chances of Project Success? [From the Archives - First Published on 12 December 2012]. Available at:
https://scottgraffius.com/blog/files/archive---chances-of-project-success.html.
black_spacer_lr_sq_v3

© Copyright 2016 Scott M. Graffius. All rights reserved. This material may not be published, broadcast, rewritten or redistributed without the express written permission of Scott M. Graffius.





custom - back to main page of blog





Typical Software Development Risks: Symptoms, Causes, Indicators, and Mitigations [From the Archives - First Published in 2012]

ScottGraffius_Com - From the Archives - Typical Software Development Risks and Mitigations - LwRes



black_spacer_lr_sq_v3

This article was first published on 16 December 2012.

black_spacer_lr_sq_v3

The risks for software development projects can vary. However, this article provides a view of the
typical risks along with the respective symptoms, root causes, leading indicators, and mitigations for each.

Risk: Inaccurate effort and estimates and schedules

  • Symptoms to watch for: Pattern of late deliverables; lack of awareness of schedule and status.
  • Potential root cause: Schedules based on business ('top down') need rather than team-generated ('bottom up').
  • Leading indicators: Earned value - schedule performance index (SPI).
  • Mitigations: 'Bottom up' planning; monitor effort and schedule; engage earned value for monitoring, control as needed.

Risk: Unconstrained requirements growth

  • Symptoms to watch for: Development staff cannot keep up with requirements changes.
  • Potential root cause: Requirements change not well-managed.
  • Leading indicators: Requirements change rate.
  • Mitigations: Plan for change (employ a requirements/change control process); don't start development until there is a stable set of requirements.

Risk: Dysfunctional organization

  • Symptoms to watch for: High project staff turnover; frequent staff reassignments; poor work environment; low productivity; staff lacks necessary skills and experience; and key role(s) are vacant.
  • Potential root cause: Lack of motivating work environment; poor management of project prioritization; lack of experience with work needed on project.
  • Leading indicators: Project staff turnover compared with historical trend; productivity; project team does not have an appropriate understanding of the requirements and project status.
  • Mitigation: Monitor, manage, and control issues and risks; status reporting; external (peer) assessment of project plans.

Risk: Poor software quality

  • Symptoms to watch for: High test defect counts; significant rework.
  • Potential root cause: Focus on schedule rather than quality.
  • Leading indicators: Test inspection yield; test defect density; defect discovery and closure rates/profiles.
  • Mitigation: Create a development quality plan that focuses on inspection rather than (only) test; measure and track against quality plan; cultivate a focus on software quality.

Risk: Under-performance

  • Symptoms to watch for: Low productivity.
  • Potential root cause: Technical complexity; development environment changes; under-achievement.
  • Leading indicators: Earned value - cost performance index (CPI).
  • Mitigation: Engaged earned value, control as needed.

Manage risks and you'll greatly improve the probability of success.

black_spacer_lr_sq_v3

How to Cite This Article

Graffius, Scott M. (2016, January 2). What Are Your Chances of Project Success? [From the Archives - First Published on 16 December 2012]. Available at:
https://scottgraffius.com/blog/files/archive---software-development-risks-and-mitigations.html.

black_spacer_lr_sq_v3

© Copyright 2016 Scott M. Graffius. All rights reserved. This material may not be published, broadcast, rewritten or redistributed without the express written permission of Scott M. Graffius.





custom - back to main page of blog