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.

Fresh Links Sundae – May 13, 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.

Johna Johnson discussed the movement from the Information Technology era to the Enterprise Technology era and how IT professionals can prepare themselves for this transition. From IT to ET: Cloud, consumerization, and the next wave of IT transformation (Network World)

Jeffrey Rayport discussed the requirements and approaches that could encourage more innovative behaviors from an organization’s frontline workers. Free Your Frontline Workers to Innovate (Harvard Business Review)

Joshua Simon suggested four important areas to automate as part of the email support structure. Help Desk 101 – 4 Essential Automations for Email Support (ITSM Lens)

James Finister shared his thoughts on the mobile computing, the BYOD trend, and how to take advantage of trend. The Lure of Shiny New Toys (Core ITSM)

Ellen Messmer talked to the IT organizations in two companies and got their (rather opposite) viewpoints on the BYOD mobile computing trend. BYOD battle: A tale of two opposing IT viewpoints (Network World)

Rob England gave his opinions of comparing two sources for good IT practices: ITIL and COBIT. Why COBIT wins in a showdown with ITIL (The IT Skeptic)

Rob England used a railway example to describe what a service catalog is and can do for the organization. What is a Service Catalogue? (The ITSM Review)

Troy DuMoulin describes an ITSM transforming approach used by Pink Elephant to help its clients bring results. Pink Elephant’s ITSM Transformation Methodology (Troy’s Blog)

Anna Farmery suggested that one approach of managing people should be from the value-creation perspective, like managing a balance sheet in business. The People Balance Sheet (The Engaging Brand)

Adrian Reed talked about the pitfalls to avoid and to remedy when conducting workshops. How to avoid 7 common workshop pitfalls (Bridging the Gap)

ITSM Tools Operation Continuity Plan – Part One

If your IT organization is like most others, you rely heavily on your IT service management (ITSM) tools for delivering IT services to your business customers or constituents. Many IT shops also have a comprehensive suite of ITSM tools they use as part of the various aspects of their operation. It is my personal belief that the ITSM tools operate like the ERP systems for many businesses – the ITSM tools are providing a critical service to the IT organizations.

While many ITSM products on the market today are well made and come with industrial strength resiliency, technology failures or other disasters can still cause the tools to become unavailable for use. When the tools unavailability or outage stretches out from merely minutes into hours or days, you need to have a continuity plan to get the tool services restored so your IT organization’s operations can continue normally without further hindrances. The ITSM tools operation continuity plan needs not to be fancy or sophisticated, but it does need to be well thought-out with as many details called out beforehand as possible. This is the part one of a two-part post where we will go over what components should go into such plan.

This section provides an overview of the plan. Why the plan exists? Who is the owner accountable for drafting and/or executing plan? How will the plan be maintained and tested for validity or accuracy? Any other high-level, overview information about the plan will be helpful to include in this section.

This section includes the comments on what conditions will trigger the actions to invoke this plan. It is important to point out who will be authorized to invoke and to implement this plan. It is also important to outline the availability requirements and targets once the plan is invoked.

This section describes the ITSM modules, systems, infrastructure, services and facilities that will be part of this plan. A number of ITSM systems do not operate in isolation these days, so identifying all components required for a functional ITSM system could be daunting. That is OK. Just have a boundary in mind and do your best. If possible, include and provide as much information on the infrastructure that hosts the ITSM products as feasible. This could include the actual server names, databases, and other components deemed essential and critical for the operations of the ITSM tools. If you have a CMDB with the relationships documented, those relationships between the system components and your plan should be consistent with each other.

Depending on your operation, not all ITSM modules need to be part of this continuity plan. For example, I surmise tool modules or services such as Incident Management, Change Management, or anything the Service Desk uses could be high on the priority list to get restored ASAP. Problem Management module probably can wait and get restored as part of the normal system recovery cycle.

Data Dependencies and Considerations
This section includes comments about the data requirements that need to be met before the recovery plan can be implemented. What data is needed for the recovery and what preparation activities are required to get the data in place? This is more than just calling out what database servers are needed for recovery, which should have been discussed in the Scope section. I am talking about things such as how current the data need to be before the recovery procedures can be executed. Another consideration is how the data that was captured during the recovery phase will be incorporated back into the main database once the original systems come back online. The key objective here is not to lose data, during recovery and post recovery.

Security and Access Considerations
This section includes the important details about the security and access related matters. For example, what access rights will your systems and personnel require in order to fully execute the plan? Often we have the security and access considerations on the back burners and forget about them. During the recovery phase, things are not working as expected and, after many rounds of discussions and trouble-shooting exercises, we realize the security access might be preventing things from working. Don’t put yourself in the position of being unprepared and wasting time. Figure out those security and access details beforehand and document them in the plan.

External Dependencies and Considerations
This section calls out the systems, infrastructure, service, facility or interfaces that are external to the ITSM system but have inter-system dependencies that should be documented. Essentially, anything that has not been identified in the Scope section but still required for recovery should be mentioned here. That way, all dependent systems and the nature of dependency can be identified and taken into account during the plan execution. For example, we might want to include information about the email system and its key interface points because most ITSM systems have a reliance on the email systems for communication.

That is all for now. On the next post, we will conclude the discussion of the plan and cover the remaining topics:

  • Recovery Team and Communication
  • Recovery Procedure and Configuration Details
  • A Checklist of Key Actions or Milestones
  • Testing and Validation
  • Return-To-Normal-Operation Procedure

Fresh Links Sundae – May 6, 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.

ITIL Projects: What to Do, and What Not to Do Jeff Wayman gave ten solid advices on what to and not to do when implementing ITIL as part of your IT service improvement project. (ITSM Lens)

10 Expert Insights on the future of the CIO With the changes influenced by technologies such as virtualization and big data, Evolven blog collected opinions from ten experts on how they see the role of the CIO changing and developing. (Evolven Blog)

ITIL – pragmatic and simple Geir Isene and Geir Isene outlined their recommendations on a simpler and more straight-forward implementation of some of the core ITIL processes. (Geir Isene Blog)

Choosing your Change Planning Team Mitchell Nash wrote a three-part post on how to plan an organization change management initiative (not necessarily the ITIL Change Management process) within your organization. (Linkage, Inc.)

How IT can alienate the very people they serve Patrick Gray talked about some of his observations on how some IT organizations tried to be helpful but left the opposite impression on its customers. (TechRepublic)

Feed It Forward Marshall Goldsmith suggested using a “FeedForward” process and explained how it works. (Marshall Goldsmith)

Top Ten Ways To Be a Male Advocate for Technical Women NCWIT suggested ten ideas on how managers can better support technical women and promote diversity efforts in their organizations. (NCWIT Resources)

Calling All Women Executives: Part 5 Mark Goulston talked about  observations behind why many women afraid to ask for what they want, need and deserve in the work place and what they can do about it using something similar to the “FeedForward” approach. (Usable Insight)

A simple antidote to a corporatized, unfeeling, profit-maximizing world Seth Godin made a simple suggestion on how to find your own compass and a reason to do the work you do in the first place. (Seth’s Blog)