seat58F
outsourcing relationships: international, inter-economic, interpersonal
September 4, 2010 ~ 09:44:16 AM * -07:00ST
PMO critical success factors
Post # 213 by
admin on February 27th, 2009 ~ 03:31:40 AM
Posted as PMO |
No Comments »
ideally, the PMO is not autonomous. it should take direction from the executive committee and then make appropriate adjustments to the service development pipeline. project priority needs to be flexible enough to accomodate changing business needs.
the PMO understands resource availability really well. it should also be able to delegate actions to other suppliers. a good PMO scorecard looks like this:
executive committee does:
Post # 257 by
rc on February 26th, 2009 ~ 08:53:15 AM
Posted as executive team |
No Comments »
- implements the Board’s strategy and policies
- proposes services strategy and policy revisions to the Board
- proposes asset mgmt strategy (including budget planning) to the Board
- monitors operations
the innovation group (?)
Post # 262 by
rc on February 24th, 2009 ~ 09:09:00 AM
Posted as innovation |
No Comments »
if there is going to be a designated “innovation group”, there better also be a “transformation group”. someone has to manage the obsolescense of services and service components. i think its totally appropriate to make the innovation people own the transformation responsibilities also.
innovation can’t be thrown over the wall with no recognition of the impact to steady-state operations. if outsourcing is about flexibility, new service innovations should have install / uninstall features and be tied to metrics that demonstrate that the expected business outcomes are happening.
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.
roadmaps
Post # 273 by
admin on February 21st, 2009 ~ 10:19:26 AM
Posted as innovation, transformation, vintage chart |
No Comments »
the xPMO should be able to produce a road map describing where the services are going to be in the intermediate future. the services support targeted business outcomes (profit, growth, cu-sat, …) and are enabled by the organizations and its relationships.
imagine a version of this roadmap that helps your suppliers understand what you expect of them.
a roadmap depicting multiple service development paths can be represented in a “vintage chart” format:
- the X axis is time with the smallest level of granularity being a quarter
- the Y axis represents services and service components; the components are shown to evolve as they extend to the right.
this chart conveys the sense of a service lifecycle; an important stimulous for those responsible for operations transformation. if the chart captures emerging service capabilities, it can also be used to vision with your outsourcing suppliers, reminding them in a not so subtle way that the relationship needs to evolve.
config wish list
Post # 205 by
admin on February 19th, 2009 ~ 02:01:00 AM
Posted as availability, business outcome, config |
No Comments »
configuration mgmt databases are notoriously difficult to maintain. every change should touch the CMDB in the planning, approval, and implementation stages. hopefully the records get updated during this cycle.
maybe because we think about SLAs in terms of availability and we think of availability in terms of boxes, we end up registering the boxes as the most meaningful CIs in the CMDB.
there are two glaring weaknesses in this approach: we don’t recognize the context of the service delivered to the end user and we don’t recognize the context of the business outcome belivered to the business.
suggestion: register business outcomes as the CI root. then identify all the infrastructure elements, the participating service providers, and the end users as supporting CIs.
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.
service element shopping cart
Post # 199 by
admin on February 18th, 2009 ~ 06:46:16 AM
Posted as business outcome, service catalog |
No Comments »
one really nice thing about a service catalog is the fact that the resources required to enable a new business outcome are well known. the service architect should be able to pick catalog elements and immediately understand the resource implications to provide a quote.
then its a matter of integration, instrumentation, and deployment; - voila.
who pays?
Post # 269 by
admin on February 15th, 2009 ~ 09:53:31 AM
Posted as PMO, innovation, r&d, xPMO |
No Comments »
the executive committe xPMO pays for straight innovation. they have the larger window on the business landscape.
the client manager pays for r&d with funds derived from the contract.
the xPMO should be aware of client specific requirements and have a seat at those PMO meetings.
shift logs
Post # 188 by
admin on February 14th, 2009 ~ 10:20:08 AM
Posted as shift log |
No Comments »
shift logs are designed to provide a snapshot of the transaction flow; incident mgmt items of note including escalations, outages, maintenance, security events.
a few opportunities are normally missed:
reconciliation of actual to forecasted volumes.
shift capacity; planned vs. actual
