Lab Maturity Model - quali.com€¦ · Lab Maturity Model By Gregory Sloan, Sr. Field Solutions...

Lab Maturity ModelBy Gregory Sloan, Sr. Field Solutions Engineer

www.qualisystems.com

Lab Maturity Model2

1 Overview of the Lab Maturity Model 3 1.1 Definition of the LMM Maturity Levels 3

Level 1 – Ad Hoc 4Level 2 – Shared 4Level 3 – Operational 5Level 4 – Enterprise 5Level 5 – Strategic 6

1.2 Key Process Areas 6Goals 6Common Features 6

2 The Key Process Areas of the LMM by Maturity Level 7 2.1 Key Process Areas – Maturity Level 2 7 2.2 Key Process Areas – Maturity Level 3 8 2.3 Key Process Areas – Maturity Level 4 9 2.4 Key Process Areas – Maturity Level 5 9

3 Key Practices 10 3.1 Maturity Level 2 Key Practices 10

KPA: Asset Tracking 10KPA: Conflict Resolution 11KPA: Utilization Efficiency 12KPA: Resource Abstraction 12KPA: Capital Planning 13

3.2 Maturity Level 3 Key Practices 13KPA: Process Efficiency 13KPA: Process Integration 14KPA: Test Automation 15KPA: Test Reporting 15

3.3 Maturity Level 4 Key Practices 16KPA: Organizational Efficiency 16KPA: Distributed Utilization 16KPA: Automation Reusability 17

3.4 Maturity Level 5 Key Practices 17KPA: Utilization Metrics 17KPA: External Coordination 18KPA: Lab as a Service (LaaS) 18

4 References 19

Contents

Lab Maturity Model3

Overview of theLab Maturity Model1

Definition of the LMM Maturity Levels1.1

By evaluating existing process, procedures, practices, and documentation in an organization with large scale lab management needs, different levels of maturity can be assigned. These levels are a way to summarize what the organization’s current capabilities are, as well as help define a plan to improve their processes to reach higher maturity levels and therefore meet higher goals. Which level an organization currently resides in is determined by comparing what activates they perform, documentation they keep, and processes they have defined. An organization may have characteristics from higher maturity level, but they have only achieved a level if they exhibit ALL of the characteristics of that level.

The diagram below provides a summary view of the 5 Lab Maturity Levels.

(QualiSystems, INC, 2013)

Baseline

High utilization

Asset trackingHigh utilization

High test throughput

Shorter schedules

Shared Corporate Asset

Enable virtual labs

Lab as a Service (LaaS)

Business Collaboration

Business Metrics and ROI

Lab Maturity Model4

Level 1 // Ad Hoc

Level 2 // Shared

This is the baseline of the Lab Maturity Model and indicates an organization that has little to no formal definition of lab management processes. Lab users tend to work as individuals, controlling their “own” equipment. Sharing is rare because the individual users are reluctant to give up control of equipment that they are familiar with as they have no guarantee of finding a suitable replacement when needed. Sharing of other information, such as topologies used for testing, is minimal as well. Each individual has their own environment and executes tests using their own methods not necessarily applicable in other users’ environments.

Management typically has limited understanding of their inventory. Equipment is delivered into the lab, then disbursed based on ad hoc negotiations between the individual lab users. Actual utilization information (what percentage of equipment is being actively used for what percentage of time) is hard to come by, but can generally be summarized as “low”. With lab users territorially protecting favorite equipment, these devices will regularly sit unused until that individual user needs it, even if it could be used effectively elsewhere.

Any automation is also typically only applicable to local user environment and not repeatable/sharable. It is developed as-needed by users not necessarily possessing automation expertise. As a result, it is usually valid only for the duration of the specific project it was written for or at best the lifespan of the specific piece of equipment it was written for, and tends to be very statically defined such that it can’t be reused by other lab users or in other topologies.

Because of this lack of reusable automation, reconfiguration of the lab is a slow, manual process. Either new localized scripts need to be produced for every topology change, or no scripting is used at all and everything is handled manually. As a result, test plans are often written to cover only a subset of possible configuration combinations due to limited time to maintain and switch between the full required set. Test planning becomes an exercise in risk management, finding the minimal set of configurations that will give some level of confidence that the remaining untested configurations will not contain errors.

Reporting both of lab utilization and test results, where it exists, is generally a manual process relying on the users to interpret results and enter them manually. This typically means that reporting is on an honor system making it difficult to guarantee accuracy and completeness.

The most important improvement that enables a lab to move from Level 1 to Level 2 is for the organization to have full knowledge of their lab assets. This is the foundation for all of the capabilities and processes required to achieve a Shared level of maturity.

As the name implies, at this level lab equipment is shared between users. By having an accurate and accessible catalog of lab assets, users can give up individual control of resources, knowing that they can find a suitable replacement by referencing the inventory. It reduces time spent finding resources, conflict between users, and time that equipment is sitting idle.

An organization at this level has visibility into real utilization data. By managing resources as a shared pool rather than individual environments, automatic data and reports can provide and accurate understanding of what equipment is in high demand, what equipment is being underutilized, and what equipment might be obsolete. Consequently, future procurement decisions can be made with a better understanding of actual lab needs. Rather than purchasing enough equipment to support each individual users’ environments separately, analysis of utilization reporting enables purchasing the minimum amount of equipment necessary to satisfy the shared need.

Lab Maturity Model5

Since all users are now sharing the same equipment and infrastructure, details about the testing environments can be effectively shared. Topologies can be documented and recreated from that documentation. Similarly, basic automation can be developed that is applicable beyond an individual’s environment or a single project. Scripts that can be executed on shared resources to perform common repeatable tasks can be used by anyone. Lab reconfiguration can similarly be automated, whether through the use of Layer 1 switching or automatically generated work orders to physically re-cable routes based on topology requirements.

Level 3 // Operational

Level 4 // Enterprise

As the lab management solution matures, the awareness of the lab and its assets can increase beyond simply identifying equipment. By adding more details of things like power infrastructure or communica-tion channels, higher level automation beyond simple scripts can be implemented. This will often take the form of automated provisioning procedures tied to topologies. This can include automatic control of power as well as automated setup and configuration of lab equipment. This will greatly reduce the time and effort required for users to reconfigure the lab between project needs, freeing them for other tasks and increasing the potential test coverage.

With topologies being sharable, repeatable, and predictable, basic test automation can be introduced. One of the biggest hurdles to effective test automation is configuration management. In labs doing telecom type testing, a large variety of equipment types and vendors mean a large number of variables test automation potentially needs to take into account. Controlling those variables with automated lab management procedures minimizes what test automation has to deal with and development can focus on creating tests rather than managing the test environment. Once the test automation can trust that the environment it is running in will be set up correctly, test execution becomes repeatable and sharable. At this level of maturity an organization also can receive the benefit of the first automated test reporting, no longer reliant on individual users manually reporting test data. Test criteria are clearly defined in automa-tion and details of the test execution environment can be accurately pulled from the lab management environment, allowing the organization to accurately answer questions about what was tested in what environments.

Prior to the fourth level of maturity, the benefits of lab management are typically limited to a single organization within a company. Larger companies may have many different organizations sharing the same lab space, geographically separate labs used by the same or different organizations, or geographically distributed users who can benefit from remote access to a managed lab. This type of corporate resource sharing can be enabled with mature lab management. Identifying pools of resources that can be grouped with access control allows for safe sharing of lab management infrastructure between different groups. Provisioning automation reduces or eliminates the need for physical access to equipment allowing remote lab access to users not located with the lab. Comprehensive automated test and lab usage reporting allows centralized tracking of distributed usage. By integrating these disbursed organizations with lab management, the efficiency benefits can be felt across the corporation.

Lab Maturity Model6

Companies that require this high level of maturity do not operate alone. They need to be constantly collaborating with customers and partners to plan their testing needs and understand future requirements. With a fully mature lab with automatic provisioning, testing, and reporting, this collaboration can include providing customers and partners access to lab resources. This is often referred to as the “Lab as a Service” Model. Typically if an outside organization wanting to validate their own product against a company’s, either that company has to bring the outside organization’s product into their lab and execute the tests, or the outside organization needs to procure (either purchase or negotiate a loan or trade) the equipment from the company and set up their own lab. A fully mature lab on the other hand can simply provide access to the required equipment through their lab management process. This frees the lab from having to perform the testing themselves, and frees the outside organization from having to maintain their own expensive lab. Other benefits include, since the testing by these organization now conforms to the lab’s standards, ease of reproducing issues found by customers and partners.

Each KPA will have a list of goals associated with it. They summarize the intent of the practices and features of the process area and provide a guidepost to evaluate any proposed process or activity meant to satisfy the KAP and achieve the maturity level.

Each KAP has a set of common features. The scope of this document includes two common features of all KPAs, Ability to Perform and Activities Performed.

Ability to Perform – A definition of organizational policies, environmental needs, and tools that must be in place to achieve the goals of the KPA

Activities Performed – Descriptions of activities that need to be performed within the organization to achieve the goals of the KPA

Level 5 // Strategic

Goals

Common Features

Key Process Areas1.2

Key Process Areas (KPAs) (further defined in Section 5) are high level processes that encapsulate goals, organizational features, and key practices that an organization needs to have implemented in order to achieve the specific maturity level.

Lab Maturity Model7

The Key Process Areas of the LMM by Maturity 2

Key Process Areas – Maturity Level 22.1

For each level of maturity, key process areas can are defined. These are listed in Figure 2. Each key process area is a general description of related activities that when implemented within the organization help achieve the goals defined by the particular maturity level. They help to identify the steps that need to be implemented and gaps that need to be closed to reach each subsequent level. Since Maturity Level 1 is defined as not having any well-defined lab management processes, it is the default maturity level and has no key process areas associated with it.

The key process areas of Level 2 focus on managing the physical assets of a lab with the goal of enabling sharing and increasing awareness and efficiency of resource utilization. The key process areas are:

Asset Tracking – This is the foundation for all goals of the LMM. Detailed information about lab assets should be stored in a central database with the ability to search and maintain up to date configuration information. Metadata relevant to the organization should be defined to aid in reporting and user interaction. The goal is to maintain visibility into what assets are in the lab, their current availability, and historical usage.

None

Asset Tracking

Conflict resolution

Utilization Efficiency

Resource Abstraction

Capital Planning

Process Efficiency

Process Integration

Test Automation

Test Reporting

Organizational Efficiency

Distributed Utilization

Automation Reusability

Utilization Metrics

External Coordination

Lab as a Service (LaaS)

Lab Maturity Model8

The key process areas of Level 3 focus on improving the process of using equipment once it’s been identified and allocated. The overall goal is to reduce the duration and manual effort required for a lab user between the time they identify the equipment they want to use and the time they actually start using the equipment. The key process areas are:

Process Efficiency – This goal refers to creating repeatable, well defined processes for configuring equipment. It should include some level of automation to interact with lab assets via scripts and standardization of topologies to reduce the amount of customization and reconfiguration required between projects or when changing configurations during a project.

Process Integration – The goal of process integration is to reduce the number of different tools and processes required to setup and access allocated resources. As much as possible the steps necessary to begin doing actual work should be integrated into the lab management tools and processes so a lab user can complete their setup tasks with a straight forward, repeatable, and predictable set of steps.

Test Automation – Testing previously done manually or with static scripts that are difficult to share and reuse should begin to be automated at this level. They should leverage the existing lab management solution so the work of identifying and maintaining the underlying configuration does not get in the way of effective testing.

Test Reporting – Test reporting should no longer be left to manual entry by users. Automated tests should produce reliable, repeatable, and accurate reports that incorporate configuration data taken from the lab management solution.

Conflict Resolution – To effectively promote resource sharing in the lab, process must exist to resolve conflicts when access to scarce resources is needed. This should include a combination of programmatic tools that communicate with the asset tracking environment to display and track resource availability and business rules to manage priorities between conflicting users and needs.

Utilization Efficiency – The purpose of this process area is to put in place reporting and process that ensure resources are being utilized efficiently. An organization should be able to identify which resources are scarce, which are underutilized, and which are obsolete. Equipment should be reallocated to remove bottlenecks.

Resource Abstraction – This is a valuable tool to aid in utilization efficiency. Where possible lab resources should be viewed by their relevant metadata rather than as individual pieces of equipment. Rather than holding work up waiting for availability of a particular piece of equipment, the lab management solution should allow users to locate and allocate any resources that meet the criteria of their usage needs.

Capital Planning – Utilization data collected at this maturity level should be used to improve capital planning. Scarce resources should be purchased to keep up with usage demands. Sharable resources should be purchased in smaller quantities than when the lab is operated without good management practices.

Key Process Areas – Maturity Level 32.2

Lab Maturity Model9

The key process areas of Level 4 focus on sharing lab assets and processes beyond the organization that originated the lab management solution. The goal is to leverage the fact that utilization is more efficient to satisfy the needs of a wider user base, and leverage the reduced need for manual lab configuration to enable remote users to take advantage of lab resources. The key process areas are:

Organizational Efficiency – The goal of this process area is to extend the benefits of lab management to the entire corporate organization. Assets previously tied to a particular individual user or small group can now be shared the entire company.

Distributed Utilization – With automated procedures in place to manage assets, being physically located near the asset is no longer a barrier to utilization. Instead of maintaining multiple labs with redundant equipment to server geographically distributed users, resources can be made available remotely.

Automation Reusability – With well-defined assets in the lab management database, automation can be developed that is applicable in all topologies and use cases. It can be consumed by anyone in the organization to achieve their own goals.

The key process areas of Level 5 focus on making lab assets available as a corporate asset, enabling effective collaboration with outside customers and partners. The key process areas are:

Utilization Metrics – Beyond simply analyzing asset usage for the purpose of efficiency and capital expenditure planning, detailed metrics are needed to keep track of usage by outside users. When allowing access to outside customer and partners, it is necessary to provide them with useful information about their own usage, especially if there is cost associated with that usage.

External Coordination – Processes and tools need to be developed to coordinate with these outside collaborators. This can include sharing of topologies, access controls to lab equipment, and providing means for the customers and partners to access the equipment. These processes can speed test and development as test configurations can be shared and issues can be reproduces efficiently.

Lab as a Service – By having processes that tightly control the configuration of and access to lab resources, an organization can become a provider of those resources via self-service means.

Key Process Areas – Maturity Level 4

Key Process Areas – Maturity Level 5

2.3

2.4

Lab Maturity Model10

KeyPractices3

Maturity Level 2 Key Practices3.1

The goal of Asset Tracking is to improve lab resource sharing by providing managers and lab users awareness of those resources. This is accomplished by maintaining a searchable and updatable repository of all resources that includes the ability to define fields that contain data relevant to users to help search for equipment that meets their needs (“attributes”) as well as indications of ownership and availability. Processes to populate this repository initially, expand it as new resources are acquired, and keep attribute and availability data up to date need to be defined.

Goal 1 – Current resource inventory is known, recorded, and available for search

Goal 2 – Changes to inventory and status of that inventory are tracked accurately and with a timely process

Ability 1 – Tools are available to facilitate the population and maintenance of repository data

For a smaller organization, this could be as simple as a spreadsheet listing resources, attributes, and ownership. For larger organizations, a database-driven tool with and advanced user interface to facilitate sharing and usability would likely be required.

Ability 2 – Responsibility for maintaining the repository is established.

Can be the responsibility of individual users to keep information up to date on resources they are utilizing, an individual or team may have responsibility for all resources.

KPA: Asset Tracking

Goals

Ability to Perform

For each Maturity Level, the Key Process Areas (KPAs) can be achieved by implementing a set of Key Practices (KPs). The KPs are defined as a collection of common features of the KPAs.

Goals – High level description of the technical business goals the KPA is meant to help achieve.

Ability to Perform – A description of organizational prerequisites that must be in place to implement the KPA that may not be covered by other parts of the LMM

Activities Performed – Specific activities that directly address the goals of the KPA.


Activity 2 – Initial population of repository.

One time effort to capture current state of lab asset inventory and attributes

After population, accuracy and usability validated by users

Activity 3 – Lab users interface with the repository to determine available resources and indicate resource usage

Either manually or using tools associated with the chosen repository solution

Defined process for indicating current usage.

Activity 4 – Updates made to repository

Non-static attributes are updated in the repository

New resources added to the repository

Out of date resources removed from repository (or indicated in the repository to maintain historical data)

To maximize sharability of resources, process must be in place to ensure that competition for scarce resources is quickly and correctly resolved. This is accomplished by maintaining accurate and up to date information about resource usage, both current and planned. There are two views of this availability. If the need is for a specific resource, the need is to view when the resource is available. If the need is for a specific use time, the need is to view what resources are available at that time. In cases when there is no clear resolution to the conflict, priority decisions must be made based on business rules.

KPA: Conflict Resolution

Goal 1 – Maximize resource utilization by avoiding resource usage conflicts caused by lack of understanding of resource availability

Goal 2 – Ensure business requirements are met by applying priorities to conflict scenarios.

Ability 1 – Given a specific resource(s), the ability to find when the resource(s) is/are available.

Ability 2 – Given a specific time, the ability to identify resource(s) available for that time.

Ability 3 – In case of unresolvable conflict, access to a method of applying business priorities.

For example, a defined process for escalating to management to make the priority decision, or reference to project priorities previously communicated by management.

Goals

Ability to Perform

Activity 1 – Relevant resource attributes are agreed on.

Attributes that will be required by users to identify relevant equipment for their needs will be identified.

Must have agreement from all affected users/groups.

Different users may require different attributes.

Must agree on minimum set of attributes that satisfy the needs of all users

Activities Performed


Activity 1 – Users refer to availability data from resource repository when planning activities that require access to shared resources

Activity 2 – Availability data, current and future, is maintained in the repository.


Once inventory is understood and documented in the repository, the goal is to use that inventory as efficiently as possible. This means being able to identify resources that may be sitting idle that could fulfill needs. It also means only using resources when absolutely necessary (e.g. if a piece of equipment is not in use, it can be powered off).

Resource abstraction drives Utilization Efficiency. In planning future resource utilization, availability should be determined by resources that conditionally match sets of attributes, rather than by specific resources. The goal is to prevent conflict and improve efficiency by expanding usage beyond specific resources known to users, opening the entire known inventory to use.

KPA: Utilization Efficiency

KPA: Resource Abstraction

Goal 1 – Avoid project bottlenecks by when usable resources are available

Goal 2 – Minimize wasteful idle time of resources

Goal 1 – Ensure projects are not held up due to conflict on a specific piece of equipment when other resources meet needs

Ability 1 – Users are provided with resource requirements that allow identification of all relevant resources.

Resource requirements are provided in terms of attributes not specifics

Ability 1 – Access to repository with complete, accurate, and current attribute information.

Ability 2 – Ability to correlate planned resource utilization by attributes and determine overall resource availability based on those plans

Activity 1 – Users use attributes to identify available resources for project

Goals

Goals

Ability to Perform

Ability to Perform

Activities


Activity 1 – When applicable, users determine availability and plan future usage based on sets of attribute values, not specific resources.


In addition to using existing assets as efficiently as possible, future asset acquisition should be done efficiently and effectively as well. The goal is to strike a balance between populating a lab with enough resources to satisfy all project needs without buying extra equipment that goes unused.

Sharing lab resources introduces a level of inefficiency. No longer in control of their own equipment, users may receive resources for use in unknown states, adding effort to reconfigure and setup the resources before work can begin. The goal of this KPA is to reduce and standardize that effort.

Goals

Goal 1 – Reduce time and effort to reconfigure resources before productive use

Goal 2 – Standardize configuration needs across projects and utilization

KPA: Capital Planning

Goal 1 – Reduce capital expenditure by purchasing only enough equipment to satisfy project needs

Goal 2 – Reduce project bottlenecks by acquiring enough scarce resources

Ability 1 – Extract from the resource repository information about classes of equipment that is not in high use.

Ability 2 – Extract from the resource repository information about classes of equipment that has a high rate of conflict.

Activity 1 – Generate reports that indicate high and low usage resources.

Activity 2 – Correlate usage reports with upcoming project plans and resource requirements to determine purchasing needs.

Goals

Ability to Perform



KPA: Process Efficiency


Ability to Perform

Ability 1 – Must have consistent definitions of resource configurations and access to standard configuration data (e.g. software, configuration files, firmware)

Ability 2 – Automated methods of configuring resources, including command line utilities and APIs

Ability 3 – Maintenance of standard configuration data as project needs are updated


Activity 1 - Begin all utilization activities with a standard configuration procedure.

Project definitions are written with the assumption that activities will begin from this standard configuration.

Activity 2 – Complete utilization activities with standard cleanup procedure that ensures configuration procedure can be executed on next use.

Activity 3 – Projects are defined using standard configurations to ensure applicability of the existing procedures

KPA: Process IntegrationWith the increased need for reconfiguring resources between use, it’s important to reduce the overhead of tool use. The more that these steps can be done from a single location, the more efficient the process will be. Integrating everything into a single (or a small number) process will also ensure more consistency in results.

Goals

Goal 1 – Maintain configuration process efficiency by reducing number of different tools need

Goal 2 – Increase process consistency by managing everything through a single process

Ability to Perform

Ability 1 – Access to a tool that is able to perform a variety of configuration activities through a single interface

Ability 2 – Customize and extend configuration processes through the single tool/interface as new configurations become necessary or new resources are added to requirements.


Activity 1 – Configuration tools made accessible from a single integration tool

Can be simply access to an interface where manual configuration can be performed, or automated procedures that can be initiated from the integration tool

Activity 2 – Configuration steps are performed from within the integration tool when possible, avoiding access from outside the tool where it would cause instability or inefficiency


KPA: Test AutomationWith consistent resource configurations, an accurate repository of resource attributes, and integration of resource configuration tools, test automation can be accomplished in a repeatable, sharable way.

Goals

Goal 1 – Increase test coverage through more efficient reconfiguration of test resourcesGoal 2 – Reduce manual effort to execute test plansGoal 3 – Reduce effort of script sharing and reuse by standardizing scripts and using dynamic inputs

Ability to Perform

Ability 1 – Access to automation tools that can utilize the resource repository information and con-figuration abilities to perform automated testingAbility 2 – Expertise in the organization in creating automation


Activity 1 – Automation tests written based on known standard configurations.At this level, automated tests and procedures may still be limited in use to a specific project or class of projects.

KPA: Test ReportingWith tests automated and running on consistent configurations, results can be accurately reported with relevant and accurate information.

Goals

Goal 1 – Improve test report accuracy by automatically collecting test configuration and result data

Ability to Perform

Ability 1 – Store test result information with meta data that allows meaningful retrievalAbility 2 – Access to definition of required reporting meta data


Activity 1 – Tests are written to collect relevant result data and store with test results.



KPA: Organizational EfficiencyWith lab assets tracked, configuration standardized, and processes consolidated, assets can be shared with different parts of an organization. The efficiency gained within a single group can be shared across multiple groups.

Goals

Goal 1 – Reduce overall corporate spending by allowing access by multiple groups to resources previously tied to a single group.Goal 2 – Improve information sharing between linked groups.For example, a test organization can provide access to their resource and configurations by a development group to reproduce a discovered bug. Previously the development groups may have had to identify their own resources and try to recreate the configuration manually.

Ability to Perform

Ability 1 – Allow access to lab management tools to other groups within the organization


Activity 1 – Users external to the group that owns the resources are created and given access.Activity 2 – External users are provided training on how to access the resources and apply the standard configuration steps

KPA: Distributed UtilizationPrior to this level of maturity most organizations are concerned with managing resource utilization by users in the same location as the resources. With no automation or standard configuration methods, physical access to the equipment can be regularly required. Now with those in place, access can be expanded to geographically distributed users.

Goals

Goal 1 – Flexibility to expand organizational activities beyond a single physical location

Ability to Perform

Ability 1 – Method for remote access to resourcesAbility 2 – Consistent and complete configuration procedures that do not require physical equipment access, or require very limited physical equipment access that can be performed quickly and efficiently by a local tech.


Activity 1 – Remote users use the existing tools to perform all of the same operations available to local users.


KPA: Automation ReusabilityWith experience in creating automation and an understanding of the needs, test automation can be expanded beyond tests written for specific projects or purposes. Reusable tests and utilities can be written generically, aware of their environment based on information from the resource repository.

Goals

Goal 1 – Reduce test authoring effort by maintaining a library of reusable utilities that can be easily combined to create tests for any project.

Ability to Perform

Ability 1 – Sharing of test assets Ability 2 – Standardization of test definitions across projects


Activity 1 – Creation of common automated procedures used by most/all testsActivity 2 – Development of standard test creation procedures that make use of existing procedures


KPA: Utilization MetricsAt lower maturity levels, understanding of utilization was limited to short term snapshots of utilization and geared toward understanding internal usage patterns. With true metrics, long term trends can be analyzed, as well as tracking usage by outside organizations. This is particularly important in the case when the outside users are not just other groups within the corporation, but true external users who may be customers.

Goals

Goal 1 – Provide users of lab resources with accurate and useful usage reportingGoal 2 – Maintain an accurate record of use by both internal and external users

Ability to Perform

Ability 1 – Access to historical, current, and future utilization dataAbility 2 – Ability to distinguish internal from external usageAbility 3 – Ability to distinguish usage between different classes of resources


Activity 1 – Reports designed to provide relevant and accurate dataActivity 2 – Users notified of usage events and aggregate data


KPA: External CoordinationExternal users may have different needs than internal users of lab resources. Simply accessing the same standard tools may not be sufficient for an external user. A fully strategic lab will have the ability to present different views of the lab and resources to different users.

Goals

Goal 1 – Provide a different level of access and control to different classes of users based on permission and need

Ability to Perform

Ability 1 – Lab management tool must be extensible, with the ability to be controlled by a variety of access methods (e.g., web interfaces, API calls)


Activity 1 – Custom interfaces are developed to satisfy the needs of different classes of usersActivity 2 – Custom configuration procedures are developed to satisfy the needs of different classes of users

KPA: Lab as a Service (LaaS)Once fully managed, optimized, automated, and accessible, the lab itself can become a product to be made available externally.

Goals

Goal 1 – Utilize organization assets to meet business goals in coordinating with external customers, either as a source of revenue or a source of increased collaboration

Ability to Perform

Ability 1 – Provide professional, consistent method of accessing and interacting with lab resources


Activity 1 – Lab resources are marketed as a commodity accessible by external customers and partnersActivity 2 – Usage statistics are utilized to provide cost models for customersActivity 3 – Internal users provide support for external usagelocal users.


References4http://www.sqi.griffith.edu.au/CMM/TR25/tr25_o2.html

http://aelinik.free.fr/cmm/tr25_o2.html

http://www.smartmatix.com/Resources/CMMIexplained/KeyProcessAreasKPAs.aspx

http://www.tutorialspoint.com/cmmi/cmmi-process-areas.htm

http://itcoolguy.wordpress.com/2008/05/30/process-areas-for-cmm/

http://www.sei.cmu.edu/reports/93tr025.pdf

http://www.qualisystems.com/white_papers/the-lab-maturity-model/

http://www.aricent.com/industries/network-equipment-manufacturers.html

WP-LM

M-1

Lab Maturity Model - quali.com€¦ · Lab Maturity Model By Gregory Sloan, Sr. Field Solutions...

Documents

Transcript of Lab Maturity Model - quali.com€¦ · Lab Maturity Model By Gregory Sloan, Sr. Field Solutions...