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 the process for updating and managing your service portfolio (Klosterboer). Releaseball accomplishes this.

• 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.
  • 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 criteria, or decompositions. (PMBoK)

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

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

Type of Work Flow

Instead of the sizing metaphor, tiny/s/m/l/xl, this is one method of "cascading" change types that I found, worthy of discussion. This is an example and a simplification but shows some difference in ways of looking at a "decision guide" model in ways we have not.

The goal is to end up with a cascade of categories that apply to a release or a "bundle" of releases that go together and their associated requirements for release process.

The "release category" implies certain standard procedures for work in that area. The other help determine risk and impact and requirements for thorough process vs. quick response and other factors.

Human Resources

I saw an example of something like this on a site called GDPA, which claims it is based on standards. However, I haven't found sizing matrices in any standard with specific reference to the size of the release.

I would recommend sizing, if we go that route, based on the staff required to do the release, not the staff that did the project.

*Attrition Risk is risk of individual flight, pending budget reduction/downsize, or single points of failure. 

End Notes

Not in any particular citation format, unless that becomes important.

• Head First PMP
• GDPA IT Project Types http://www.informatik.uni-bremen.de/gdpa/part3/p3t2.htm (About GDPA: http://www.informatik.uni-bremen.de/gdpa/aboutgdpa.htm)
• Wikipedia Summary of Identifying and Managing Project Risk by Tom Kendrick http://en.wikipedia.org/wiki/Identifying_and_Managing_Project_Risk
• Klosterboer, Larry. "Chapter 3 - Defining Change and Release Management Processes". Implementing ITIL Change and Release Management. IBM Press. © 2009. Books24x7. <http://common.books24x7.com.libproxy.mit.edu/book/id_30900/book.asp> (accessed July 28, 2010)
• The Visible Ops Handbook