none
Release Readiness RRS feed

  • Question

  • Hi MOF Community.

    I have found, that the number one issue with my customers is that they implement It services that are not really Release ready. The operations team is not really able to operate an IT Services for a number of reasons. It is simply not handed over well enough from the project/development. This often lead to developers doing operations work, and they cant seem to finish the project.

    The way we look at this in MOF is to define Release readiness criteria. Some of the things are the stuff that goes into operational procedures, all the documentation about the setup, the servide desk needs to be informed, the backup needs to be configured, monitoring systems should reflect the new service and so forth.

    My question is: Do any of you have a good and generic list of things you recommend, the check list, or the release readiness criterias, that you can share with the community?

    That to me would be really interesting to discuss and to share.

    All the best

    Lasse
    Thursday, May 1, 2008 11:46 PM

Answers

  •  

    Hi Lasse,   

    This is a good discussion, the release readiness is a very important point to make shure that the new service (or changed service) stay ready to implement in operational environment. In my projects I take care on this points: 

     

    1. Make shure that documentation be agree with planned and approved by PM

    1.1. Kick of documentation

    1.2. Solution Design documentation

    1.3. Operations guide

    1.4. others important guides like backup, restore...

     

    -> Always to confirm with the customer if that is being done assists the need

     

    2. Make shure that test labs they were done with all possibilities 

    2.1. lab environment like production environment

    2.2. all doubts solved in test ambient

     

    -> Always to confirm with the customer if that is being done assists the need

     

    3. Make shure that all areas know about the new service 

    3.1 good communication plan

     

    -> Always to confirm with the customer if that is being done assists the need

     

    4. Make shure that all team was trained on the new service 

    4.1 with training and knowledge align

     

    -> Always to confirm with the customer if that is being done assists the need

     

    5. Make shure that the new service won't have problems with the services in production 

    5.1 with a pilot environment

     

    -> Always to confirm with the customer if that is being done assists the need

     

    I use this points in my day to day tasks and more things, and I don't forget a good Post-Implementation review :)

     

    Cleber Marques

    MOF Brazil Project

    www.clebermarques.com

    Friday, May 2, 2008 5:19 AM
    Moderator
  • Lasse

    I have a few things that I would make sure that every customer performs prior to implementing into production.


    Early on in the project the Operational Acceptance Criteria must be determined (early is key).  Ensure that Operations tells the project team what they need to manage the new IT system in production.  Ideally this could be several emails, but I would have a face to face meeting.  Put the responsibility of Operations to let the Project team know what they want.  The intent of this is to ask  "What are the key deliverables from the project team which must be in place to ensure a smooth transition to Operations"

    Some of the things that I could see Operations needing/wanting

    • Implementation Plan review
    • Operational Run Books
    • Post Implementation Audit, to ensure what was implemented reflects the design document and it is updated and handed over to Ops
    • Knowledge transfer sessions, each phase should have a Knowledge Transfer session and the Operations people should be there
    • after initial install
    • after tuning
    • Allow the Operations people to do the installation in QA prior to production
    • Documentation, including release notes, implementation plan, backout plan, test cases, test results
    • Operations Acceptance Testing, sign off....
    • Bug sheets
    • Operational Roles and Guidance
    • Procedural guidance
    • Troubleshooting tips

    Hope that I helped you out. 

    Monday, May 5, 2008 3:42 PM
  • Interesting topic....and a long-suffering problem :)

    Simplistically working on a few assumptions:
    Operations are the poor cousins and have no real authority to deny new projects from going live, and operational requirements are the first victims of project pressures.

    The suggestions about requirements/checklists so far are all good. I try to spend some time making sure that the project sponsors know what to expect with ongoing maintenance and operations costs - the 80/20 TCO rule can be quite useful to help prevent the premature death of the operational acceptance criteria. But all of this requires a fair bit of courage to enforce.

    Slightly off-topic......and along the lines of Darrel's post - I think we need to start shifting our thinking about this distinction between projects and operations. With operations taking the "victim" role this broken handover will never be fixed - operations is responsible for maintenance and if we think of this maintenance starting during the design and build phases then perhaps we can resolve the breakdown. And thinking a few years ahead....the rate of change will just increase - this means additional pressure on project resources - and perhaps it makes more sense to have the responsibility of operational handover belonging to operations?

    Tuesday, May 6, 2008 12:35 PM
  • In the MOF implementations I have been responsible for we used the Release Readiness Review not as the official hand over to Operations but as the decision point if the release would go live. That is not the same thing. In the Release Readiness Review the project manager responsible for the release has to prove the release is ready for production. This can be compared to the final check before a space shuttle will be launched, when Space Control will ask everybody responsible if they are ready to go. In the situation of an IT release you can say that the customer, users, developers, testers, support, operations, management, all of them need to say that they think the release is ready to go into production. That is maybe less planned than a formal checklist with acceptance criteria that is given to the release team upfront (which would be fair though).
    After the go-live the project team (or Solutions team) will stay responsible for the running of the release until the post-implementation review. In the PIR the formal handover to Operations (and Support team for that matter) will take place. Including the workinstructions, monitoring requirements, bugsheets/known errors, etc.

    Paul Leenards
    Getronics Consulting

    Tuesday, May 6, 2008 7:58 PM
  • Kathleen_ I can certainly see how the study of social systems could help you get to where you are now, but I wasn't being very idealistic good communications is the key in any solid managerial system, whether formalized or not. In fact while clear conceptualization of roles can benefit planning situations, execution of those plans can't be fossilized there are a great number of variables of things that can go wrong to throw off any script...'the best laid plans' as it were, and sometimes even to work too well and hence throw off schedule needed resources. So any really workable plan must incorporate viable and constant feedback mechanisms much as the different syatems and parts of the human body does. If the brain tells the hands to perform some task, it NEEDS to have the sensitivity to the perceptions of the fingers to make reasoned judgements that what it is trying to do has a good chance of working out. WE all learn very young what happens when we try to grasp a flame. The American business community has gotten a bad reputation for being too top driven, to insensitive to short term maximization at the expense of real long term costs, and being competitive to the point that the first thoughts even in forming partnerships are 'How can I get out of the commitments I'm making.' Something that has cost us dearly in dealing with European and Asian partners concerned with making things work out. The MOP 4 model shows a great deal of awareness to these problems. I'm delighted. Flexibilty not overspecialization is the key to survival. If life was as two dimensional as a board game then the Kasperov's and Fisher's of the world would ALWAYS win by being several moves ahead of anyone else...but it just doesn't work out that way very often. 
    archaeology of the future
    Wednesday, May 7, 2008 11:10 AM

All replies

  •  

    Hi Lasse,   

    This is a good discussion, the release readiness is a very important point to make shure that the new service (or changed service) stay ready to implement in operational environment. In my projects I take care on this points: 

     

    1. Make shure that documentation be agree with planned and approved by PM

    1.1. Kick of documentation

    1.2. Solution Design documentation

    1.3. Operations guide

    1.4. others important guides like backup, restore...

     

    -> Always to confirm with the customer if that is being done assists the need

     

    2. Make shure that test labs they were done with all possibilities 

    2.1. lab environment like production environment

    2.2. all doubts solved in test ambient

     

    -> Always to confirm with the customer if that is being done assists the need

     

    3. Make shure that all areas know about the new service 

    3.1 good communication plan

     

    -> Always to confirm with the customer if that is being done assists the need

     

    4. Make shure that all team was trained on the new service 

    4.1 with training and knowledge align

     

    -> Always to confirm with the customer if that is being done assists the need

     

    5. Make shure that the new service won't have problems with the services in production 

    5.1 with a pilot environment

     

    -> Always to confirm with the customer if that is being done assists the need

     

    I use this points in my day to day tasks and more things, and I don't forget a good Post-Implementation review :)

     

    Cleber Marques

    MOF Brazil Project

    www.clebermarques.com

    Friday, May 2, 2008 5:19 AM
    Moderator
  • Lasse

    I have a few things that I would make sure that every customer performs prior to implementing into production.


    Early on in the project the Operational Acceptance Criteria must be determined (early is key).  Ensure that Operations tells the project team what they need to manage the new IT system in production.  Ideally this could be several emails, but I would have a face to face meeting.  Put the responsibility of Operations to let the Project team know what they want.  The intent of this is to ask  "What are the key deliverables from the project team which must be in place to ensure a smooth transition to Operations"

    Some of the things that I could see Operations needing/wanting

    • Implementation Plan review
    • Operational Run Books
    • Post Implementation Audit, to ensure what was implemented reflects the design document and it is updated and handed over to Ops
    • Knowledge transfer sessions, each phase should have a Knowledge Transfer session and the Operations people should be there
    • after initial install
    • after tuning
    • Allow the Operations people to do the installation in QA prior to production
    • Documentation, including release notes, implementation plan, backout plan, test cases, test results
    • Operations Acceptance Testing, sign off....
    • Bug sheets
    • Operational Roles and Guidance
    • Procedural guidance
    • Troubleshooting tips

    Hope that I helped you out. 

    Monday, May 5, 2008 3:42 PM
  • Do you guys realize that if what you are talking about were implimented from a consumer to government level, we would have a planned economy? Likely one that worked.
    As a social scientist interested in the material development of society, what i've feared is that human societies tend to develop faster than social institutions like politics and certainly belief systems can keep pace...exhaust their natural and human resources...and then crash. MOP 4.0's a good model of what's possible. If we can keep our organizations open to both outside and uphill interior input, the net may yet resolve our mutual problems.
                                                                                                             Thanks for all your effort!
                                                                                                                        Darrel
                                                                                                                             Montana
    archaeology of the future
    Monday, May 5, 2008 10:00 PM
  • Ares

    I could not agree with you more.   So my ask of all of you working in these technical engagements out there is to ask this question to the Operations team.

    "What are the key deliverables from the project team which must be in place to ensure a smooth transition to Operations"

    By just simply asking the question is the first step, then use your ears and an open mind to hear what the answer is.  I am sure that every Operations person out there will thank you for asking this question and actually listening.  The next difficult step is to ensure that the project team delivers the items necessary for Operations.

    It does sound like Utopia, but I could bet on it that many project teams have not even done this.  The assumption is that Operations will Operate. 

    BTW... I did study Archeology in University, maybe this is why this seems so simplistic to me.

    Kathleen
    Tuesday, May 6, 2008 12:27 PM
  • Interesting topic....and a long-suffering problem :)

    Simplistically working on a few assumptions:
    Operations are the poor cousins and have no real authority to deny new projects from going live, and operational requirements are the first victims of project pressures.

    The suggestions about requirements/checklists so far are all good. I try to spend some time making sure that the project sponsors know what to expect with ongoing maintenance and operations costs - the 80/20 TCO rule can be quite useful to help prevent the premature death of the operational acceptance criteria. But all of this requires a fair bit of courage to enforce.

    Slightly off-topic......and along the lines of Darrel's post - I think we need to start shifting our thinking about this distinction between projects and operations. With operations taking the "victim" role this broken handover will never be fixed - operations is responsible for maintenance and if we think of this maintenance starting during the design and build phases then perhaps we can resolve the breakdown. And thinking a few years ahead....the rate of change will just increase - this means additional pressure on project resources - and perhaps it makes more sense to have the responsibility of operational handover belonging to operations?

    Tuesday, May 6, 2008 12:35 PM
  • In the MOF implementations I have been responsible for we used the Release Readiness Review not as the official hand over to Operations but as the decision point if the release would go live. That is not the same thing. In the Release Readiness Review the project manager responsible for the release has to prove the release is ready for production. This can be compared to the final check before a space shuttle will be launched, when Space Control will ask everybody responsible if they are ready to go. In the situation of an IT release you can say that the customer, users, developers, testers, support, operations, management, all of them need to say that they think the release is ready to go into production. That is maybe less planned than a formal checklist with acceptance criteria that is given to the release team upfront (which would be fair though).
    After the go-live the project team (or Solutions team) will stay responsible for the running of the release until the post-implementation review. In the PIR the formal handover to Operations (and Support team for that matter) will take place. Including the workinstructions, monitoring requirements, bugsheets/known errors, etc.

    Paul Leenards
    Getronics Consulting

    Tuesday, May 6, 2008 7:58 PM
  • Kathleen_ I can certainly see how the study of social systems could help you get to where you are now, but I wasn't being very idealistic good communications is the key in any solid managerial system, whether formalized or not. In fact while clear conceptualization of roles can benefit planning situations, execution of those plans can't be fossilized there are a great number of variables of things that can go wrong to throw off any script...'the best laid plans' as it were, and sometimes even to work too well and hence throw off schedule needed resources. So any really workable plan must incorporate viable and constant feedback mechanisms much as the different syatems and parts of the human body does. If the brain tells the hands to perform some task, it NEEDS to have the sensitivity to the perceptions of the fingers to make reasoned judgements that what it is trying to do has a good chance of working out. WE all learn very young what happens when we try to grasp a flame. The American business community has gotten a bad reputation for being too top driven, to insensitive to short term maximization at the expense of real long term costs, and being competitive to the point that the first thoughts even in forming partnerships are 'How can I get out of the commitments I'm making.' Something that has cost us dearly in dealing with European and Asian partners concerned with making things work out. The MOP 4 model shows a great deal of awareness to these problems. I'm delighted. Flexibilty not overspecialization is the key to survival. If life was as two dimensional as a board game then the Kasperov's and Fisher's of the world would ALWAYS win by being several moves ahead of anyone else...but it just doesn't work out that way very often. 
    archaeology of the future
    Wednesday, May 7, 2008 11:10 AM
  • Thanks guys,

    This is all very interesting stuff and inputs. I will be building a checklist that I would share with the community once I am a bit further. I truly believe that it can be made. The complexity of the list will very much depend on the nature of the Service and whether it was build in house og installed out of the box. some tests may not apply and things like that.

    thanks for sharing your inputs.

    Cheers

    Lasse
    Friday, May 16, 2008 1:40 PM
  • I’m marking this post as answered, if you guys need any help about MOF please open a new thread. J

    Thank you,

     

    Cleber Marques
    MOF Brazil Project: Simplifying IT Service Management
    www.mof.com.br | www.clebermarques.com | www.clebermarques.com.br
    Thursday, May 28, 2009 10:12 AM
    Moderator