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.

Release Category

Release Urgency

Release Workflow

Data Center

Emergency

Configuration

Workstation

Urgent

Integration

Data Changes

Normal

Infrastructure

Doc/Admin Changes

Long, Complex

Custom Software

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.

Score

Man Years

Project Members

Skills Gap/Consulting

1

<= 0.25

1

None

2

0.25 - 0.5

2

< 10% Consulting or Attrition Risk*

3

0.5 - 1

3 - 5

10-25% Consulting or Attrition Risk

4

1-2

6-10

25-75% Consulting or Attrition Risk

5

> 2

> 10

Approaching 100% Outsourced

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

  • No labels