Versions Compared

Old Version 5

changes.mady.by.user Stephen M Landry

Saved on

compared with

New Version Current

changes.mady.by.user Stephen M Landry

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

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.

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

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

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.(ed. to become properly formatted end notes later. sml)