Service Launch Fundamentals for Successful Deployment
In this comprehensive guide, John Beckett outlines key strategies for launching a service successfully, including planning for potential issues, the six-step launch process, defining a ready list, and working through it efficiently. From specific and unambiguous criteria to launching beta and production services, this resource covers essential aspects to ensure a smooth rollout for any service.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
19 Service Launch - Fundamentals John Beckett CPTE 433 Beckett Additions highlighted like this
What Service? VPN server OS installer Web-based application Remote meetings/instruction/service
19.1 Planning for Problems Expect problems challenges This doesn t mean you failed Be careful that your planning doesn t create the problem Experience helps Lesson from Apollo program: Planning helps Keep a checklist with what to do for each
19.2 The Six-Step Launch Process 1. Define the Ready List 2. Work the List 3. Launch the Beta Service 4. Launch the Production Service 5. Capture the Lessons Learned 6. Repeat
19.2.1 Defining the Ready List Must Have feature set Would be nice feature set Bugs to be fixed Assertians & approvals Legal Security Management Operational (e.g. capacity) Title Priority Responsible person Link to history Status Use not required rather than deleting it from a list people have seen
Specific and Unambiguous Specific what is to be improved Measurable how will we know it s achieved Achievable can we do this? Relevant worthwhile, corporate goals Time-bound when do we need this Some of these may not be needed for some items, e.g. deadline for simple bug report
Where do you keep the ready list? Bug or ticket system with tags Bug or ticket system with watchlists Tag classifies these items for your list Kanban board Online or shared spreadsheet Text says to keep it in one place Could you tag a specific ready list in your ticket system?
19.2.2 Work the List Connect your people to the list Meet regularly Weekly Daily stand-up If you are alone, you need a ready list
19.2.3 Launch the Beta Service There are various levels: Dev anything can happen Quality Assurance we think it s ready User acceptance Beta or Early-access Production Legacy people who haven t converted yet
19.2.4 Launch the Production Service This is when the service goes live for essentially the remainder of your users Communicate, communicate, communicate The text suggests staging larger and larger groups If you can t do that, you need to immunize yourself against problems by doing more planning and testing
Case: Replacing Southerns telephone system circa 1985 Began on Monday of Spring Break Moved dorm phones over one-by-one, tested Prepared offices so that cutover could be cone by switching eight 25-line cables Wednesday: took the team out for pizza at Rafael s. Are we ready? Actual cutover took about 15 minutes that evening Outside line access code changed from 2 to 9 Configured so that dialing errors routed to the switchboard so we could remind them of the new procedure Note: outside line digit went back to 2 a few years later due to a 911-access issue
19.2.5 Capture the Lessons Learned Make notes as you are mopping up Have a review meeting where you will finalize these into Things we still need to do Things we need to do before next time
Textbook suggestion for report Executive summary Timeline Successes Failures Short-term changes Long-term changes
19.2.6 Repeat This is a cycle, not a one-time happening In a cyclic environment (e.g. school), bear in mind that much will be the same each time but some things will or should change
19.3.1 Launch Readiness Criteria Examples Service is monitored Monitoring alerts are configured Backups & restores are tested and working Standard authentication, authorization, and access control have been tested and are working SLA is defined Service request model is in place User documentation is complete Online, and tested using actual users Operational documentation is complete User training is complete Load testing is complete Ten-times response plan is developed and tested
Developing the LRC Don t just add remove obsolete Best way: make that function automatic Is it an excuse not to launch? If bypassed, launches will go wrong Base it on experience not just good ideas Can we really remove that item? If the list is too bloated, we can t do small batches
19.4 Launch Calendar Need a central place and curator Should this launch be isolated from others? Does it depend on another launch? Is that date a goal for launching, or a deadline by which it must be done?
19.5 Common Launch Problems Unexpected access methods (e.g. VPN) Resources unavailable New technology failures (e.g. printer speed) Beware of mismatched yardsticks Lack of user training No backups (or no way to go back)
