Versions Compared

Old Version 8

changes.mady.by.user Stephen M Landry

Saved on

compared with

New Version 9

changes.mady.by.user Stephen M Landry

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This document compares the release process being designed for IS&T (releaseball) with documented standards for IT service delivery.

Base Model

  • In ITIL, your release should be integrated with an overall release policy and the process for updating and managing your service portfolio during the work flow. Releaseball accomplishes this. (Klosterboer)
  • In ITIL, release should include update of a "definitive media library" as part of the release work flow. (Visible Ops, Klosterboer)
  • Consider five size categories for all IT projects: Extra Small, Small, Medium, Large, and Extra Large. (ed. This is one or two more categories than prior art I have discovered so far – sml)
    • Our conception is mostly based on project length (time) and a vague concept of complexity. So far, not meshing with ITIL or Six Sigma. More to come.
    • "Size" in Six Sigma appears to relate to the complexity-as-risk and
    "Size" means the complexity and risk as
    • impact on the end-user community.
  • The Size Category determines the release processes that must be followed, normally called "work flows." That is the sole purpose of this tool.
  • Determine sizing score by considering a concrete set sizing criteria, or decompositions. (ed. Decomposition of Risk, PMBoK – sml)
  • Still figuring out if these should be summed, averaged, or some other math.

Phases

Phases

"Each release adds incremental function to the overall service and represents a separately deployed part of the service." (Klosterboer)

  • ITIL, Agile, and other theories all recommend strongly encouraging more frequent but smaller, simpler releases.
  • Our process achieves that but does not set policy for what a "phase" is, which essentially breaks the processIf you can break a project down into discrete phases of lesser impact, you can reduce the amount of required process and complexity.
  • A "phase" is only a phase if it can result, on its own, in a discrete improvement to the product or service.You can reduce scope by eliminating non-dependent phases.
  • A project "phase" must end in a release. It is not just a discrete unit of work. This is a "release unit."

Decompositions

Human Resources

...