Page History

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. (ed. This is one or two more categories than prior art I have discovered so far – sml)
• "Size" means the complexity and risk as impact on the end-user community.
• The Size Category determines the release processes that must be followed. 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

• • 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 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.

Decompositions

Human Resources

• 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 projectTake the quality that invokes the highest score.

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

Release Complexity

A release can contain more than one of these. Consider only parts of the service subject to change. Take the quality that grants the highest score.

ITIL Outline discovered by Pat on Wikipedia:

I found some tid bits on Wikipedia in the ITIL section that may or may not be helpful (high level)

Release categories include:

Major software releases and major hardware upgrades, normally containing large amounts of new functionality, some of which may make intervening fixes to problems redundant. A major upgrade or release usually supersedes all preceding minor upgrades, releases and emergency fixes.

• Minor software releases and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as emergency fixes. A minor upgrade or release usually supersedes all preceding emergency fixes.
• Emergency software and hardware fixes, normally containing the corrections to a small number of known problems.

Releases can be divided based on the release unit into:

Delta Release: a release of only that part of the software which has been changed. For example, security patches.

• Full Release: the entire software program is deployed---for example, a new version of an existing application.
• Packaged Release: a combination of many changes---for example, an operating system image which also contains specific applications.

End Notes

(ed. to become properly formatted end notes later. sml)

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://mv.ezproxy.com.ezproxyberklee.flo.org/book/id_30900/book.asp> (accessed July 28, 2010)
• The Visible Ops Handbook