How to assess Project Success and Failure in SPM.

8 b] How to assess Project Success and Failure in SPM.

Assessing project success and failure in Software Project Management (SPM) involves evaluating various criteria and metrics that determine whether a project has met its objectives, stayed within scope, time, and budget constraints, and delivered the expected value to stakeholders. Here are key factors and methods to assess project success and failure:

  1. The project plan should be designed to ensure project success by preserving the business case for the project. However, even non-trivial projects can have problems, and what stakeholders view as a failure may differ.
  2. Project objectives and business objectives are distinct. The agreed functionality, required level of quality, on-time delivery, and within budget are key project objectives. Meeting these does not guarantee business success.
  3. Project deliverables may meet the project objectives but still fail to meet the business case, for example, if a computer game is delivered on time and budget but does not sell well.
  4. Project management focus on internal factors like development costs and number of customers may not capture the broader business impact. Increasing development costs can reduce the chances of the product being profitable.
  5. Technical learning from earlier projects can benefit later projects, but the focus of project management is not on the immediate project but on the broader business impact over time.
  6. There is a potential trade-off between a narrower project management view and a broader business perspective that includes factors like market surveys and user feedback.

The passage also discusses how different stakeholders can have different perspectives on whether a project is a success or failure. Even a “non-trivial” project that meets its technical objectives may still be viewed as a failure by some stakeholders if it doesn’t align with their specific interests or the overall business case.

It notes that “project deliverables” – meaning the actual outputs or functionality delivered by the project – may meet the agreed project objectives in terms of scope, quality, schedule and budget, but still fail to fully deliver the expected business benefits. The example given is of a computer game being delivered on time and budget, but not actually selling well.

The passage emphasizes that the “focus of project management is not, intuitively, on the immediate project” but rather on understanding how the project fits into the broader business context and objectives over time. It suggests that factors like development costs and the number of customers may not fully capture the ultimate business impact.

Interestingly, it notes that “technical learning” from earlier projects can benefit later projects, even if the earlier projects were not entirely successful from a business perspective. This highlights how project management is an iterative process where lessons can be carried forward.

Overall, the key message seems to be the need to maintain a balanced perspective that considers both the technical project objectives and the overarching business goals and impacts, while recognizing that different stakeholders may have varying views on what constitutes true project success.

Leave a Reply

Your email address will not be published. Required fields are marked *