Versions Compared

Old Version 9

changes.mady.by.user Stephen M Landry

Saved on

compared with

New Version 10

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

  • PRO: In ITIL, your release should be integrated with an overall release policy (Klosterboer). Releaseball accomplishes this.
  • PRO: In ITIL, your release should be integrated with and the process for updating and managing your service portfolio during the work flow(Klosterboer). Releaseball accomplishes this. (Klosterboer)
  • CON: In ITIL, your release should include update of a "definitive media library" as part of the release work flow. (Visible Ops, Klosterboer) Releaseball does not accomplish this.
  • Consider five size categories for all IT projects: Extra Small, Small, Medium, Large, and Extra Large.
    • 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 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.
    • CON: We should be using language categorizing risk due to complexity and risk due to community impact (Six Sigma)
    • CON: "Size" as a metaphor for these problems is a weak criteria in literature I've reviewed so far.
    • Recommendation: Determine release categorization by considering a concrete risk and impact
    Determine sizing score by considering a concrete set sizing
    • criteria, or decompositions. (
    ed. Decomposition of Risk,
    • PMBoK
    – sml
    • )

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 process.
  • A "phase" is only a phase if it can result, on its own, in a discrete improvement to the product or service.
  • A project "phase" must end in a release; this is a "release unit." It is not just a discrete unit of work.

Decompositions

Wiki Markup
This is

...

 a significant simplification of some \[ed. overly complicated\] industry scholarship.

Type of Work Flow

What is a release?

...

Human Resources

Take the quality that invokes the highest score.

...