Month: May 2012

Leveraging Business Analysis Techniques for ITSM Work

I came across IIBA’s Business Analysis Body of Knowledge (BABOK) a few years ago, and I like its overall requirement analysis and handling approach. Business analysis is nothing new, and people have been doing BA work for a long time. Still, it was good to see the BA discipline get captured and documented in a well-organized framework, just like having ITIL for managing IT. Over time, I have developed a simple workflow for doing the ITSM work using some of the BA techniques and tools. If you need a starting point for developing your own ITSM/BA practice, I will go into details on some of the steps within the workflow.

Business Analysis Workflow Sample

Come Across a Business Idea or a Need: This is the starting point of the process. A business idea may have come from an organization within the company, or a need may have risen. In any case, we want to know whether it makes sense to turn the idea or the need into a project and understand how well the project will match with the business’ overall goals and mission. In the next two activities, we will try to gather more information about the project and analyze them further.

Capture Previous Lessons: One way to understand the degree of business alignment for a project is to learn from previous, similar projects. If you have such information available, it will be very useful to leverage it for the alignment decision. I like this particular activity from PRINCE2, so I have included it in my own methodology.

Conduct Enterprise Analysis: You may need to conduct a study, formal or informal, to determine the alignment between the project and the business needs. Your organization’s methodology will have a large influence on this particular activity and the outcome of the decision. If you need more information, Chapter Five of BABOK discusses the Enterprise Analysis topic extensively.

Initiate Business Case and Project Charter: Once the project is determined to have an overall positive business alignment, the information gathered during the enterprise analysis phase can essentially be turned into a business case. Also, many organizations require a formal charter document for any project. You should have sufficient information to initiate both documents at this point.

Gather Requirements: After the enterprise analysis activity, gathering requirements is the next key task. As we are all intuitively aware of, requirements are critical to get them right because they serve as the foundation for the solution to the project. Chapter Three of BABOK covers the knowledge area of Elicitation. The key thing to do, according to BABOK, is to “ensure that a stakeholder’s actual underlying needs are understood.”

Analyze Requirements: Once you have gathered the requirements, you need to make sure they are as complete, accurate, and consistent as they can be. You will also need to prioritize the requirements based on their level of criticality to meet the final project objectives. Chapter Six of BABOK covers the knowledge area of Requirement Analysis.

Formulate a Solution: Assessing and validating the solution will leverage the output from the enterprise analysis and requirement analysis activities. I also put a few decision points within the workflow to demonstrate that the BA process is not always linear. You may find yourself back to gathering more requirements, refining what you have, or coming up with another solution based on the new information that may have come along. Chapter Seven of BABOK covers the knowledge area of Solution Assessment and Validation.

Update Business Case and Project Charter: Once we arrive at the solution that meets the requirements and the business needs, we update the business case and project charter to include the updated information. The analysis, for the most part, is completed for this phase of the project. We will now focus on the implementation and subsequent assessment of the performance and effectiveness of the solution.

By applying the BA techniques, I believe a number of ITSM organizations and projects can benefit immensely from blending the BA discipline into their own methodologies or approach. The suggested workflow is just one of many ways to get the job done, and I believe it can work with various project management approaches such as the traditional waterfall, agile, etc. The BABOK offers a wealth of information on the BA practices and processes that you can use and integrate into your ITSM practices and processes.

Fresh Links Sundae – May 27, 2012 Edition

Fresh Links Sundae encapsulates some pieces of information I have come across during the past week. They maybe ITSM related or not entirely. Often they are from the people whose work resonates with me, and I hope you will find something of value.

Rob England expressed his viewpoint of why using menu as the analogy for service catalog is not that simple. A menu is not a service catalogue (The IT Skeptic)

Damon Edwards got together with two other industry experts to talk about their experience and insights on the DevOps topic. High Velocity Release Management with Alex Honor and Betsy Hearnsberger (dev2ops)

Jeff Wayman discussed some excellent points for taking on a brand new ITSM initiative or trying to revive an under-performing one. The key is to center around taking on small bites, achieving results, and iterating continually to improve and to compound the smaller, positive results into a bigger one. ITIL for the Beginner: 4 Common Misconceptions (ITSM Lens)

If you are looking for ideas on how to set up or improve your change management practice, Alicia Choo has published something that is worth looking into and adapting it for your organization. My take on ITSM and IT Governance: Change Management (Choofca’s Brain Dump)

Julie Craig gave several suggestions on minimizing the probability of your enterprise management software acquisition becoming shelfware. Just say NO– to shelfware (EMA Blog Community)

Perry Rotella gave his thoughts on three key considerations a CIO must address to ensure operational success in managing the data within the organization. Data Excellence = Executive Success (Forbes)

Bret Simmons talked about the importance of not withholding truth as part of a leadership lesson. If You Don’t Have Something Nice To Say (Positive Organizational Behavior)

Julie Peeler talked about some simple steps to take to better protect you from disclosing too much data via social media. Data leakage in social media ((ISC)2 Blog)

Charles Betz suggested how a different approach like Demand-Supply-Execute can improve what we do in IT management today. Moving from Plan-Build-Run to Demand-Supply-Execute (Nimsoft Modern IT Blog)

Anna Farmery suggested the use of S.U.P.E.R. model to improve our effectiveness in what we do in business. Why Tomorrow…is so Yesterday (The Engaging Brand)

Actionable Ideas on Running a Better Sysadmin and Devops Shop

When I ran across Adam Jacob’s “Choose Your Own Adventure” video from Velocity 2010, I liked the talk a lot. His thoughts on system administration and IT management resonate very well with mine. Why? Because I started out and grew up in my IT career as a sysadmin, I can totally appreciate where Jacob is coming from. Jacob also presented his viewpoints in a straight-forward, no non-sense style, which was a pleasure to listen to. When the video for the “Choose Your Own Adventure 2” session from Velocity 2011 became available, I had to check it out. Here are some concepts from the talk that I really enjoyed – I hope you will, too!

DevOps: Whether you are in dev or in ops, we are still on the same team. It is also not possible to work in isolation these days – teamwork has to be it. Join the inclusive folks and ditch the ones who promote this us-vs.-them attitude.

Managing Operations: The divide between dev and ops, we created and did it to ourselves. Allocate the responsibility correctly and everyone (dev or ops) needs to shoulder the burdens equally. After all, we are on the same team.

No Asshole Rule: Based on Dr. Robert Sutton’s great book, civility is still the noble goal to strive for these days. With the social network technologies, it is pretty easy to spread the passive-aggressive snarky crap and behave badly in order to put down or undermine someone else’s viewpoints or effort. Try not to do those things if you can.

Philosophy of Automation: Jacob explained why automate and I agree. The success of any IT system is ultimately measured by the end solution and what the solution enables your organization to do. Automate when you can and keep things standardized, consistent, and working well. The working end solution will in turn promote system availability and business efficiency.

8 Tips for Full Automation: Eight solid, fundamental advices on getting your IT automation work done and done well.

Check out the Velocity 2011 video on YouTube

Fresh Links Sundae – May 20, 2012 Edition

Fresh Links Sundae encapsulates some pieces of information I have come across during the past week. They maybe ITSM related or not entirely. Often they are from the people whose work resonates with me, and I hope you will find something of value.

Through the SEAS and CARE principles, Jeff Wayman suggested some opportunities for improving the efficiency and effectiveness of service desk function. 8 Areas to Improve Help Desk Customer Experiences (ITSM Lens)

Alicia Choo started cataloging and sharing her thoughts on IT service management and IT governance via her blog. I wish her much success and look forward to reading her great work. Here is a sample of what is to come. My take on ITSM and IT Governance: Foundation (Choofca’s Brain Dump)

Charles Betz shared three books that, when taken together, can outline a program for improving IT management. Three books for the next ten years (Charles Betz)

Simon Morris discussed the concept of Coach Loop and how you can use its iterative nature to improve the processes in your organization. Be sure to check out the whitepaper that discusses this topic in detail. Increasing process performance using feedback loops (ServiceNow Community)

James Finister talked about six factors that can lead to poor decisions and outcomes when practicing ITSM. The 6 Deadly “I”s of IT Managers (Core ITSM)

Using a couple of survey examples, Charles Betz suggested that having a consistent IT terminology is more important than most people think. Semantics matter: the troubled world of IT terminology (Charles Betz)

Ten experts shared their viewpoints on how they see where IT is in relation to social media and how this relationship should develop. 10 Key Issues on Social Media and IT (Evolven Blog)

Expanding on the premise of learning is just as important as performing; Bret Simmons talked about situations where people fail to recognize the need of learning, not just performing. Ten Signs You Are Too Smart To Learn And Too Incognizant to Know (Positive Organizational Behavior)

Seth Godin talked about beating the competition is not so much about working harder or being more creative. Hard work on the right things (Seth’s Blog)

Mark and Mike of Manager Tools talked about creativity being not so much as having wild ideas out the blue but noticing things that are more fundamental. Creativity (Manager Tools)

ITSM Tools Operation Continuity Plan – Part Two

We discussed the first several topics (scope, data considerations, and external dependencies) that should go into an ITSM tools operation continuity plan during a disaster recovery (DR) scenario. In this post, we will conclude the discussion by covering the people, procedures, checklist, and validation sections of the plan.

Recovery Team and Communication

The section spells out the key roles and the staff members who will be responsible for implementing the plan. It will include the typical information such as name, organization affiliation, location, and contact details. This section should also include agreed upon communication protocols for the duration of the recovery process. For example, teleconference bridge information could be something useful to include, if that is your organization’s standard practice. Also, if your organization has a major incident handling practice with standard communication and reporting requirements, you can cover the pertinent details within this section or at least make a reference to it.

Recovery Procedure and Configuration Details

This section outlines the recovery instructions and procedures with as many details as necessary for a successful recovery. This section also provides all configuration details that need to be in place in order for the recovery solution to work as designed. Just how much information do you really need to include in the document? I believe the level of detail will largely depend on whom your organization anticipate will execute the plan or heavily influenced by your organization’s disaster recovery plan.

By default, I would recommend having the level of detail based on the assumption that the people who will execute the plan are NOT the same folks who operate the production environment pre-disaster. This is the safer router in my opinion.

For example, your organization uses ITSM product XYZ, made by company ABC and operated by an off-shore team from vendor OPQ. When a disaster strikes your data center, the network connectivity between your data center and your production personnel from OPQ was cut off. At this time, your OPQ vendor has another team at a different location who can access the recovery site and knows your ITSM product. With a properly documented recovery plan with the right level of details, you can leverage your vendor’s second team quickly to start working on the recovery without any help from the production team.

Checklist of Key Actions or Milestones

To help everyone who needs to understand and execute the plan, I recommend having a section that outlines the key tasks and activities so no important activities will be missed. The checklist can also be used to show the various communication and escalation points.

Testing and Validation Steps

This section outlines the detailed testing strategy and validation activities required to implement the recovery plan. Similar to the recovery procedures section, it is highly recommended that these instructions are comprehensive, so the recovery solution can be fully tested by people who may not be the same team as your production crew. The section should also account for all potential conditions, events, and scenarios. The section should contain information that can be used during the testing such as:

  • What are the success criteria for the test objectives?
  • What are the assumptions defined for this test, if any?
  • When is the testing window?
  • How should the security setup be taken into consideration?
  • Which tool modules will be tested?
  • Who will be conducting the test?
  • What are the steps to validate the application and data integrity?

Return-To-Normal-Operation Procedure

This section describes the instructions/procedures necessary to return to the normal production environment once it has been restored. For this section, I would say probably the most key information to explain is how the data will be synchronized between the production and the DR systems. Again, the key objective is not to lose any data captured by the ITSM tools while it was operating in the DR setup. This section will also include the necessary testing and validation steps to ensure that the production system is back in full operation, so the DR system can be fully shut down and return to the stand-by mode.

An ITSM Tools Operation Continuity Plan Example

I hope this particular discussion on the ITSM tools continuity plan provides something of useful tidbits for your organization to think about and to plan for. Considering the importance of the data and transactions captured by the ITSM tools for many organizations, having a workable continuity plan is really not optional anymore. If you don’t have anything in place now, I recommend start small by drafting a plan and making the scope compact enough to cover just a few high probability and high impact scenarios. Work with someone within your IT organization who is responsible for the overall IT continuity plan, so your plan can integrate well with the overall IT and business objectives.