seat58F
outsourcing relationships: international, inter-economic, interpersonal
September 4, 2010 ~ 09:49:22 AM * -07:00ST
first, the good news
Post # 323 by
admin on April 28th, 2009 ~ 07:17:47 AM
Posted as change, incident, knowledge, problem, release |
No Comments »
a new release, as a collection of enhancements or bug fixes, is expected to improve overall functionality and service effectiveness. change managers and release planners should be able to anticipate any negative effects, but the communication about those issues to end users or the helpdesk usually does not happen.
at minimum, problem managers need a heads-up to give them a chance to write some sort of release note to give the helpdesk a hint as to the expected impact.
gauge lab redux
Post # 77 by
rc on March 19th, 2009 ~ 12:09:26 PM
Posted as change, metrics |
No Comments »
we had gauge labs that housed all of the instruments used to verify inbound parts and to check tolerances during manufacturing. it was somewhat uncomfortable going to ask for an instrument because it meant interrupting a tech fine-tuning an instrument or replacing a component based on a calibration or maintenance schedule. calibration strickers recorded status.
The simple objective was to ensure valid results from measuring equipment. To do this calibration was performed and tracked. The instruments were protected against improper adjustment (the lab was restricted access) and protected against damage (transit cases and carts were used to move them to the mfg floor).
today, service levels drive much of the conversation with the client. the client is focused on *interpretation* of the numbers and, for whatever reason, we loose awareness of the tool configuration details that essentially represent changes in “calibration”. over time, the significance of the collected data can easily change if the service provider changes how the data is collected.
most frequently, data is skewed by changes in workgroups as new people come in with perhaps different language skills; common terms can be interpreted in many ways. the source of data can also change over time. the most pernicious examples occur when service mgmt tool throttles are adjusted to “drop” transactions that do not meet certain criteria. These actions should transit a transparent Change Mgmt process, but normally, they don’t.
red days
Post # 101 by
rc on March 18th, 2009 ~ 08:23:58 AM
Posted as change, config |
No Comments »
red days are designated “hands off the infrastructure”; no changes allowed. delivery teams need to have a feel for application activity throughout the month and quarter. It would help if the service managers had a solid understanding of all infrastructure elements (and suppliers) required to complete transactions.
even emergency changes need to be handled with extra care during these periods. impact assessment, implementation and test planning should be more formal than normal.
delivery manager denial
Post # 48 by
rc on March 13th, 2009 ~ 02:03:56 AM
Posted as change, problem |
No Comments »
just accept it, your service architecture is part of the problem. delivery bugs contribute directly to outages, client dissatisfaction, and unnesessary cost on both sides. if the app development guys can do it, you can too. estimate the population of bugs, identify, document, prioritize and squash them one by one. (Unless the contract allows you to be paid by the ticket - and you really need to own up to that one.)
bad situation #1: recurring service support events ripple negative impacts to the client. so you get more tickets. patch installations and backups are obvious culprits. so too the lack of a structured return to production test suite. establish a calendar and stick to it. have really good reasons for emergency changes. take personal umbrage when a new ticket comes in. some enhanced capability (that the CIO will pay you for) could have prevented that ticket.
bad situation #2: the dependencies between infrastructure elements are not documented for the change managers, so they unintentionally break stuff. yes, comercially packaged configuration mgmt is expensive. yes, you can build a functional app with open source tools. It just a matter of ensuring that 2nd level support feels some ownership for the CMDB and the knowledge base.
bad situation #3: incident records are not analyzed for root cause. just train the supervisors in production statistics 101 and you can save some big bucks. everyone should be able to drive down client cost of service outages by 30%. to get there, the service provider needs 1st level mgmt expertise. Then add some supplier mgmt expertise, and you can talk about reducing your own costs and increasing your margins by engaging a supplier of your own.
Delivery Managers absolutely need to know the client perspective cost numbers, the CIO *will* ask at some point, and it should already be on your private dashboard.
don’t stomp on the backups
Post # 208 by
admin on February 23rd, 2009 ~ 10:14:03 AM
Posted as change, release |
No Comments »
backups are susceptible to collisions during the implementations of new releases.
the release manager should ensure that the backup shedule does not overlap the change window and that all changes are evaluated for impact to the backup process.
for that matter, people have to decide how change implementations are going to be production validated.
change orchestration
Post # 195 by
rc on February 18th, 2009 ~ 09:32:17 AM
Posted as change, release |
No Comments »
discrete change windows usually mean that approved changes are all implemented at essentially the same time. change managers coordinate the resources and report success in the context of individual changes.
a “release manager” should be responsible to evaulate the bigger picture, a aggregate view of a current changes, understanding the relationship of one change to another, and the resource impact during the change window.
release plan approval should be the final line item in the change board agenda; we’re trying to verify that the pending changes are synchronizzed in terms of resources and backout plans.
