Process Definition Continuum

An earlier post on this blog titled Process Tailoring, Process Deviation, Process Exception, Approval and Waiver dwelt upon concepts such as tailoring, deviation, exception, approval and waiver in relation to the defined process that gets used for performing any work.

In light of that, it can very well be said that process definition in the real sense happens over a wide continuum starting from standard process getting used to a situation of "no process".

As an aside, an important one though, it needs to be clearly understood that "no process" does not mean no process is being used but that their is no agreed/common/consistent process in place that is getting used.

• Everyone is on their own and supposed to deliver their piece
• Work would seemingly happen but their is no assurance about what exactly will be coming out of that work at the end of it, if the work even reaches its end ever!
• There will be a lot of friction between the manager and the team, between the team members and between various sub-teams engaged in that work
• There will rise out of the ashes some "heroes" who may happen to save the day, but only in certain instances and that too after they and the others would have undergone severe burn-out

Clear understanding of the continuum concept is necessary to ensure a systematic and structured approach is firmly put in place while following the standard processes or the variations thereof.

The continuum view of process definition also implies that the process definition that is finally put into use is the one that happens at the granular level.

The granular level process would get captured as part of the project management plan, service delivery plan, product management plan, etc.

And even if localized processes are used or the "no process" type of process is used, there is still an overall governance layer to take care of deviations as also the exceptions.

The big thought here is that there is a well-defined process in place for handling any situation, including that of the situation of "no process" too!

The following figure presents the process definition continuum illustrating the different levels at which process definition at the project plan level would typically play out.

 

Here are the four levels in which the process definition continuum can be categorized into.

ORGANIZATION’S STANDARD PROCESS

• Ideally speaking, standard process should be followed by every project.
• This will enable meaningful comparison of performance across different projects in the organization.

PROCESS TAILORING

• There are situations, where a project would require that it be allowed specified variation over the standard process without the need for any approval.
• Such variations should get included in the tailoring guidelines and govern any process tailoring.

PROCESS DEVIATION

• Then there are situations, which should be infrequent, where a project would follow an applicable process but in a manner that is different than the standard process as well as the tailoring guidelines.
• Such case-specific process deviation should get approved and waived-off by the topmost authorities accountable for process and delivery outcomes of the organization.

PROCESS EXCEPTION

• And lastly, there are situations, which should ideally be rare, where a project would work with no basis in standard process, process tailoring or process deviation. 
• Such process exception (either to few or all applicable processes) should get approved and waived-off by the topmost authority accountable for business outcomes of the organization. 

CMMI V2.0 - Services View

CMMI 2.0 or version 2.0 came into being with the release of the Development view in March 2018.

This was closely followed by the subsequent release of the Services and Supplier Management views in December 2018.

This post is exclusively focused upon the Services view of CMMI V2.0 model.

It provides high level description of the four practice areas that come under the "Services" category.

• Strategic Service Management (STSM) - what services to provide?
• Service Delivery Management (SDM) - how to ensure delivery of selected services?
• Incident Resolution and Prevention (IRP) - how to ensure smooth service delivery?
• Continuity (CONT) - how to ensure disruption-free service delivery?

 
The above four practice areas are described in a more detailed manner in the following sections of this post.

Strategic Service Management (STSM)

STSM relates to designing, developing and deploying new or upgraded services. It also conceptually relates to decisions regarding downsizing or discontinuing of services that are in operation.

The key point here is ensuring there is deep and strategic connect of the service offerings with the business objectives, needs and directions.

Key elements that need consideration in this practice area include:

• Creating and maintaining a service catalogue that lists down all types of service offerings with different levels of support (like standard, premium)
• An example of this could be a bank offering different facilities/services like ATM, lockers, teller, FD opening/closure, etc.
• Again, there could be different SLAs/levels of the above services based upon customer types like regular. privilege, etc.
• Creating and maintaining the SOP for providing the services with detailed description of the work flow
• Creating and maintaining the SOP for introducing a new or upgraded service and also for downsizing or discontinuing an existing service
• Analyzing the services portfolio to keep it aligned with the business objectives, needs and directions of the organization.
• An example of this could be a bank offering new facilities/services in the branch operating in a specific locality based upon that locality's unique characteristics.
• Again, the bank can discontinue certain services in the branch operating in a specific locality including even shutting down the branch (which essentially means all services get discontinued!)

Service Delivery Management (SDM)

STSM takes care of which services should be offered. SDM takes care of service delivery system to ensure services are delivered as planned.

SDM relates to the provisioning and delivery of the selected services. It also conceptually relates to decisions regarding enhancements, changes and improvements to the services that are in operation.

The key point here is ensuring there is clear operational connect of services with the service catalog and the SOPs for the services that are on offer.

Key elements that need consideration in this practice area include:

• Provide services (which essentially means handle incoming traffic of service requests/tickets) in line with SLAs or service performance contracts and includes services scope, service window (time/availability), SLA commitments, etc.
• Operate and maintain the end-to-end system for service delivery including introducing changes to enhance or improve the parameters related to effectiveness and efficiency.
• Analyze service performance to identify improvements in service delivery like cycle time reduction, response within SLA, resolution with SLA, SLA tightening, etc.
• Evaluate the suitability of service delivery system in terms of its capacity and its actual performance in catering to the incoming traffic of service requests (this would also feed into SSM for the top-level intervention at the service catalog level)

The workflow for handling service requests can follow a workflow similar to what gets used for handling an incident or issue as mentioned in the section below.

Incident Resolution and Prevention (IRP)

SDM takes care of the actual delivery of services on the ground. IRP ensures incidents and issues that  disrupt service delivery are addressed promptly to ensure high availability to the end-user of the services.

IRP relates to identification and resolution of incidents and issues that disrupt or degrade the delivered services and in selected cases investigate the underlying causes to prevent recurrence of certain incidents and issues.

The key point here is ensuring that any disruption of degradation in services is restored and the service operations brought back to normal state at the earliest so that services continue to be delivered in line with the SLA commitments.

Key elements that need consideration in this practice area include:

• Identification of incidents and issues (both in a reactive mode as well as anticipatory/proactive mode) that disrupt or degrade service delivery or may do so
• The definition of incident can be extended beyond issues or problems faced by an end-user to include requests regarding some help or query related to something where the user may have got stuck.
• The incidents, issues and user requests can be logged as service request or problem ticket or service issue or service ticket, etc.
• Logging and tracking the incidents and issues to their resolution and eventual closure
• Resolving incidents and issues in a systematic manner in accordance with the SOP for the same - this SOP should have steps like:
• analyzing the incident or issue
• classifying the incident or issue correctly
• assigning to the right team/personnel
• identifying the fix or workaround needed
• verifying that the proposed fix or workaround will actually resolve the incident or issue
• implementing the proposed fix and pushing that into production
• verifying the fix or workaround is actually working as was thought
• informing the concerned stakeholders and/or the requester that the incident or issue has been resolved
• obtaining concurrence of the requester that the incident or issue has indeed been resolved
• closing the service request or ticket
• Investigating the underlying causes of selected set of incidents or issues and take measures to prevent their recurrence either by eliminating them altogether or minimizing their frequency of occurrence - this is recommended in following situations:
• an incident is occurring very frequently or becomes a pain point for the end-users
• an incident is not occurring very frequently but has significant disruptive or degrading impact on the service delivery system
• an incident is not occurring very frequently but has end-users like the CEO, senior management whose down-time is pretty expensive

Continuity (CONT)

IRP takes care of resolving incidents and issues that disrupt or degrade the services being delivered by a service system.

CONT ensures mitigating measures or controls are put in place to reduce the likelihood of serious disruptions or catastrophic events that have severe impact on the availability or performance of the service system and also the overall business operations.

An example of this could be the outage of the web portal of an e-retailer!

CONT relates to identification and implementation of mitigation measures to avoid the occurrence of serious disruptions or catastrophic events during the operation of the service delivery system.

It also conceptually relates to the complete business operations which essentially means all services being delivered by the business.

This view has direct linkage with the business continuity and disaster recovery plan concept in the ISO 27001 standard as also ISO 22301 (ISO standard exclusively focused on business continuity management).

The key point here is ensuring some kind of FMEA (Failure Modes and Effects Analysis) or FTA (Fault Tree Analysis) is done on the service delivery system (or even the overall business operations) so as to identify and address, in a proactive manner, things that could go wrong.

Key elements that need consideration in this practice area include:

• Identification of the triggers that can lead to serious disruptions or catastrophic events
• Identification of the approaches to mitigate those triggers
• Implementation of the measures and controls in line with the selected approaches for mitigating the likelihood of the triggers
• At times, it may not be possible to influence the likelihood of a serious disruption or catastrophic event so in that case it is advisable to focus on reducing their impact should they happen (an example could be floods in an area where nothing can be done on the likelihood part but a better building design would lessen the impact)
• In addition to mitigation plan, there should be a contingency plan which would state what will be done should any serious disruptions or catastrophic event were to occur
• Preparation of a continuity plan for service operations which should include
• List of functions and services that are essential to ensure continuity of operations
• The sequence of restoration, RPO (recovery point objective) and RTO (recovery time objective)
• Period verification and validation of the continuity plan which should include
• Training of the staff involved in ensuring continuity as well as recovery and restoration after the occurrence of any serious disruption or catastrophic event
• The trained staff should be fully aware of the contingency measures as documented in the continuity plan
• There should be periodic testing of the continuity plan to ensure the plan would "go right" when it needs to be invoked and this is important because it will be a situation of real crisis when it would need to be invoked, if ever