Versions Compared

Old Version 9

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

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

Decompositions

Human Resources

Take the quality that invokes the highest score.

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. 

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.

Score

Software Application

Data

Integration

1

minor patch or security release, no end-user function affected

single schema

self-contained, single end-user transaction

2

major patch, "dot release" that effects end-user behavior

single database, multiple schemas

system of record, affects data feeds to warehouse

3

full application upgrade, new user functionality

external link or feed relationship to other system of record

service allows for real-time update of share enterprise data

4

operating-system upgrade as distributed release or affecting many underlying services

multiple external links or feed relationships

real time integration service, loss of service ends business productivity

5

packaged release of operating system, multicomponent or multi-transactional system

multiple production database servers changed

real-time integration service, requires client applications to refactor

Community Impact

Score

Impact

1

 

2

 

3

 

4

 

5

 

End Notes

End Notes

Not in any particular citation format, unless that becomes important.(ed. to become properly formatted end notes later. sml)