Introduction

Service Validation and Testing ensures that deployed releases and the resulting services meet customer expectations, and to verify that IT operations can support new services. Service Validation and Testing defines the testing of services during the Service Transition phase.  This will ensure that new or changed services are fit for purpose (this is known as utility) and fit for use (this is known as warranty).

Service Validation and Testing’s goal is to make sure the delivery of activities adds value that is agreed and expected.  If testing hasn’t been carried out properly, additional Incidents and Problems will arise.

Activities in Service validation and testing

There are a number of activities for Service Validation and Testing, these include:

Validation and Test Management

Service Validation and test management are crucial components of the software development life cycle. They ensure that software applications meet the desired quality standards and are free from defects. The validation phase involves evaluating the software against user requirements and specifications to determine its correctness and fitness for purpose. This process includes activities like requirement validation, design validation, and user acceptance testing. Test management, on the other hand, focuses on planning, organizing, and controlling the testing activities throughout the development process.

In validation and test management, a systematic approach is essential to ensure thorough coverage and effective testing. This involves creating test plans, defining test cases, and executing them to uncover defects and verify the software’s functionality. The test management process includes activities like test prioritization, resource allocation, test execution tracking, and defect management. It also involves collaborating with different stakeholders, such as developers, business analysts, and end-users, to ensure clear communication and alignment of objectives.

Proper validation and test management contribute to the overall success of software projects. They help in identifying and addressing issues early in the development cycle, reducing the risk of costly errors in the final product. Through effective test management, organizations can ensure comprehensive testing coverage, improve the quality of their software, and enhance customer satisfaction. By incorporating best practices, such as test automation, continuous integration, and regular reviews, validation and test management can streamline the testing process and deliver robust and reliable software solutions.

Test Planning and design

Test planning and design for Service Validation are crucial in the software testing process that lay the foundation for successful testing. Test planning involves determining the scope, objectives, and approach of the testing activities. It includes identifying the test requirements, defining the test strategy, and creating a comprehensive test plan. Test planning also involves resource allocation, scheduling, and budgeting to ensure efficient and effective testing. The test plan serves as a roadmap for the testing team, outlining the testing activities, deliverables, and timelines.

Test design, on the other hand, focuses on creating detailed test cases and test scenarios based on the requirements and specifications of the software. It involves breaking down the system into smaller components and designing tests that target specific functionalities or features. Test design requires a clear understanding of the system’s architecture and behavior to ensure that all critical and high-risk areas are adequately covered. This phase also involves designing test data, selecting test techniques, and prioritizing test cases to maximize test coverage within the given constraints.

Both test planning and design are iterative processes that require collaboration between the testing team, developers, and stakeholders. They require careful analysis and consideration of the system’s requirements, risks, and dependencies to ensure comprehensive testing coverage. Well-planned and well-designed tests contribute to the overall effectiveness of the testing process by identifying defects early and providing valuable feedback for improvement.

Sample Test Scenario Template

Creating test scenarios for unit, system and integration testing forms part of the test strategy. Let us look at one of the templates (here is the Integration testing template).

Verification of Test Plan and Design

Verification of the test plan and design ensures the completeness, accuracy, and effectiveness of the test plan and design documents. It involves a thorough review and evaluation of the test plan and design to validate that they meet the specified requirements and objectives. During this verification process, stakeholders and experts assess the clarity and consistency of the test plan and design, checking if they align with the project’s goals, scope, and available resources. By conducting a rigorous verification, organizations can identify any gaps, ambiguities, or potential issues early on, allowing for necessary refinements and improvements to be made before the actual testing phase begins.

Prepare and create a baseline for the test environment

Preparing and creating a baseline of the test environment involves capturing and documenting the initial state of the environment to establish a reference point for future testing activities. Here are the steps involved in preparing and making a baseline of your test environment:

1. Define the baseline criteria: Determine the specific elements and components that need to be included in the baseline. This can include hardware configurations, software versions, network settings, databases, and any other relevant components that make up the test environment.
2. Set up the initial environment: Create the initial test environment by installing the required software, configuring hardware, setting up networks, and deploying any necessary infrastructure components. Ensure that the environment closely resembles the production environment or the target environment for testing.
3. Document the baseline: Document all the relevant information about the initial state of the environment. This can include detailed hardware specifications, software versions, network configurations, database schemas, and any other relevant settings or configurations. Take screenshots, capture system logs, and record any specific details that are essential for replicating the baseline in the future.
4. Establish version control: Use version control tools or mechanisms to manage and track changes to the test environment. This helps maintain a record of any modifications or updates made to the baseline over time and allows for easy rollback or reference to previous states if needed.
5. Validate the baseline: Verify the baseline environment to ensure that it accurately represents the desired initial state for testing. Validate that all the required components are properly installed, configured, and functioning as expected. This can involve conducting basic tests or checks to confirm the integrity of the baseline.
6. Secure and protect the baseline: Take measures to secure and protect the baseline from unauthorized changes or modifications. Implement access controls, backups, and other security measures to ensure the integrity and availability of the baseline environment.

Cleanup and Closure of the test environment

During the cleanup process, all test data, files, and databases used during the testing phase are securely deleted or archived, ensuring that sensitive information is properly handled and protected. Test configurations, settings, and environment variables are reset to their initial values, ensuring that the environment is free from any test-specific configurations that might interfere with production operations. Additionally, any temporary resources or virtual machines that were set up for testing purposes are decommissioned or removed to optimize resource utilization.

Closure of the test environment involves documenting the test results, issues, and lessons learned during the testing process. Test reports, defect logs, and any other relevant documentation are compiled and stored for future reference or audit purposes. It is also important to communicate the closure of the test environment to the relevant stakeholders, such as project managers, developers, and other members of the testing team. This ensures that everyone is aware that the testing phase has concluded and that the environment is ready for the next phase or project.

Authored by Vijay Chander – All rights reserved – 2023

The post Steps to follow for Service Validation and Testing first appeared on TekTalk | Project Management Process Tool.

The post Steps to follow for Service Validation and Testing appeared first on TekTalk | Project Management Process Tool.

Introduction

Often your organization has the opportunity to work with customers to manage and provide cloud managed services transition as an extension of their own internal IT. Here in this blog, we will go through the various stages of taking over those responsibilities, and how to plan and phase it in. This is a kickoff deck that you walk over with your customer. TekTalk is the service provider here!

Typically, these are the 4 major areas we deal with:

1. Define Scope of Services
2. Build a Transition Plan
3. Describe the Support Model
4. Resource Plan
5. Governance Model

Scope of Services

 Cloud Support

• Cloud network, VM monitoring
• Cloud service management console
• Cloud Vendor interfacing
• Alert setup
• Automated custom monitoring
• Identity management

Database Management (DBMS)

• Database Administration
• Backup and Recovery
• Patching
• Database monitoring using OEM/OMC
• Database clone/refresh
• Database security
• CPU scaling

Disaster Recovery (DR)

• Monitor stand-by database
• Support failover testing
• Oracle data guard management
• File system replication
• Patching

Infrastructure Support (IaaS)

• Infrastructure as a code
• Quarterly Patching
• Infrastructure support
• VM management
• Storage management
• Proactive monitoring for infrastructure
• Load balancer configurations

Apart from this you would have the specific application software, Example Oracle E-Business Suite or SAP ERP. An Example of the services you provide for Oracle EBS is listed:

• Application and security patching with little to no downtime
• Cloning and refresh
• Concurrent processing setup and monitoring
• Support month-end and year-end processing
• Workflow monitoring
• SLA management
• Application DMZ/external setup
• EBS load balance configuration
• Oracle Enterprise Manager setup and monitoring for EBS
• Health check and assessment
• Apply automation for monitoring
• Performance Monitoring
• Log monitoring

Build a Transition Plan

Here is a simple diagram to showcase your Transition Plan. You may add wordings, however the diagram is self-explanatory.

Transition showcasing People Process and tools

Build a sample timeline. Below is one I have built earlier that you can use as a guideline and build your own.

An example of Cloud Managed services timeline

Support Model

There are two important components for the support model

The first is the Incident Management Flow for the specific customer. Here is a sample flow:

You can use your own escalation management flow of your own organization. Apart from the escalation flow, you can also add the following diagram for Escalation Process. You may want to change the wording here, based on what you would like to present to the customer and how comfortable both of you are with it.

Resource Plan

Describe your resources and hierarchy.

Cloud managed services transition resource team

Governance

Emphasize on the following items:

• Regular status meetings between customer and OD teams (Weekly)
• Monthly Business review
• Quarterly Business Reviews with Executive Sponsors
• Provide and discuss key statistics/risks/Mitigation
• Responsibilities fixed to team resources (TekTalk and Customer)
• Regular communications
• Suggest improvements/enhancements

Show your potential graphical reports that you plan to submit on a periodic basic. Add your own.

This way you can create a professional deck to present on your Kickoff meeting to keep everyone impressed. You can always improve on this by adding additional information.

Authored by Vijay Chander – All rights Reserved – 2023

The post How to Build a professional Kickoff Deck for Cloud MS Transition first appeared on TekTalk | Project Management Process Tool.

The post How to Build a professional Kickoff Deck for Cloud MS Transition appeared first on TekTalk | Project Management Process Tool.

Background

In the topic “Identify and Record Critical Incidents”, closure forms an important part of the complete process. This is in addition to my previous blogs I have written about Phase I, II and III which deal with Identification and Recording, Investigation and Diagnosis and Resolution and Recovery. This blog continues with Closure that is equally important to close the loop.

We use the RACI to assign responsibility to the following personnel or groups.

Incident Manager/IT Operations
Support Group

Process flow for Closure

 

1. The The Major Incident Manager, Incident Manager or Support Group confirms with the user that the incident has been resolved. At this stage the incident is ready to be resolved.

CI	RA

2. Following the confirmation of the satisfactory resolution of the incident the status is updated. The incident status is set to resolve.

CI	RA

3. The decision is taken if a solution is available. The Known error database is reviewed and an appropriate Known Error is located. If the answer is yes, proceed to step 7) or if the answer is no proceed to step 4).

CI	RA

4. A decision is that there is no solution available. We figure out if it can be resolved with a Root Cause Fix. We check to see if the root cause of the underlying problem addressed during the incident lifecycle. If the answer is yes we proceed to step 6) and if not proceed to step 5).

CI	RA

5. If the root cause of the Underlying problem was not addressed during the incident; a) A Problem record is to be raised to identify root cause (where not known) and b) A known error is to be raised where a temporary work-around or a permanent solution has been identified. A Problem or a known error record is raised.

CI	RA

6. At this stage there are three possible decisions. a) A solution is available b) Resolved with a Root Cause Fix c) Problem or Known error record raised. A Valid Problem record or a known error record is raised and linked to the Incident and the Incident is closed.

CI	RA

7. The incident is linked to the appropriate Known Error record within the service management tool. The incident is closed.

CI	RA

Authored by Vijay Chander – All rights reserved – 2023

The post How to Identify and Record Critical Incidents – Phase IV first appeared on TekTalk | Project Management Process Tool.

The post How to Identify and Record Critical Incidents – Phase IV appeared first on TekTalk | Project Management Process Tool.

Background

Resolution and Recovery of Critical Incidents is a continuation of the previous blogs I have written about Phase I and Phase II which deal with Identification and Recording, and Investigation and Diagnosis. Understanding the previous blogs makes reading this blog easier as it is a continuation, I would recommend you to read them first.

We use the RACI to assign responsibility to the following personnel or groups.

Technical Restoration Manager
Incident Manager/IT Operations
Support Group

Process flow for Resolution and Recovery of critical incidents

1. The Technical Restoration Manager reviews the proposed recovery activities to determine if a Technology change is required. This activity is to confirm if Change is required.

RA	I	CI

2. A decision is made that service restoration activities must be progressing through the implementation of a Change. (a) If Yes, go to step 3 (b) If No, go to step 7.

RA	I	CI

3. A decision regarding the type of change is made based upon the Change Management Procedure and the Change Management Process Policy.
(a) If Latent, go to step 4
(b) If Emergency, go to step 6

A	CI	CI

4. Change activity is reviewed and a Latent Change created to document historic change activities. The decision is that the change is Latent in nature.

A	R	CI

5. Either a Latent Change is created OR Emergency Change created. The Change Management process is engaged to manage the lifecycle of all Technology Change activity.

CI	A	R

6. Emergency Change created. The Change Management process is engaged to manage the lifecycle of all Technology Change activity. Restoration activities are reviewed with an Emergency Change created to restore or protect service.

CI	CI	RA

7. The Support Group verify that a temporary work around or solution can be applied without the need for a change – while meeting the requirements of the Change Management Process Policy. The process moves to closure of the incident.

Additional Tasks to be performed

i) Following service restoration All Major Incident Bridges are closed.

ii) The Problem Management process commences, through: 1) The creation of a Problem Record where root cause is not known. 2) Linking the Incident to an existing Problem Record where appropriate. 3) Creating a Known Error record where root cause has been identified. 4) Linking the Incident to an existing Known Error record where appropriate.

iii) The Major Incident Manager reviews the Incident criteria against the Incident Review entry criteria. Upon review; (a) If a review is required go to step (iv) (b) If a review is not required go to step (v).

iv) The Major Incident Manager initiates an Incident Review following the resolution of the incident. A completed Incident Review distributed to agreed recipients within the scheduled timeframe agreed upon.

v) The Major Incident Manager reviews the Incident criteria against the Major Incident Review entry criteria. Upon review; (a) If a Major Incident Review is required go to step (vi) (b) If a Major Incident Review is not required the process ends.

vi) The Major Incident Manager initiates a Major Incident Review following the resolution of the incident. A completed Major Incident Review distributed to agreed recipients within the scheduled time-frame.

Authored by Vijay Chander – All rights reserved – 2023

The post How to Identify and Record Critical Incidents – Phase III first appeared on TekTalk | Project Management Process Tool.

The post How to Identify and Record Critical Incidents – Phase III appeared first on TekTalk | Project Management Process Tool.

In the continuing series, I am talking here about the Investigation and Diagnosis of a Critical incident. In the earlier edition, I have talked about Identification and Recording. You can read that blog here.


We will also examine the various roles and how they play out in reference to RACI.
With that let us look at the various roles that come into play here.


Service Desk Analyst
Major Incident Group
Major Incident Manager
Technical Restoration Manager
IT Operations Manager
Incident Manager / IT Operations

1. The activity is classified as High/Critical incident. The Service Desk Analyst reviews the Impact and Urgency of the incident in accordance with the your Manage Technology Incident Prioritization process.

RA	I		C	C	C

2. The incident is reviewed. The incident manager reviews the critical incident. This is a process in this stage.

RA	I		C	C	I

3. Is the resolution or a work around found? The Incident Manager looks for an appropriate resolution or work around. This will generally include referencing; a) Job Docs b) Incident Response Plans. All recovery activities completed during this phase must comply with Change Management Process Policy.

	C		C	C	RA

4. A work around or resolution was found and now can proceed to resolve the incident. The Incident manager proceeds to implement to resolution or workaround.

	C		CI	CI	RA

5. If the decision was that a resolution or workaround was not found, the support groups have to be engaged. The Incident Manager contacts the appropriate support groups to assist in the incident resolution. This includes all the internal technology groups and support partners/vendors.

	CI			CI	RA

6. The criticality is now decided. The decisions are if the incident is a Critical Priority or a High Priority. We are dealing with Critical Priority items only here.

	C			C	RA

7. The Major Incident Manager is engaged. After confirming the Critical Incident the Incident Manager engages the Major Incident Management team to manage recovery activities.

			I	I	RA

8. The Major Incident Manager now decides if the priority is Critical or Non-Critical.

	C		RA	C	C

9. The Incident Manager engages the Major Incident Manager to drive the resolution of the Critical Incident. The decision was that the restoration target was breached. The Major Incident Group bridge is held with relevant information and decisions interfacing into the Major Incident Communications Procedure. This is an ongoing activity that is executed throughout the lifecycle of the incident. This bridge is established only when the resolution or workaround was not found.

		RC	RA	RC	I

10. Attend Technical Group Bridge, Engage & Disengage Support Teams as Required (continuous to restoration confirmation). The Technical Group Bridge is held with relevant information and decisions delivered to both the Major Incident Group and the Major Incident Communications procedure. This is an ongoing activity that is executed throughout the lifecycle of the incident. Now at this stage the incident is diagnosed.

			A	RC	C

11. Now that the incident is diagnosed, the technical Restoration Manager establishes a recovery plan to restore service and the restoration plan is established.

			A	RC	C

12. The support groups are now engaged to assist with a) Establishing a restoration plan b) Identifying Tasks c) Executing Tasks.

	C		I	C	RA

13. The tasks are now assigned. Tasks are established (wherever applicable) and assigned to Support Groups and Technology Partners. Tasks are completed as documented.

	CR		CI	RA	I

14. Now that it has been identified as a Major Critical Incident, we need to move on to the next phase. Which is Resolution and recovery. The Major Critical Incident Communications procedure is executed throughout the lifecycle of the incident.

	C	I	RA	C	I

This ends the phase II of Investigation and Diagnosis. After this phase, the Major Critical Incident Communications procedure and Resolution and Recovery process is started. That is published in my next blog.

If you like this blog, check my other blogs on my site here.

Authored by Vijay Chander – All rights Reserved – 2023

The post How to Identify and Record Critical Incidents – Phase II first appeared on TekTalk | Project Management Process Tool.

The post How to Identify and Record Critical Incidents – Phase II appeared first on TekTalk | Project Management Process Tool.

The diagram describes the various phases in the life-cycle of a Major Critical Incidents. In this blog I will be delving into the First phase, which is the Identification and Recording of the Critical Incident.
Here is the flow chart for the Identification Process. I will also show how RACI plays an important role in designating responsibility. R=Required A=Accountable C=Consulted I=Informed.

– Service Desk Analyst – Support Group

1. A request is received. A User contacts the Service Desk to lodge a service request, seek information or record an incident. The is Responsible and Accountable.

2. The next activity is deciding what is the request type? The reviews the request – directing it to either the Service Request Management Process, or the Incident Management Process dependent upon respective entry criteria. Decision – The Request type is a Request / Query OR Decision – The Request type is an Incident. (a) If Request/Query, go to step 3 (b) If Incident, go to step 4. The is Responsible and Accountable.

3. Based upon the assessment of the initial request the records and lodges a service request within the service management system. This kicks off the Service Request Management module. The is Responsible and Accountable.

4. The verifies that the request is an incident and reviews the service management system for similar existing incidents. This after s/he confirms that the request type is an Incident. The is Responsible and Accountable.

5. The searches for duplicate incidents. (a) If Yes, go to step 6 (b) If No, go to step 7. S/he takes a decision – The Incident is a Duplicate OR Decision – The Incident is not a Duplicate. This is to check if this kind of incident already exists in the system. The is Responsible and Accountable.

6. The identifies a duplicate incident, using this information to gain a better understanding of both the impact and potential resolution requirements. If it is a duplicate, it is mapped to existing Incident which is already existing in the system. The is Responsible and Accountable.

7. The creates a new Incident recording required attributes based on the fact that it is not a duplicate. The is Responsible and Accountable. The is Informed.

8. The searches the knowledge base and completes incident matching activities within the Service Management tool. Now the incident is created. The is Responsible and Accountable.

9. The Service Desk Analyst references the Technology Incident Management (Incident Prioritization document) to asses both the Urgency and Impact of the incident. This provides the initial Priority assessment of the incident. Based on the findings the priority is assessed and set. At this stage the is still Responsible and Accountable.

10. The control now moves to the support group. The manually detects an incident, through observation, monitoring or other means that are available. If the Service desk analyst specifies that the incident is critical, they are notified immediately. The is Responsible and Accountable.

11. Automated monitoring detects the failure or potential failure of a component under management. This incident is detected typically by the Event Management process. The is Responsible and Accountable.

12. The , either manually or automatically, creates a new Incident recording and verifying all required attributes. The is Responsible and Accountable.

13. Now that the incident is created, the assigns and confirms the urgency and criticality of the incident. The assigns references the Technology Incident Management (Incident Prioritization document) to asses both the Urgency and Impact of the incident. This provides the initial Priority assessment of the incident and that it is a Critical Incident. The is Responsible and Accountable.

This concludes the Identification and Recording which is the phase I of the Major Incident Management Process. Please look out for my next phase shortly (Investigation and Diagnosis).

Authored by Vijay Chander – All rights Reserved – 2023

The post How to Identify and Record Major Critical Incidents? first appeared on TekTalk | Project Management Process Tool.

The post How to Identify and Record Major Critical Incidents? appeared first on TekTalk | Project Management Process Tool.

Introduction

Purpose

“Secure the IT Environment of customers” is part of Environment management, which describes the processes that is used to keep technical systems operational and facilitate new changes to the technology supporting the customer platform. Both technical and procedural mechanisms are in place to ensure that no undesired changes take effect and that quality of service remains at the highest level. This document clarifies what those mechanisms are and how they benefit the customer.

Scope

The first part of “Secure the IT Environment” is the scope. The following section describes the requirements for environment management as required for the Platform. It is limited to defining the key areas of interest around enterprise environment management and the strategic approach that will be taken to ensure that technical systems are updated and maintained according to the customer’s requirements. The following key activities for environment management:

• Manage Platform software licenses (including the provisioning of all licenses)
• Administer operational and analytical databases
• Ensure that all required security controls are in place for all components
• Perform shared software components resource capacity planning in accordance with the capacity planning processes
• Provision new shared software component capacity
• Provide Level 2/3 support for shared software components in accordance with the incident management process
• Plan and execute required Platform software component changes in accordance with the change and release management processes, including producing the release packages
• Maintain Platform software component configuration information in accordance with the configuration management process
• Proactively monitor all Platform software components in accordance with the event management and monitoring processes
• Identify patches and required upgrades including impact assessment
• Coordinate the schedule for and apply patches and upgrades to Platform software
• Maintain the configuration of the shared components to meet other service providers’ needs
• Provide technical expertise and support to service providers during design and leverage of Platform software components
• Provide and support Platform tools (e.g., Help Desk ticketing, document repository, testing tools)
• Provision new users and services on the shared components (e.g., when a service provider adds services you will have to update directories)
• Enable and support disaster recovery, including providing the capability to migrate an application and data from the DR Data Center back to the primary data center with minimum manual involvement
• Maintain all application administration shared services (code/configurations of enhanced IT operational capabilities that can be leveraged by all vendors)

Environments

The customer’s physical servers support multiple logical environments. Environments are divided into locations, categories, and tiers based on the environment’s needs. Understanding the environment helps to secure the IT environment with the necessary controls.

Environment Types

An environment’s type is based on the functionality needed. List out the following types that the project should support.

Environment Categories

Environment Tiers

The environments are tiered based on the overall project need of the environment. Below are the breakdowns of the environment tiers.

The following figure shows the migration path that allows changes to be moved from lower environments up to production. This is an important process that shows how to secure the IT environment, from Development to Production and UAT to Production.

Integration Workflows

You need to fill up the following business functions and their descriptions as provided with respect to integration workflows.

Instance strategy

Production Environment

The production environment (PRD01) consists of all application technology stack components (e.g., SOA, Adobe) for various applications. Each application component is supported by underlying infrastructure. These infrastructure elements, along with the related application components, comprise what is known as an instance. The production environment has several layers of application, middleware, and database technologies being used by both internal and external users.

Describe and showcase your diagram showing the different tiers: Client, Presentation, Application, Middleware and Data for both internal and external users. These are your Production Components.

Non-Production Environments

The non-production environments for eligibility assistance portal and customer employee portal each comprise all application technology stack components (e.g., SOA, Adobe). The technology components are shared across environments for most of the non-production environments. The current non-production environments are listed in the following table. A few examples are shown for you.

Additionally illustrate the future state of various environments running on the portals. Use various patterns and colors to represent environments that will be added or relocated. You can name it as “Future State of Environments by Technology Stack”.

Instance Management

Instances are defined by technology stack, environment, and component. Dedicated instances within eligibility assistance portal frequently utilize shared services within customer portal. Thus, when describing communication between multiple components and technology stacks it is advisable to use the eligibility assistance portal’s stack as the initial reference point. Instances are frequently changed to introduce new functionality or correct an existing issue. Once the desired outcome is achieved then the change is promoted to higher environments for various levels of testing.

Patching process

The patching process that keeps customer environments up to date is critical to the success of environment management. Both security and functional patches are implemented to keep the environments operational.

Critical patch updates are put into place on a monthly/quarterly basis and are aligned with vendor release dates. Security patches are put into place according to any potential vulnerabilities identified by scans. The affected environments are scanned after being patched to ensure that the vulnerability was mitigated successfully.

Backup and recovery

Data Availability Requirements

To secure the IT Environment, the production environments of the Platform supported are required to be 99.99% available outside of planned maintenance windows. Maintenance windows are required to improve application or infrastructure functionality and to address defects such as security vulnerabilities that necessitate a patch. Maintenance windows should not be used to facilitate regularly scheduled backups. The overall backup strategy for production environments must allow for all relevant data and applications to be backed up while the systems are online and operational.

While non-production environments do not have the same availability requirements as production environments, non-production environments are used by multiple application systems integrators for strategic development, testing, and support. Data availability issues can potentially impact the timeline of applications system integrator deliverables. Therefore, the backup strategy for the non-production environments must be very robust to minimize impact to any of them.

Data Loss Impact

For the production environments of the Platform supported, the impact of data loss is dependent on system components. For most production system components, the impact of data loss is substantial. Therefore, the backup and restore strategy must take in to account eliminating, or at the very least minimizing, the possibility of data loss. In addition, the production environment has a disaster recovery solution in place should an event take place that results in the unavailability of data or systems.

While data loss of the non-production environments is not as critical as the production environments, the impact would still be substantial given the 24×7 development/testing/support model of multiple applications systems integrators. Therefore, the backup strategy for non-production environments must be very robust to minimize the possibility of data loss impact to any of them.

Data Recovery Model

The data recovery model must be very flexible and robust for the production environments of the Platform. Overall, the data recovery model must to be consistent across all technical and functional components of the environment so that all systems needing recovery are recovered to a consistent representation of the overall functionality. For example, in the need for recovery of a database, any application data on file systems to support the same functional need must be recovered to a point in time consistent with when the database is recovered. Inconsistencies between the two (database and file system) impact the integrity of the application systems. The data recovery model used for the production environments of the Platform supports this consistency requirement. The same flexibility and robustness of the data recovery model is also necessary for the non-production environments given the 24×7 development/testing/support model of multiple applications systems integrators. This is one way to secure the IT Environment.

Data Restoration Process

A key element to secure the IT Environment, especially for the Platform’s production environments, the need for data restoration can be identified by either the business or applications systems integrator. Once this need is identified and confirmed, the restoration process begins. This process begins with either the creation of an emergency change request (for production) or a standard change request (for non-production environments) documenting specifically what needs to be restored. The restoration requirements can range from a single file restore to the restoration of an entire environment.

Change Management Process Guide

Authored by Vijay Chander – All rights reserved – 2023

The post How to secure the IT Environment of your customers? first appeared on TekTalk | Project Management Process Tool.

The post How to secure the IT Environment of your customers? appeared first on TekTalk | Project Management Process Tool.

Business plans for your startup have many different formats. Depending on your business you can create a pitch deck that is appealing and gets your message across to your potential investors.

Microsoft Office is one of the tools that has many business plan formats in PowerPoint. Below is one that you can use to pitch your product.

Credits to Microsoft Office Templates

Authored by Vijay Chander – Tektalk 2023

The post Business Plan – Pitch Deck first appeared on TekTalk | Project Management Process Tool.

The post Business Plan – Pitch Deck appeared first on TekTalk | Project Management Process Tool.

This Service level management process flow is written in a document format for easy printing and exporting as a document for your use.

Scope

The scope of Service Level Management is existing and new IT services provided by <your organization> to <Customer Name>.

Definitions

Service

A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.

Service Level Agreement

It is an agreement between <your organization> and <Customer Name>.

The SLA describes the IT Service, documents Service level targets, and specifies the responsibilities of the <your organization> and <Customer Name>.

Operational Level Agreement

It is an agreement between <your organization> and another department of <your organization>

An OLA supports <your organization> delivery of IT Services to <Customer name>. The OLA defines the goods or Services to be provided and the responsibilities of both parties.

Underpinning Contract (UPC)

It is a contract between an <your organization> and a Third party.

The Third party provides goods or Services that support delivery of an IT Service to a <Customer name>. The Underpinning Contract defines targets and responsibilities that are required to meet agreed Service level targets in an SLA.

Configuration Management System (CMS)

It is a set of tools and databases that are used to manage <your organization> Configuration data.

The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships.

The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users

The CMS is maintained by Configuration Management and is used by all Service Management Processes.

Service Improvement Plan

It is a formal Plan to implement improvements to a Process or IT Service.

Service Level Requirements (SLR)

A Customer Requirement for an aspect of an IT Service.

Roles and Responsibilities

Service Level Manager Responsibilities

• Keeping aware of changing business needs.
• Ensuring that the current and future service requirements of <Customer name> are identified, understood and documented in SLA and SLR documents.
• Negotiating and agreeing levels of service to be delivered with the <Customer name>; formally documenting these levels of service in SLAs.
• Negotiating and agreeing OLAs and, in some cases, other SLAs and agreements that underpin the SLAs with the customers of the service.
• Assisting with the production and maintenance of an accurate Service Portfolio, Service Catalogue, application Portfolio and the corresponding maintenance procedures.
• Ensuring that targets agreed within underpinning contracts are aligned with SLA and SLR targets.
• Ensuring that service reports are produced for each <Customer name>’s service and that breaches of SLA targets are highlighted, investigated and actions taken to prevent their recurrence.
• Ensuring that service performance reviews are scheduled, carried out with <Customer name> regularly and are documented with agreed actions progressed.
• Ensuring that improvement initiatives identified in service reviews are acted on and progress reports are provided to <Customer name>.
• Reviewing service scope, SLAs, OLAs and other agreements on a regular basis, ideally at least annually.
• Ensuring that all changes are assessed for their impact on service levels, including SLAs, OLAs and underpinning contracts, including attendance at CAB meetings if appropriate.
• Identifying all key stakeholders and customers.
• Developing relationships and communication with stakeholders, customers and key users.
• Defining and agreeing complaints and their recording, management, escalation, where necessary, and resolution.
• Definition recording and communication of all complaints.
• Measuring, recording, analyzing and improving customer satisfaction.

Input, Output

Inputs

• Business Information (Such as organizations business strategy, plans and information on current & future requirements.
• Business Impact Analysis
• Business Requirements
• Service Portfolio
• Service Catalogue
• Change management information
• Configuration Management System (CMS)
• Customer feedback
• Inputs from other Service Management processes

Outputs

• Service reports
• Service Improvement Plan (SIP)
• Service Quality Plan
• Service Level Agreements (SLA)
• Operational Level Agreements (OLA)
• Service Level Requirements (SLR)
• SLA review meeting minutes
• Revised Contracts

Service Level Management Process flow

 

Detailed explanation of the Service level Management Process flow

References

• Procedure for Change Management
• Procedure for Service Portfolio Management
• Procedure for Service Catalogue Management
• Procedure for Supplier management
• Procedure for 7 Step-Improvement

Measurements

Reports are generated based on the below metrics.

Authored by Vijay Chander – All rights Reserved – 2023

The post Service Level Management Process Flow and Guide first appeared on TekTalk | Project Management Process Tool.

The post Service Level Management Process Flow and Guide appeared first on TekTalk | Project Management Process Tool.

In this Issue management process blog, I have written it in a document style so that it can be copied and used directly into a document.

Program Issue Management Process

The Program Issues Management Process is the process used to receive, qualify and manage issues that require the intervention of <customer> or <your Organization> contract management team to facilitate resolution.

Objectives

The objectives of the Program Issues Management Process are to

• Ensure issues are captured and resolved within the shortest possible time-frame at the lowest operational level possible;
• Provide the escalation path, with criteria, from operational or project issue management to program issue management then ultimately to Dispute Resolution so that the resolution of the issue can be assigned to someone with appropriate authority;
• Track all open issues to closure; and,
• Protect the relationship between <customer> and <your organization)

This is done by the the following

• Establishment of a review meeting;
• Addition of issue monitoring to the agendas of contract meetings;
• Active tracking of issues; and,
• Logging issues and regularly updating and reporting status to the Commercial Review Meeting.

Scope

The Program Issues Management Process is used by <customer> and <your Organization> to manage and resolve all joint program issues, whether raised by <customer> or <your Organization>.

Operational or individual project-level issues, unless escalated to the central governance level, are excluded from this process and are managed within the delivery organizations.  Similarly, day-to-day contractual issues may be managed directly by the Contract Managers. 

Disputes are issues between <customer> and <your Organization> that cannot be resolved at the central governance level.  These are managed by the Dispute Resolution Process as described in Dispute Resolution of the Infrastructure Transformation Services Agreement and are excluded from this process except for tracking and reporting their status.

Internal issues of either organization are outside the scope of this process. 

The process begins when a joint program issue is raised and continues with ongoing tracking until the issue is resolved.

Policies

The following policies will apply to <customer> and <your Organization> in relation to this process:

• <customer> Technology Governance will be the focal point for issue status updates and reports within <customer>; and,
• The <your Organization>PMO will be the focal point for issue status updates and reports from <your Organization>.

Process Flow and Diagram

An issue is “a matter of concern” caused by some event which, if not resolved, will have an adverse impact on project or service commitments, client satisfaction or other program measurements.

A program issue is an issue that has been escalated to the point where resolution requires the involvement of either the <customer> Senior  Management or the <your Organization> Senior Management or both.  Due to their broad impact, some issues may inherently be program level and cannot be adequately addressed at a lower level.

The Program Issues Management Process has two phases

• Issue Initiation; and,
• Issue Management and Tracking.

It is expected that both <customer> and <your Organization> have an internal issues management process to handle its own internal issues.  Joint issues, however, are shared between <customer> and <your Organization> necessitating an interface between the respective internal processes. 

Policies

Other processes that may affect the Program Issues Management Process to be deployed include:

• Contract Change Management Process
• Formal Correspondence Process
• Contract Deliverables Process

Issue Management process flow

Process Steps

Program Issue Initiation

A program issue may be initiated when an initiator fills out a joint issue form (refer to Appendix A Forms (your task is to Create a form), in correspondence or by tabling and minuting the issue in the operational meeting.

The Commercial Review Forum provides the channel between <customer> and <your Organization> for all communications related to joint issues, including the ongoing communication of the status of open issues. The meeting is responsible for qualifying issues, approving resolution plans and ensuring status is tracked until the issue is resolved and closed or referred to the Dispute Resolution Process.

Raise Issue

The Issue Initiation phase shown in Figure 1 begins when a joint program issue is raised by either <customer> or <your Organization> and may arise, for example:

• If a delivery or project issue is unable to be resolved at the operational level;
• During the execution of other governance processes;
• As a result of a review or audit; and,
• As a result of an event that has a negative impact on contract commitments or client satisfaction.

Register Issue

A review is performed to verify that the issue qualifies as a joint program issue and that all information required for registering the issue has been provided. The issue is reviewed and noted by the <customer> and <your Organization> Governance Representative before the issue will be presented at the Commercial Review Forum and consequently the <your Organization>Performance Forum. The issue is registered by the <your Organization> PMO and a sequential number assigned to uniquely identify the issue.  The issue form is then submitted to the next Commercial Review Forum for qualification.

Qualify Issue

The issue is qualified by the Commercial Review Forum. Agreed Resolution will normally be provided at Commercial and/or the HIS Performance Forum.

The Commercial Review Forum qualifies the issue and assigns a person with the appropriate skills and authority to resolve the issue as the Issue Owner.  A target resolution date may be set at this time.

If an issue does not pass qualification the Issue Initiator is notified.  The initiator may elect to modify the information previously provided and resubmit the issue, escalate the rejection, submit or return the issue to delivery or project processes for management.

The Issue Initiation phase ends when one of the following occurs:

• The issue fails qualification; and,
• The issue passes qualification and is passed to the Issue Management and Tracking phase.

Issue Management and Tracking

The Issue Management and Tracking phase begins after a registered issue passes qualification and needs to be tracked by the Commercial Review Forum. 

Assign Issue Owner

When an issue passes qualification a person with the appropriate skills and authority to resolve the issue is assigned as Issue Owner.  A target resolution date may be set at this time.

When an issue passes qualification, the issue moves into the Initiate Issues Management and Tracking phase and an Issue Owner then is responsible for resolving it.

Develop Issue Resolution Plan

The responsibility for resolving a joint program issue may rest with either <customer> or <your Organization>.  In many cases the cooperation of resources from both organizations will be needed to produce a satisfactory resolution.  If a target resolution date was set during the Initiate Issue phase, the Commercial Review Forum will track to the agreed date; alternatively, a mutually agreed date will be set during the meeting.

The Issue Owner develops an Issue Resolution Plan and is responsible for obtaining the agreement of stakeholders for the proposed resolution.

Issue Resolution Plan Reviewed

The plan is reviewed by the Commercial Review Forum 

If the resolution plan is approved, the Issue Owner manages the implementation of the resolution.

If the resolution plan is not approved, it will be re-worked by the Issue Owner.

Execute Issue Resolution Plan

When the Issue Resolution Plan is approved, the Issue Owner manages the implementation of the resolution.   

Review Issue Resolution Status

Issue resolution progress is monitored against the resolution plan. Any agreed adjustments to the issue owner/resolution plan will be made where necessary.

Issue Escalation

If all efforts have failed to resolve a joint program issue it may escalated to the contractually-defined Dispute Resolution Process.

Issue Complete

The Issue Owner is responsible for obtaining the agreement of the Issue Initiator that the issue is resolved.

When complete, the Commercial Review Forum endorses the closure of the issue. 

The Issue Management and Tracking phase ends when the issue is resolved.

If the issue results in a Contract Change, please refer to the Contract Change Management Process

Issue Formal Closure

The Commercial Review Forum endorses the issue for formal closure; The <your Organization> PMO will update the issue form with agreed resolution and approval. The updated Program Issue form is then submitted to <customer> Technology Governance for audit records. 

Roles and Responsibilities

<customer>

<customer> representatives are responsible for:

• Performing the roles defined by the meeting charter for the Commercial Review Forum in the Governance Plan as appropriate;
• Participating in the review of the status of all open Program Issues in accordance with the schedule and agenda for the Commercial Review Forum; and
• Working with <your Organization> to resolve all Program Issues in a timely manner.

<your Organization>

<your Organization> representatives are responsible for:

• Performing the roles defined by the meeting charter for the Commercial Review Forum in the Governance Plan as appropriate; and,
• Participating in the review of the status of all open Program Issues in accordance with the schedule and agenda for the Commercial Review Forum; and
• Working with <your Organization> to resolve all Program Issues in a timely manner.

Commercial Review Meeting

The members of the Commercial Review M Forum meeting are specified in the Governance Plan and maintained by the Business Office.  It is responsible for:

• Ensuring a joint program issue is registered;
• Convening, in accordance with the meeting schedule and agenda detailed in the Governance Plan;
• Qualifying new joint issues;
• Assigning issue owners;
• Assigning issue priority as required;
• Agreeing the planned resolution date;
• Reviewing the status of joint issues;
• Approving resolution plans;
• Reviews resolution progress against the plan and may change the priority of the issue;
• Approve additional resources, assign a new owner or request changes to the resolution plan as required to accomplish effective and timely resolution of the issue; 
• Communicating to initiator, <customer> Technology Governance and <your Organization> PMO  if a Program Issue results in a Contract Change;
• Escalating joint issues that cannot be resolved at the program level to the contractually‑defined Dispute Resolution Process; and,
• Approving the closure of joint issues.

Issue Initiator

The Issue Initiator is responsible for:

• Ensuring that all operational avenues for resolving the issue have been exhausted prior to submitting a program issue;
• Completing and submitting the Issue Form when used;
• Reviewing and agreeing to the resolution proposed by the Issue Owner; and,
• Agreeing to the closure of the issue.

Issue Owner

The Issue Owner is assigned by the Commercial Review Forum and is responsible for:

• Managing assigned issues to resolution;
• Developing the resolution plan and gaining the agreement of stakeholders, including the Issue Initiator;
• Managing the implementation of the resolution plan;
• Obtaining the sign-off of the Issue Initiator that the issue has been resolved; and,
• Providing updated Issue Forms, if used, and status updates at the required frequency.

Authored by Vijay Chander – All rights reserved – 2023

The post Program Issue Management Process Guide! first appeared on TekTalk | Project Management Process Tool.

The post Program Issue Management Process Guide! appeared first on TekTalk | Project Management Process Tool.