Narrowing Tool Selection Criteria Based on Stakeholder Requirements

One of our followers recently asked about how to handle the CIO's concern about security in a cloud environment when evaluating tool solutions. To my mind, the CIO is expressing a potential requirement that should be considered and that may narrow your selection criterion.

Your selection criteria should assist in achieving two outcomes. One is to narrow down the list of providers and their products to a workable number so that you are not spending undue amounts of time evaluating too many vendors. The other is to ensure that the products you have selected to evaluate really do meet 80% of your stated requirements out of the box.

You will need to develop three criteria sets. The first list is a set of criteria of what you would like the tool to do in terms of supporting your documented and defined processes (call these functional requirements). Functional requirements are those things that help you to achieve utility of your processes and services. You will also need a set of criteria in terms of what the tool can do as a tool (call these non-functional requirements). Non-functional requirements are those things that help to deliver on the promise of warranty (in the form of availability, capacity, continuity and security). The third list of selection criteria would be at the technical specification level, and would deal with the inner workings of the source code of the tool, underlying database structures, etc.

You will need to weight each criterion to determine the necessity or importance of that criterion. Not all requirements are created equal. So if your CIO has a concern about cloud technologies, then that needs to become one of your non-functional requirements or selection criteria (in this case an Information Security requirement). Since a CIO is a stakeholder their requirements must be considered when putting together your selection criteria. You will need to weight that against other criteria in terms of how important the criterion is for your organization.

Once you weight each requirement, you then need to evaluate and score each vendor against those lists of criteria. The two vendors with the highest total from the scoring can be brought on site for demos and further evaluation.

Comments

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services, which is people. Because the people element adds variability, the service is variable. This holds true, especially for the value proposition—not eve...

What Is A Service Offering?

The ITIL 4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group. As a service provider, we can’t stop there! We must know what the contracts of our service offering are and be able to put them into context as required by the customer. Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include: Goods, Access to Resources, and Service Actions 1. Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods. Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you. You the consumer own these and they are yours to take with you. ...

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

This article was originally published in 2015. With the Introduction of ITIL 4, some of this best practice has changed. See ITIL 4 and the Evolving Role of Roles . Updated Definitions in ITIL 4: Process Owner: In ITIL 4, the concept of 'processes' has expanded into broader 'practices.' Consequently, the Process Owner is now often referred to as the 'Practice Owner.' This individual is accountable for the overall design, performance, integration, and improvement of a specific practice within the organization. They ensure that the practice achieves its intended outcomes and aligns with the organization's objectives. Process Manager: Now commonly known as the 'Practice Manager' in ITIL 4, this role is responsible for the day-to-day management of the practice. The Practice Manager ensures that activities are carried out as intended, manages resources assigned to the practice, and oversees the practitioners performing the work. Process Practit...

Search