Skip to main content

The Question

One of the most important tools in the toolbox for implementing Service Management is “The Question”. Effective questioning can help make both a new and existing implementation more successful. Good questioning techniques take practice and knowledge like many other skills. It can take years to move questioning from a skill to a talent. But learning how to ask and answer questions is a valuable instrument.

Questions go beyond just the closed (specific answer) and open (subjective or broad answer). Questions can fall into several other categories and each should be approached in different ways:

INDUCTIVE: there are designed to aggregate information and will be used effectively in Incident Management; Problem Management and Change Management.

How do a set of Incidents correlate?

DEDUCTIVE: these are designed to break down or decompose information and will be used effectively in Problem Management and Service Level Management.

What are the elements that make up an existing service?

ABDUCTIVE: these are designed to find the best possible answer and will be used effectively in Financial Management, Portfolio Management and Service Level Management.

What should be our strategy to adjust to changes in the
marketplace?
Questions can help in many ways:
  • Gathering data and information
    How many incidents occurred yesterday?
  • Comprehending and understanding the data and information
    Did the Request for Change impact the service?
    Analyzing the data to create information
    Does the increase in response times indicate a trend?
  • Applying the information to turn it into knowledge
    If we find root cause for Problem A, will that help us fix Problem B?
  • Synthesizing knowledge into wisdom
    Can I get greater capacity by combining Service Desks?
  • Evaluating information and knowledge in order to gain wisdom through judgments
Is the Portfolio balanced to meet the needs of the customer and the business?


Used correctly, questioning is the basis for good Knowledge Management. By using various types of questioning techniques we can move from data to wisdom. Another benefit of questioning helps us avoid assumptions or to manage perceptions. Perhaps the single most powerful question we can ask in terms of Service Management is “why?”

Say a person asks you to approve a Request for Change. You should ask “why?” They may say it has low risk, no impact and little cost. That should lead to another powerful question: “Is that fact or an assumption?” By asking this question you get people to rethink their assumptions or perceptions. Perhaps it is low cost, risk and impact. But that needs to be proven through data, not through perception or opinion or assumption.

Hopefully you can see that using questions can be a strong tool. The key is to think about questions before you need to ask them. Have a quiver of questions ready at your disposal and do not be afraid to use them.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…