...
- 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
Wiki Markup
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.
...
*Attrition Risk is risk of individual flight, pending budget reduction/downsize, or single points of failure.
...
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.
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