Posts Tagged ‘IT Service Management’
A Good Start Point for Devops – Guest Post by Peter McGarahan
Source: http://www.flickr.com/photos/stevepj2009/3461077400/
Many of the devops posts in this blog were written from a dev perspective. Today’s guest post by Peter McGarahan examines the topic from the ops perspective. It is inspired by the following eloquent quip about change:
Assume we’re starting from scratch. Assume that we actually are a startup that doesn’t have over a hundred years of experience and sub-optimized IT legacy.
A few biographical details for readers who might not know Peter or know of him. Peter J. McGarahan is the founder and president of McGarahan & Associates, an IT Service Management consulting and training organization. Peter offers 27 years of IT and Business Service Management experience in optimizing and aligning the service and support organizations of the Fortune 1000 to deliver value against business objectives. His thought leadership has influenced the maturity and image of the service and support industry. His passion for customer service led the Taco Bell support organization to achieve the Help Desk Institute Team Excellence Award in 1995. IT Support News named him one of the “Top 25 Professionals in the Service and Support Industry” in 1999. Support professionals voted McGarahan “The Legend of the Year” in 2002 and again in 2004 at the Service Desk Professionals conference for his endless energy, mentoring and leadership coaching. As a practitioner, product manager and support industry analyst and expert, McGarahan has left his service signature on the support industry / community.
Here is Peter:
As a former Director of Infrastructure & Operations (I&O), I found it beneficial to establish a respectful working relationship with my Development Colleagues. It was important for the accountable leaders to better understand the objectives, workings and success metrics of each team. It was also critical for the leader to establish the ‘rules of engagement’ for how each team would assist each other in achieving their stated objectives (success metrics). It certainly helped to have an IT / Business leader who established a cooperative / collaborative teamwork culture. She also supported it with shared IT / Business objectives and performance goals for all accountable IT leaders. The I&O team certainly benefited from a CIO who understood the importance of customer service, the value of support and the business impact (negative IT perception) caused by repetitive incidents, problems and service disruptions. It was a game changing day for I&O when the CIO announced that all accountable leaders would have half of their performance objectives (bonus compensation) based on the success metrics of the I&O team.
In working with Infrastructure & Operations organizations, it has become apparent that as we continue to implement, measure and continuously improve the IT Infrastructure Library v3 (ITIL) processes, we must simultaneously address how we focus on all things new! In a recent Cutter Executive Update entitled IT’s Change Imperative, I relate lessons learned from my conversations with Geir Ramleth, CIO of Bechtel and Ron Griffin, Senior VP of Applications for Hewlett-Packard. Their leadership, vision and courage inspired me to think differently about how IT can better work together for the benefit of the business. In the end, the only success that matters – is the continued growth and profitability of the business. A summary of their change success stories:
- Hewlett-Packard CIO Randy Mott hired the right people to implement his IT strategy and change plan that included building, consolidating and automating its data centers; transferred work in-house from contractors; standardized on only a quarter of its apps; and built one central data warehouse — all while cutting spending in half.
- Geir Ramleth, CIO of Bechtel described how he used cloud computing principles to transform IT and make Bechtel’s computing environment more agile. He had a vision of allowing Bechtal’s global employees access to the right resources at any place at any time with any device – delivered securely and cost-effectively. He encouraged his IT people to step outside their comfort zones and do things in a different way. He resisted modifying the current state and went with the transformational change fearing they would only wind-up incrementally better. In targeting a desired end state, he gave his team guiding instructions to “Assume we’re starting from scratch. Assume that we actually are a startup that doesn’t have over a hundred years of experience and sub-optimized IT legacy.”
In the spirit of change, we should challenge ourselves to develop shared ‘devops’ goals / objectives. In the end, these should help us identify, link and realize how to translate IT objectives / metrics into tangible business benefits / value.
I have listed some shared ‘devops’ goals / objectives that I believe are a good starting point. I encourage and invite your thoughts, opinions and ideas around these and any others that you feel would aid ‘devops’ in working to establish measurable business value credibility.
- Lower the total cost of ownership of all services (best way to achieve this is build them with serviceability, usability and maintainability in the design of all new applications, systems and services).
- Increase business value – achieve business benefits (lower operational costs, increased revenues, improved customer experience)
- Simplified navigation
- Productivity enhancing capabilities /functionality
- Plug ‘n play integration
- Personalization
- Training / On-line Self-help features
3. Minimize business impact
- Reduce change-related outages / incidents.
- Reduce number of problems / incidents / calls.
- Reduce the number of requests / training-related calls / inquiries.
- Provide insights and tracking to the number of Known errors / workarounds / knowledge articles (solutions).
- Speed to resolution based on business prioritization model
- Operating Level Agreement / Commitment between Single Point of Contact (SPOC) Service Desk and internal IT Service Providers based on response / resolution times / commitments.
- Bug-fix Process:
– Provide insights into the ‘bug/fix/enhancement’ list and process with transparent visibility to business prioritization (needs / requirements / quantifiable benefits).
4. Improved and frequent Communication
- A marketing / product launch / status update and awareness campaign.
- Especially around rollout / enhancement time.
Prior to Sprint Zero: A Note on Jakob Nielsen’s “Agile User Experience Projects”
Dr. Jakob Nielsen published the results of a follow-on study to his 2008 report Agile Development Methods and Usability. The bottom line from the 2009 study (entitled Agile User Experience Projects) is as follows:
The two main recommendations for ensuring good usability in Agile projects remain the same as in our original research:
Separate design and development, and have the user interface team progress one step ahead of the implementation team. That way, when it comes time to build something, it’s already been designed and tested. (And yes, you can do both in a week or two by using paper prototypes and discount user testing.) Maintain a coherent vision of the user interface architecture. Create the initial vision during a “sprint zero” period — before any implementation has started — and maintain it through annual (or semi-annual) design vision sprints. You can’t just design individual features; they have to fit together into a coherent whole — a whole that must be designed as well. Bottom-up user interface design equals a confused total user experience (the Linux syndrome).
I would like to highlight one implicit sub-aspect of Dr. Nielsen’s good counsel to maintain a coherent vision of the user interface architecture:
- Ensure coherence with the underlying application paradigm
To illustrate the point, think of a Business Service Management Application. You might monitor any number of servers, routers, databases and applications in order to ensure that a service satisfies the corresponding Service Level Agreement. However, the user interface architecture should have service as its fundamental concept. The architecture should certainly enable zooming in on any component of the service. But, the status of any such component (or sub-component) is merely means to an end: reflecting the status of the service and initiating as appropriate action(s) to fix it. Forming a service piecemeal from a number of constituent elements like those mentioned above – servers, routers, databases, applications, etc. – is no substitute to “service orientation” of the user interface.
The reason for my strong emphasis on the service as the most fundamental user interface concept is nicely captured in the article “How to Spell BSM” by BSM Review‘s Tom Bishop:
Most businesses today are so dependent on IT that, if an IT organization does not understand how the business depends on its services, or does not manage those services with that business perspective in mind, they are dooming the business to slow, steady death….
Dr. Nielsen’s recommendation to conceive the initial user interface architecture prior to beginning any implementation work is very consistent with this imperative need in BSM to manage the services from a business perspective. I would actually go one step further and contend that whenever the underlying paradigm changes in a manner as dramatic as the servers –> services in the BSM example above, demonstration of the core concept(s) of the user interface might need to precede the “sprint zero” period. In the context of the overall planning and budgeting process which governs the Agile process, such demonstration could actually be a pre-requisite to launching “sprint zero.”
If you consider this “prior to sprint zero” approach a bit heavy-handed, I would offer a simple test to assess its reasonableness. Play with a number of IT Service Management (ITSM) products that you picked in random. Once you did so, compare the numbers of those that clearly have services at their core, to the number of those that integrated services into their user interface as an afterthought.
Agile Business Service Management
Over the weekend we activated the BSM Review. It is a thought leadership website dedicated to next practices in Business Service Management (BSM) in a way that is appropriate for our era. To quote my colleague and friend Bill Keyworth:
This website is dedicated to the BSM dialogue by whoever wishes to participate. There is no fee to join …no content that requires a subscription …and no censorship of reasonable ideas and questions.
My area of focus in this site is Agile Business Service Management. The term is defined as follows:
Agile Business Service Management (Agile BSM) is the fusion of modern software development methods with the prevailing preference to run IT from the perspective of the business customer. Instead of dividing the “world” to development on the one hand and operations on the other hand, Agile Business Service Management unifies the two to manage them as part of one continuum that improves the delivery and usage of the application to the targeted business end-user. By so doing, it crosses the metaphorical chasm between the R&D lab and the customer door (or laptop, or iPhone, or…)
My research agenda in the context of the BSM Review will be outlined in a forthcoming post. For now, suffice it to say it will primarily be driven by two themes:
- Business alignment: At the heart of it, BSM is a discipline to better align business with IT; at its core, Agile is about “customer collaboration over contract negotiation.” The two are conceptually similar: they express the strong desire in both development and operations to carry out meaningful tasks that have business impact.
- Continuous manufacturing: I view IT as a form of continuous manufacturing. If you accept this premise, the application of Agile concepts, principles and techniques to IT management makes perfect sense. Just as Agile has been influenced by Lean techniques from manufacturing, it has the potential now to influences (continuous) manufacturing in its IT incarnation.
If software development is your primary interest, you might find my forthcoming posts in BSM Review go a little beyond the traditional scope of software methods. If, however, you are interested in software delivery in entirety, you are likely to find good synergy between the topics I will address in BSM Review and those I will continue to bring up in The Agile Executive. Either way, I trust my posts and Cote’s will be of on-going interest to you.
The Agile Executive 