Emergency change management is a critical aspect of organizational operations that deals with the efficient handling of sudden, urgent situations that require immediate action. It is a specialized process designed to address emergencies such as system failures, security breaches, or major disruptions to business continuity.

Unlike regular change management processes, emergency change management requires rapid decision-making, prioritization, and execution to mitigate the impact of the emergency and restore normalcy as quickly as possible. This discipline emphasizes effective communication, risk assessment, documentation, testing, and post-change evaluation to ensure that emergency changes are implemented successfully while minimizing any unintended consequences. By focusing on swift and efficient response, emergency change management helps organizations address unforeseen challenges and maintain operational resilience in the face of unexpected events.

Let us consider the 10 most important points:

Urgency

Emergency change management is necessary when a critical situation arises that requires immediate action. It typically involves situations such as system failures, security breaches, or major disruptions to business operations.

Rapid Response

Emergency change management focuses on quickly identifying and implementing the necessary changes to address the issue at hand. This may involve bypassing or streamlining normal change management processes to expedite the resolution.

Risk Assessment

Despite the urgency, it is important to conduct a rapid but thorough risk assessment to understand the potential impact of the emergency change. Risk assessment helps in determining the appropriate actions and mitigating any unintended consequences.

Stakeholder Communication

Effective communication is crucial during emergency change management. All relevant stakeholders, including the IT team, management, and affected users, should be promptly informed about the situation, the planned changes, and the expected impact.

Prioritization

When multiple emergencies occur simultaneously, prioritization becomes essential. A clear understanding of the criticality, urgency and potential impact of each emergency helps in allocating resources and focusing efforts where they are most needed.

Documentation

While time is of the essence, it is still important to document the process. This includes capturing the steps taken, decisions made, and any modifications to existing procedures. Documentation helps in reviewing and learning from the emergency situation for future improvements.

Testing and Validation

Even in emergency situations, it is essential to perform some level of testing and validation to ensure that the changes implemented effectively address the problem without introducing new issues. Typically in your testing and validation process a separate entity can be created to explain the process. This may involve conducting limited tests or leveraging existing knowledge of the system.

Contingency Planning

Emergency change management should also include planning for contingencies. In case the initial changes do not fully resolve the problem or new issues arise, having backup plans and alternative approaches can help minimize the impact on operations.

Post-change Evaluation

Once the emergency is resolved and stability is restored, it is important to conduct a post-change evaluation. This involves assessing the effectiveness of the changes, identifying any further improvements, and capturing lessons learned for future emergency situations.

Continuous Improvement

This process should be an opportunity for continuous improvement. Organizations should analyze the root causes of emergencies, identify ways to prevent or minimize their occurrence, and enhance their overall change management processes to handle emergencies more efficiently in the future.

Flowchart Representation

Here is the flowchart for a visual representation of process

Here is another representation of the Process

Check my earlier blog for Change Management Process.

For more information check ITIL’s Change Management.

Authored by Vijay Chander – All rights reserved – 2023

The post Emergency Change Management: Adapting to the Unexpected first appeared on TekTalk | Project Management Process Tool.

The post Emergency Change Management: Adapting to the Unexpected appeared first on TekTalk | Project Management Process Tool.

In IT service agreements, service level credit is commonly incorporated to provide customers with compensation in case the service provider fails to meet the predefined service levels. Essentially, this means offering the customer a credit towards future payments as a form of reimbursement for the service provider’s inability to meet the mutually agreed performance standards.

Key elements of Service Level credit

A Service Level Credit for the IT industry managed services typically includes the following information. We can divide it into different sections to focus on each. These sections may be documents, reports or processes.

Service Level Agreement (SLA) Details

This document normally outlines the specific service level targets and supplier performance metrics agreed upon between the service provider and the customer. It includes details such as response time, uptime, resolution time, and other key performance indicators (KPIs) that define the quality of service. This is the primary document for calculations of Service Level Credit.

SLA Breach Identification

Highlight any instances where the service provider failed to meet the agreed-upon service levels or performance standards. It identifies the specific SLA targets that were not achieved and provides a clear description of the breach.

Impact Analysis

Examines the impact of the SLA breach on the customer’s business operations. Assess the consequences of the service level failure and quantifies the impact in terms of downtime, lost productivity, financial losses, or any other relevant metrics.

Service Credit Calculation

The report outlines the methodology used to calculate the service credits owed to the customer. It typically includes the formula or calculation method specified in the SLA for determining the compensation amount based on the severity and duration of the SLA breach.

Service Credit Applied

Organizations also calculate the actual service credits that will be applied to the customer’s account as compensation for the SLA breach. It specifies the amount or percentage of credit to be deducted from future payments or invoices.

Root Cause Analysis

The report may include a root cause analysis of the SLA breach, identifying the underlying reasons or factors that led to the service level failure. This analysis helps in understanding the issues and taking corrective actions to prevent similar incidents in the future.

Corrective Actions

If any corrective measures were implemented to address the SLA breach, this section provides details of the actions taken by the service provider to rectify the situation and prevent recurrence.

Customer Feedback and Resolution

Customer perception is very important when discussing resolutions. If the customer provided feedback or raised any concerns regarding the SLA breach, this should be captured and should include a summary of their input and how the service provider resolved or addressed those concerns.

Forward Planning

Including this section, which outlines any preventive measures or improvements planned by the service provider to enhance service delivery and avoid future SLA breaches. It may include strategies for process improvements, infrastructure upgrades, or staff training.

Create a report with a summary and overall assessment of the SLA breach, highlighting the steps taken, the compensation provided, and the commitment to delivering better service in the future. An example is shown below for critical service levels. (SLED is Service Level Effective Date)

Conclusion

Service Level Credit is an important aspect to keep a service level provider in check, to ensure they keep up their delivery standards. Missing those performance standards translates to financial penalties.

Authored by Vijay Chander – All rights reserved – 2023

The post Service Level Credit – Why is it Important? first appeared on TekTalk | Project Management Process Tool.

The post Service Level Credit – Why is it Important? appeared first on TekTalk | Project Management Process Tool.

Project Onboarding is the process of adding a person to a new or existing project.  At the onset this is different from onboarding a person into the organization, which is a separate topic of discussion. Here we explore what an organization should consider when onboarding a resource into a IT project.

Let me list out some of the top items that are listed below

Project onboarding: Goals and Objectives

Clearly Communicate the goals and objectives of the IT project to the new team member. Here are a few examples:

 

1. Organize a project kickoff meeting specifically for the new team member. In this meeting, present an overview of the project, including its goals, objectives, and expected outcomes. Discuss the scope of the project, major milestones, and timelines.
2. Utilize visual aids such as flowcharts, diagrams, or presentations to illustrate the project’s structure, key processes, and expected outcomes. Visual representations can help the new team member grasp the big picture more effectively.
3. Provide written materials, such as project briefs, requirements documents, or project plans, that clearly articulate the project’s goals, objectives, and deliverables. These documents should also outline the project timeline and milestones.
4. Schedule one-on-one discussions with the new team member to provide a personalized explanation of the project’s goals and objectives. Allow them to ask questions and seek clarification on any aspects they may find confusing.
5. Collaborate with the new team member to establish individual goals and performance objectives aligned with the overall project goals. This helps them understand how their work contributes to the project’s success.
6. Use real-world examples or case studies that demonstrate how similar projects have achieved their goals and the impact they had on the organization. This can provide context and help the new team member visualize the desired outcomes.

Project Structure and Roles

Explain the project’s organizational structure, including the roles and responsibilities of team members. In project onboarding it is essential to provide clarity in defining the reporting lines and escalation paths to ensure a smooth collaboration.

 

1. Provide a clear and concise overview of the project’s organizational structure, including the different teams, departments, and their respective roles. Explain how these teams collaborate and interact with each other within the project context. Use diagrams or visual representations, if possible, to illustrate the structure and relationships.
2. Clearly define the roles and responsibilities of team members within the project. Outline the specific tasks, deliverables, and areas of expertise expected from each role. Emphasize the interdependencies and collaborative nature of the project, highlighting how each role contributes to the overall success of the project.
3. Explain the reporting lines and escalation paths to ensure effective communication and issue resolution. Clarify who team members report to, who they should reach out to for guidance or approvals, and how decisions are escalated when necessary. This helps prevent confusion and ensures that everyone understands the appropriate channels for communication and problem resolution within the project structure.

Project Documentation

Provide access to relevant project documentation, such as project plans, requirements documents, design specifications, and any existing documentation. Ensure the new team member understands the project’s context and current progress.

 

1. Set up a centralized document repository or project management system where all relevant project documentation is stored. Grant the new team member appropriate access and permissions to retrieve and review the necessary documents. Ensure the repository is organized and labeled clearly to facilitate easy navigation and retrieval of information.
2. Schedule dedicated sessions with the new team member to review and discuss the project documentation. Walk them through the project plans, requirements documents, design specifications, and any other existing documentation that provides context and insights into the project. Encourage questions and discussions to ensure their understanding of the project’s current progress, challenges, and key considerations.

Tech Stack and tools

Familiarize the new team member with the project’s technology stack, tools, and development methodologies being used. Provide necessary training or resources to help them quickly get up to speed.

 

1. Provide an overview of the project’s technology stack, outlining the different technologies, frameworks, and programming languages being used. Explain the purpose and role of each component within the overall architecture. Share any relevant documentation or resources that can help the new team member understand the stack in more detail.
2. Offer training sessions or provide resources to familiarize the new team member with the tools and software used in the project. This can include development environments, version control systems, project management tools, testing frameworks, or any other relevant tools. Ensure they have the necessary access credentials and permissions to use these tools effectively.
3. Explain the development methodologies and practices employed in the project, such as Agile, Scrum, or Kanban. Describe the workflow, iteration cycles, and any specific processes or ceremonies followed. Help the new team member understand their role within these methodologies and how they can contribute to the project’s success.

Project Culture and Values

Introduce the new team member to the project’s culture and values, emphasizing teamwork, collaboration, and a commitment to project success. Encourage an inclusive and supportive environment.

 

1. Emphasize the importance of collaboration and teamwork within the project. Highlight that the project’s success depends on the collective effort and contributions of the entire team. Encourage open communication, knowledge sharing, and a supportive environment where team members can collaborate effectively.
2. Emphasize a culture of continuous learning and innovation. Communicate that the project team values creativity, curiosity, and a growth mind-set. Encourage team members to explore new technologies, propose innovative solutions, and actively seek opportunities for professional development and improvement.
3. Emphasize the importance of accountability and taking ownership of one’s work. Communicate that the project team values individuals who take responsibility for their tasks, deliverables, and commitments. Encourage a proactive approach to problem-solving, meeting deadlines, and ensuring the quality of deliverables.
4. Respect and Inclusivity: Stress the project team’s commitment to fostering a culture of respect and inclusivity. Emphasize that team members should treat each other with respect, regardless of their roles, backgrounds, or perspectives. Encourage active listening, empathy, and creating a safe environment where diverse ideas and opinions are valued.

Those are the few aspects to keep in mind when inducting a team member into an IT project. You can be more elaborative on project onboarding if you require to prepare one for your organization. Some of the others you may consider are explaining the project risks, the training availability and delivery, and quality expectations.

Authored by Vijay Chander – All rights reserved 2023

The post Important Steps to follow for a Successful Project Onboarding first appeared on TekTalk | Project Management Process Tool.

The post Important Steps to follow for a Successful Project Onboarding appeared first on TekTalk | Project Management Process Tool.

Introduction

Concurrent Dev policies provides general guidance to ASIs (Application Software Integrators) regarding the development and integration of software systems for the Customer (Enterprise) Platform. It presents policies and recommended approaches for creating applications that work with the Middleware (MW) components of the Platform.

Additionally, this blog assumes you have a template that can be used to create interface design documentation (Will write a separate blog on this!). ASIs are encouraged to adhere to the naming conventions provided in this document while developing MW applications.

By adhering to the practices and processes for concurrent dev policies outlined in this document, ASIs can also reduce the time required to onboard new developers, make efficient use of existing services by reusing them, and promote consistent interaction among different ASIs.

ASIs should consider this document as a point of reference for their concurrent dev policies.

Customer Platform

The Platform consists of managed hosting services and other shared services utilized across multiple projects and/or business solutions that are deployed on the Platform. The customer or an enterprise integrator is not only responsible for providing these shared services, but also includes an independent System Integrator / Multi-Vendor Integration (SI/MVI) team that is responsible for supporting ASIs and implementing proper governance and processes for development on the Platform.

The following areas are normally designated as shared services provided as part of the Platform for which we are discussing the concurrent dev policies. You may add more the following list.

• Middleware
• Security
• Analytics
• Portal
• Content Management

Generally the architecture is broken into four distinct parts. They are 1. Presentation Layer 2. Data Layer 3. Application Layer and 4. Middleware Layer.

Types of documents to be maintained by ASI for concurrent dev policies include the following:

Onboarding Guide

• Develop and document standardized processes for onboarding new ASI team members. This is the responsibility of the ASI supervisor. The SI/MVI team administrators will provide the necessary support in addition to an handbook for how to appropriately work with the Enterprise Systems Integrator (ESI).

Design Documents

• The ASI must maintain the following types of documents for any new application or project implemented by the ASI.
  • Logical Architecture: A system architecture diagram displaying all the logical components. Interface Design: A document detailing specifications for new services or interfaces exposed to other ASIs.
  • Integration Flows: A document displaying all the integration flows developed for the new applications and projects.

Standards Documents

• Develop and maintain coding standard documents that detail practices to be followed by ASI developers. These standards should also include any policies or standards from the customer for any shared service areas that may be relevant to the work being performed by the ASI.

Design Policies

The following must be used as a guide and you can add to it for concurrent development policies

• ASIs should review the current customer Enterprise Platform architecture. The SI/MVI enterprise architect/technical lead (EA/TL) is responsible for maintaining relevant, Platform-related documentation.
• Testing environments may contain masked personally identifiable information (PII) data. During the design phase, the ASI should identify any PII data to be masked for the new application or project.
• The ASI must consider high availability (HA) when designing the architecture for the new application or project.

The proposed design must be compatible with the established disaster recovery (DR) process, which also has to follow the published standards of the concurrent development policies.

Solution Architecture Principles

The proposed solution should follow guiding architectural principles developed by customer.

• Modular Design: Architectural design should follow a modular approach. This includes breaking down the solution into as small modules as possible which provide a single functionality with minimal inter-dependency.
• Service-Oriented: The architecture should consist of a number of services that are compliant with industry standards for SOA to facilitate reuse, adaptability, and interoperability.
• Distributed Architecture: Modules must be able to run on distributed resources and ability to communicate with each other.
• Reusability: Design the modules for reuse. Modules are designed and deployed in a manner that enables them to be invoked by disparate systems.
• High Availability: The solution architecture must be designed to ensure high availability.

Integration and Testing

• The ASI will be responsible for testing and maintaining valid integrations for all components of the overall system architecture at all times.
• The ASI will be responsible for code migration.
• The ASI is responsible for identifying test data and providing scripts to create/migrate data.
• The customer/integrator team will be responsible for executing the migration scripts for test data and other Platform-related configurations required for testing.
• The customer/integrator team will coordinate testing activities with other ASIs and external partners and agencies.
• Additional details on integration and the code migration path are provided in Section 5 Code Migration.

ASIs must follow continuous integration practices. ASIs are free to use the integration tools of their choosing; however, the ESI recommends using the tools in the following table.

Code Migration Policies

• The ASI needs to produce a Systems Integration document that provides the customer with the information required for the integration of the associated application or project. This information should include: integration flows, connections to external systems and agencies, test data set requirements and other details as applicable. These documents are to be uploaded to the applicable Shared project site with permissions granted to the customer for accessibility.
• Before promoting code to the next environment, the ASI needs to provide the customer with a Testing Summary document that includes the methodology and a task list of what was tested and how. This document must be attached to the service request in ServiceNow, requesting promotion.
• Environment backups should be taken before code promotion. The ASI can request backups by submitting a service request. Please note that databases should be backed up on a recurring basis for all non-production environments, except for UATxx (exceptions). If an ASI needs regular backups of infrastructure components (e.g., software binaries, filesystems, log files, etc.) for any other non-production environment, the ASI needs to submit a service request ticket with details on the backup, restore requirements, and timeline. All infrastructure components for non-production environments—example (UATxx and UATyy) —are backed up on a regular basis.
• Testing environments contain masked personal identification data. It is the ASI’s responsibility to identify the personal data to be masked for the new application or project developed by the ASI.
• The ASI needs to provide the customer with instructions on how to mask the personal data (identified in the previous bullet). The ASI can request data masking by submitting a service request ticket. The instructions for masking should be attached to the service request.
• For disaster recovery, the customer/integrator team will be responsible for migration and sync-up of databases and file systems. It is the ASI’s responsibility to migrate and sync application specific configurations.

In conclusion these are some of the guidelines you can use as a reference for Concurrent Dev policies that are adopted by your internal team and also your application software integrators. This will ensure a standardized and predictable output following desired standards.

Authored by Vijay Chander – All rights reserved 2023

The post Concurrent Dev Policies – The Best Practices Of Integrating Applications first appeared on TekTalk | Project Management Process Tool.

The post Concurrent Dev Policies – The Best Practices Of Integrating Applications appeared first on TekTalk | Project Management Process Tool.

Performance reports on infrastructure aims to present a comprehensive overview of a system’s performance in important aspects. These reports serve the purpose of analyzing patterns and detecting areas that require closer examination. Identifying performance issues can be challenging since they might not be directly related to metrics like CPU, memory, or networking. Moreover, they may not generate clear error messages in logs and can result from specific bottlenecks within the system. By establishing and reporting on performance metrics, we can ensure a favorable user experience for customers.

Database Reporting

Database reports are intended to show the overall footprint across all databases. Several key indicators such as database size, wait time, availability, and number of connections help to identify which environments require the most attention and are going to be most impactful if they are taken down for maintenance.

• Reports provided
  • Database metrics
• Tools
  • OEM
• Overview of report content
  • Size (GB)
  • Availability (%)
  • Wait Time (%)
• Frequency of report generation
  • Monthly
• Location of stored output
• Communication mechanism

Network Reporting

Network reports are intended to show the overall utilization and availability of the network. Networking paths can be complicated and are not always easily understood through diagrams. Network traffic patterns are critical in understanding interoperability between systems and designing risk mitigation schemes.

• Reports provided
  • Network (MB/s)
  • Network uptime
• Tool
  • SolarWinds
• Overview of report content
  • Utilization across all interfaces (MB/s) over a 30-day period
  • Network availability for the month
• Frequency of report generation
  • Monthly

 

Security Reports

 

Security reports focus on known vulnerabilities and patching progress as part of the Security Governance Framework. Security reports will provide the most actionable recommendations as compliance will continually be a top priority for the customer. This reporting mechanism is crucial for providing a mapping between potential vulnerabilities and the patch level of affected systems.

 

• Reports provided
  • NESSUS scan results
• Tools
  • NESSUS
• Overview of report content
  • Total results: production and non-production
  • Top 12 critical vulnerabilities
  • Top 12 hosts of critical vulnerabilities
  • Linux patching progress
• Frequency of report generation
  • Monthly

Other Reports

Helpdesk reports are collected from your helpdesk software like Jira or ServiceNow and presented on a monthly basic. Here is an example of that report.

Performance reports on infrastructure serve as a vital tool in maintaining and optimizing infrastructure systems. By carefully analyzing performance data, trends can be identified, and potential areas of concern can be addressed proactively. It is important to recognize that performance issues are not always straightforward and may require thorough investigation to identify the underlying causes. Therefore, defining and reporting on performance metrics becomes crucial to ensure a seamless and satisfactory experience for the users of the infrastructure. By continuously monitoring and optimizing performance, organizations can enhance the efficiency, reliability, and overall success of their infrastructure systems.

Authored by Vijay Chander – All rights reserved 2023

The post Why Performance reports on Infrastructure is Important? first appeared on TekTalk | Project Management Process Tool.

The post Why Performance reports on Infrastructure is Important? appeared first on TekTalk | Project Management Process Tool.

Introduction

Key Activities

• Planning for Turnover: We will carefully strategize and plan the various elements involved in the turnover process.
• Knowledge Transfer: Our team will facilitate the transfer of essential knowledge to empower the customer in independently operating the solution.
• Pre-Cutover: We will conduct thorough preparations and evaluations ahead of the cutover phase.
• Cutover: We will manage the actual cutover phase to ensure a seamless transition to the customer’s control.
• Post Cutover: We will provide ongoing support and assistance immediately following the cutover to address any post-transition challenges.
• Turnover Finalization and Acceptance: This stage involves formalizing the completion of turnover and obtaining acceptance, ensuring that all requirements and expectations are met.

Your organization should be dedicated to delivering a comprehensive turnover process that enables the customer to assume full ownership of the solution and associated components with confidence.

Requirements Statement

The Requirements Statement outlines the number, skills, responsibilities, and salary of personnel required to assume full maintenance and operations support of the solution. In addition to the people required to operate the solution, Requirements Statement will include an inventory of all systems, documentation, supplies, facilities, and any other resources required to operate the solution.

Turnover Training Plan for Maintenance and Operations

The objective of the maintenance and turnover assessment training plan is to equip the Maintenance and Operations team with the necessary knowledge and skills to effectively assume responsibility for the ongoing support and operation of the information technology systems. The training plan aims to ensure a smooth transition and seamless continuation of services.

1. Documentation Review

• • Conduct a comprehensive review of all relevant documentation, including system manuals, standard operating procedures (SOPs), incident logs, change management records, and system configurations.
  • Verify the accuracy and completeness of the documentation, ensuring it reflects the current state of the IT systems.

2. Knowledge Transfer

• • Facilitate knowledge transfer sessions where the outgoing IT team shares their expertise, insights, and best practices with the Maintenance and Operations team.
  • Cover critical areas such as system architecture, key processes, troubleshooting techniques, and known issues.
  • Encourage interactive discussions and provide opportunities for the Maintenance and Operations team to ask questions and seek clarification.

3. Transition Planning

• • Develop a detailed transition plan that outlines the timelines, milestones, and responsibilities for the turnover process.
  • Identify any dependencies, risks, or challenges that may arise during the transition and establish mitigation strategies.
  • Define communication channels and protocols for effective coordination between the outgoing and incoming teams.

4. System Access and Permissions

• • Ensure that the Maintenance and Operations team has the necessary access rights and permissions to manage and operate the IT systems.
  • Update user accounts, passwords, and access controls as needed to align with the new team’s requirements.
  • Coordinate with the relevant stakeholders, such as network administrators and system administrators, to ensure smooth access transitions.

5. Testing and Validation

• • Conduct thorough testing and validation of the IT systems to ensure their stability, functionality, and adherence to established service level agreements (SLAs).
  • Collaborate with the outgoing IT team to perform comprehensive system checks, including functionality tests, performance evaluations, and disaster recovery drills.
  • Document and address any identified issues or discrepancies before the formal handover.

6. Incident and Change Management Alignment

• • Align incident management and change management processes between the outgoing and incoming teams.
  • Ensure that the Maintenance and Operations team is fully aware of the incident reporting procedures, escalation paths, and response protocols.
  • Establish a streamlined change management process to track and manage system modifications, ensuring proper documentation, approval, and implementation.

7. Stakeholder Communication

• • Communicate the upcoming transition to relevant stakeholders, including end-users, management, and other internal teams impacted by the change.
  • Provide regular updates on the progress of the turnover process, highlighting key milestones, anticipated benefits, and any potential disruptions.
  • Address any concerns or questions raised by stakeholders and ensure transparency throughout the transition.

8. Post-Turnover Support

• • Offer post-turnover support and assistance to the Maintenance and Operations team during the initial phase to address any unforeseen challenges or questions.
  • Conduct regular check-ins and knowledge transfer sessions to ensure a smooth transition and promote ongoing collaboration between the outgoing and incoming teams.

Turnover Results Report

1. Executive Summary

• • Summarize the purpose and objectives of the turnover process.
  • Provide an overview of the key activities and milestones achieved during the transition.
  • Highlight the overall success of the turnover and its impact on the Maintenance and Operations team’s ability to assume full responsibility.

2. Scope and Objectives

• • Define the scope of the turnover, including the specific IT systems, applications, and infrastructure involved.
  • Outline the objectives and goals established for the transition process.
  • Specify any constraints, limitations, or considerations that were taken into account during the turnover.

3. Turnover Timeline

• • Present a timeline of the turnover process, highlighting key dates, milestones, and activities completed.
  • Include any deviations or adjustments made to the original timeline and provide explanations for the changes.

4. Documentation and Knowledge Transfer

• • Discuss the review and evaluation of documentation provided by the outgoing IT team.
  • Describe the knowledge transfer sessions conducted to transfer expertise and best practices.
  • Highlight any improvements or updates made to the existing documentation based on the turnover process.

5. System Validation and Testing

• • Provide an overview of the validation and testing activities performed to ensure the stability and functionality of the IT systems.
  • Detail the testing methodologies, including functional testing, performance evaluations, and disaster recovery drills.
  • Summarize the results of the testing, highlighting any issues identified and their resolution.

6. Incident and Change Management Alignment

• • Describe the alignment of incident management and change management processes between the outgoing and incoming teams.
  • Discuss the establishment of incident reporting procedures, escalation paths, and response protocols.
  • Highlight the successful implementation of a streamlined change management process.

7. System Access and Permissions

• • Detail the process of granting system access and permissions to the Maintenance and Operations team.
  • Describe any updates or modifications made to user accounts, passwords, and access controls.
  • Highlight the successful transition of system access without disruptions.

8. Stakeholder Communication

• • Discuss the communication strategies employed to inform relevant stakeholders about the turnover process.
  • Summarize the key messages conveyed to end-users, management, and other internal teams.
  • Include feedback or testimonials from stakeholders regarding the effectiveness and transparency of the communication.

9. Lessons Learned

• • Identify lessons learned from the turnover process, highlighting areas of success and areas for improvement.
  • Provide recommendations for future turnover activities based on the experiences gained.
  • Outline any best practices or insights gained during the transition that can be applied to future projects.

10. Conclusion

• • Recap the successful completion of the turnover process.
  • Summarize the key achievements, outcomes, and benefits of the turnover for the Maintenance and Operations team.
  • Express appreciation to all stakeholders involved in the transition.

The post How To Implement the Right Maintenance And Turnover Assessment Plan? first appeared on TekTalk | Project Management Process Tool.

The post How To Implement the Right Maintenance And Turnover Assessment Plan? appeared first on TekTalk | Project Management Process Tool.

Introduction

This blog outlines the methodology for effectively managing the Enterprise Integrator engagements. Its purpose is to guarantee the delivery of high-quality services and the fulfillment of all service level agreements (SLAs) in supporting the customer platform. It covers key aspects such as the account management structure, account planning, and program management processes. These processes are designed to ensure consistent and reliable service delivery across the account.

What is the best approach? Let us look into this from a perspective (I am using Oracle’s Envision, Implement and Manage) approach here

• The Project Management Office (PMO) ensures that customer support aligns with customer expectations.
• The PMO defines governance and standards to facilitate consistent delivery of enhancement projects.
• The approach, centered around the Oracle Unified Method (OUM), focuses on three areas: Envision, Implement, and Manage.
• While Envision and Implement are relevant to the work performed for the customer, the Manage focus area is crucial for comprehensive program management.
• The Manage focus area follows principles from the Project Management Institute’s (PMI) Body of Knowledge.
• The Enterprise Integrator provides document templates, standards, and conventions, as well as establishes an electronic document repository for version control and reviews of key program and project deliverables.
• The Enterprise Integrator employs a primary approach for managing areas such as Scope, Work, Issue, Problem, Risk, and Communications.

Scope

Defining the scope is a tedious task, and the outcome is the slave labor you put into understanding your customer and endless interview sessions. Let us look at some of the key areas in Scope that one must focus on.

• The scope defines the specific boundaries and deliverables that the team will implement.
• The scope will be actively managed throughout the entire project lifecycle, from request initiation to closure.
• The primary source of the enterprise integrator scope is normally outlined in the contract with the customer.
• When requests are made by the customer or the Application System Integrator (ASI), the scope will be evaluated and, if necessary, appropriately amended.
• This evaluation and amendment process will be carried out through the change control process and the project approval process, which will be further explained in subsequent sections of the document.

Work Management

The Enterprise Integrator has defined work management execution processes and policies. These processes and policies include the definition of and weekly monitoring of:

• Team member time and expense entry and approval into a designated project accounting system
• Task status reporting and tracking is performed weekly

Through various internal meetings, team members will be advised of their upcoming tasks in advance so that they can plan their work schedules appropriately.  From a Platform support perspective, periodic reviews of overall staffing levels will be conducted to ensure that work is being performed as effectively as possible while still meeting all agreed upon SLAs.

For enhancement projects, the work plan is the most important document the Enterprise Integrator has for communicating project progress and status. One can utilize Microsoft Project or any other one as the a scheduling tool for creating the work plan. The Enterprise Integrator develops, communicates, and maintains a work plan for each of the enhancement projects approved to be initiated by customer. The most current copy of any work plan, along with other key deliverables outlined as part of a Project Charter, are stored in the appropriate customer project site in a shared repository to ensure that all team members always have access to the most up to date documentation.

Issue Management

The Enterprise Integrator defines issue management as a structured process for identifying, documenting, tracking and resolving issues as they occur throughout the life cycle of a project or service request. The System Integrator and Operations Manager defines, obtains agreement on, and communicates, a structured process to capture and track issues. It is the Enterprise Integrator’s responsibility to record, assign, and track issues as well as to drive the resolution of open issues as it relates to the Platform or any projects that are being managed by the Enterprise Integrator.

Key aspects of issue management include:

• Analyzing cause and effects associated with issues
• Capturing, analyzing, and resolving or escalating issues
• Establishing reporting metrics (e.g., issues by category, issues by application, issues by flow)

Issues will be discussed and reported to customer through regularly scheduled Platform M & O Status and Whiteboard meetings for both projects and the Platform, status reports, and at quarterly business reviews—all of which are outlined in the Enterprise Integrator Program Communication Plan.

Problem Management

A problem is defined as a perceived variance between the expected and observed ability of an item to fulfill its defined purpose (e.g., a software bug, consistent unexpected downtimes, a faulty design, TARs/SRs). The Enterprise Integrator documents and captures problems on a formal problem log, assigns individuals responsible for problem resolution, tracks the resolution of problems, and—in those instances when the team cannot resolve the problem—escalates as appropriate following our escalation management process.

Key aspects of problem management include:

• Analyzing cause and effects associated with problems
• Capturing, analyzing, and resolving or escalating problems
• Establishing reporting metrics (e.g., problems by category, problems by application)
• Establishing a process to determine and report root cause analysis (RCA) of problems to identify and take corrective actions to prevent problems in the future

Problems and RCAs are discussed and reported to customer through regularly scheduled Platform M & O Status and Whiteboard meetings both projects and the Platform, status reports, as well as at quarterly business reviews—all of which are outlined in the Enterprise Integrator Program Communication Plan.

Risk Management

A risk is an uncertain event or condition, which if it occurs, has a positive or negative effect on a request’s objectives. The Enterprise Integrator develops and manages risks per the following process. Risk management does not necessarily eliminate risk but attempts to reduce the exposure to risk. A risk is viewed in two dimensions:

• Risk probability: The likelihood that a certain risk will negatively affect a project
• Risk impact: Measures the anticipated severity of a risk

Examples of common risk sources include

• Size and complexity of effort (e.g., solution footprint, number of business units, geographic breadth)
• Technical (e.g., infrastructure technology, applications, third party, legacy)
• Staffing (both customer and Enterprise Integrator)
• Organizational change management
• External factors

The Enterprise Integrator follows a risk management process that includes the following components for both Platform activities as well as individual projects led by the Enterprise Integrator:

• Risk identification: Notification when a risk is identified and turned into a problem.
• Risk analysis and prioritization: Regular assessment of open risks and criticality of each.
• Risk response planning: Possible options assigned to risks include avoidance, transfer, mitigation, accept and control. If mitigation is the approved approach, mitigation plans are identified and documented along with the risk.
• Risk monitoring: The process for reviewing risks before they are identified as having occurred.

Risks are discussed and reported to customer through regularly scheduled Platform M & O Status and Whiteboard meetings for both projects and the Platform, status reports, as well as at quarterly business reviews—all of which are outlined in the Enterprise Integrator Program Communication Plan.

Communications

The Enterprise Integrator provides all quality data, analyses, deficiency reports, corrective action plans and other QA data to customer routinely via normal program and task management channels, such as monthly program reviews, quarterly business reviews, status reports, and other technical interchanges and as defined further in the Communication Plan.

Achieving Quality

Enterprise Integrator brings a concentrated focus on quality assurance (QA) methods. Because of our process-driven orientation, BIAS consistently meets or exceeds customer requirements, as evidenced by having received numerous customer recognitions during the past five years, including awards, certificates of achievement, and letters of commendation.

A Quality Assurance Plan consists of planning and prioritization, performance and quality assurance reviews, corrective actions, and client satisfaction surveys. This plan defines the methodology for validating performance with Platform requirements. The goals of this Quality Control Plan include the following:

• Focus quality control efforts on the areas of greatest importance for the customer Agency of One vision
• Provide a comprehensive and verifiable approach for monitoring contractor performance
• Promote consistent, accurate, and effective communication of contractor performance
• Implement a self-sustained approach to continuously improve performance
• Motivate innovative use of available resources to benefit customer and the Enterprise Integrators as partners in the program

Project Planning and Prioritization

Quality is best achieved when it is built into the initiative from planning phases. The delivery methods include a robust planning and mobilization phase. The purpose of this phase is to help confirm that you have a thorough understanding of the customer goals and expectations, business cases, existing management structure and processes, and other key criteria. The planning approach involves confirming the program scope, refining estimates, finalizing resources and work planning, and confirming assumptions, risks, and dependencies.

Finally, identify controls and their reporting frequencies to provide a process for monitoring the achievement of the goals associated with each program, project, and task. This information is documented in a project charter that is approved by customer before any project activities can begin in earnest. The Enterprise Integrator’s Program Manager and Project Manager would have primary oversight of the planning and proper prioritization of customer goals and expectations. Through a series of meetings with the customer Program and Project Manager, the Enterprise Integrator management team confirms and refines all previous planning work and begins mobilizing additional team members to start implementation activities. This assures the onset of correct plans for quality and performance.

Client Expectation Management

To help validate that we continue to meet customer expectations, we will implement a Client Expectations Management process. We will use this process to gain an understanding of how customer executives define satisfaction with our overall efforts.

The Enterprise Integrator directors will meet with customer management to answer two key questions:

• How would customer judge our performance?
• How would customer judge our contribution to their success?
• Would customer recommend using the Enterprise Integrator to another department or colleague?

Confirm expectations with customer, have follow-up meetings to determine how you are performing with these expectations, and to determine if expectations have changed.

Customer Management

Relationship management involves key stakeholders on all Platform initiatives. The relationship management approach we propose includes:

• Defining program objectives and validating they are aligned with key business objectives
• Verifying that each major project and program affecting the Platform is well defined with accountable sponsors and champions; accountable meaning they own the business outcomes
• Determining project success criteria during the inception phase of the project
• Identifying clear delineation of roles, responsibilities, and authority commensurate with their roles across Enterprise Integrator, Application Systems Integrator, and customer teams
• Providing proper management methodologies and tools in place and providing adequate support for delivering and reviewing deliverables and outcomes
• Developing timely, accurate, and fact-based reporting
• Facilitating controlled and timely resolution of issues and risks with a clearly defined escalation path
• Develop RCAs and other means to foster continuous improvement efforts

Authored by Vijay Chander – All rights Reserved – 2023

The post How to define a scope for an Enterprise Integrator Engagement? first appeared on TekTalk | Project Management Process Tool.

The post How to define a scope for an Enterprise Integrator Engagement? appeared first on TekTalk | Project Management Process Tool.

Introduction

In this blog we explore the options for Storage Management and Operations. This blog explores a unique perspective on storage resource management, fostering the consistent integration of storage information and processes into the overarching management of an IT environment. The objective is to improve the efficiency and effectiveness of a storage organization by utilizing a set of aligned storage management processes based on a CMDB that contains storage Configuration Items (CIS). This blog shows how the process can be enhanced with a ‘storage resource perspective’ that is required to support storage management operations. The linkages required for this process for better enhancement of the following services include: Configuration Management, Change Management, Incident Management, Release Management and Service Level Management.

Service Management Storage Resource Perspectives

 

Storage Configurations

 

These are the various storage configurations you need to check.

 

Local Storage

This refers to the storage devices that are directly connected to a single computer or server. Local storage can include hard disk drives (HDDs), solid-state drives (SSDs), USB drives, or other similar storage devices. Local storage is typically used for storing data and files on a specific computer or server and is not accessible to other computers or servers in the organization without manual sharing or transfer.

 

Network-Attached Storage (NAS)

NAS is a dedicated storage device or server that is connected to the network and provides storage services to multiple computers or servers. NAS devices are equipped with their own operating system and file system, and they are accessed over the network using protocols such as NFS (Network File System) or SMB (Server Message Block). NAS is often used for centralized file sharing, data backup, and media streaming within an organization.

 

Storage Area Network (SAN)

SAN is a specialized network that enables multiple servers to access shared storage devices, typically in the form of disk arrays or tape libraries. SAN uses high-speed connectivity technologies such as Fibre Channel or iSCSI (Internet Small Computer System Interface) to connect servers and storage devices, allowing for high-performance and scalable storage solutions. SAN is commonly used for large-scale data storage, databases, virtualization, and mission-critical applications.

 

Cloud Storage

Cloud storage refers to the storage of data and files on remote servers managed by a third-party provider over the internet. Cloud storage allows organizations to store and access data from anywhere, at any time, and typically offers scalability, flexibility, and cost-effectiveness. Various purposes, including data backup, file sharing, collaboration, and application hosting, can use cloud storage.

 

Hybrid Storage

Organizations create customized storage solutions that meet their specific requirements by combining different types of storage technologies in hybrid storage configurations. For example, they may use local storage for frequently accessed data, NAS for centralized file sharing, SAN for high-performance databases, and cloud storage for offsite data backup and disaster recovery.

 

Virtualized Storage

Virtualized storage is a type of storage configuration that abstracts physical storage resources and presents them as virtual storage to servers or applications. This can be done through software-defined storage (SDS) or virtual storage appliances (VSAs) that run on standard servers and utilize local storage, NAS, SAN, or cloud storage resources. Virtualized storage provides flexibility, scalability, and ease of management, making it suitable for virtualized environments and software-defined data centers.

 

Once you have figured out the Storage Configurations your organization has, you have to define the configurations in detail and importantly be able to track it. Here is an example of how you can track your configuration:

File system

Local storage can be tracked using the file system of the operating system running on the computer. For example, on Windows, the File Explorer or Command Prompt can be used to navigate and manage files and folders stored on the local storage device.

Disk management tools

Operating systems often have built-in disk management tools that allow tracking the storage usage and health of local storage devices. These tools can provide information on disk space usage, disk health status, and partitions on the local storage device.

Asset management software

Organizations may use asset management software that tracks and manages all IT assets, including local storage devices. These software solutions can provide details on the type of storage device, its location, owner, usage, and other relevant information for tracking and inventory management purposes.

Labeling and documentation

Proper labeling and documentation of local storage devices, including serial numbers, model numbers, and other relevant information, can help track them effectively. This information can be stored in a centralized database or inventory system for easy reference.

Regular audits

Regular audits of local storage devices can be conducted to ensure accurate tracking. This can involve physically checking and verifying the presence and condition of local storage devices in their designated locations and cross-referencing them with the documented inventory.

Barcode or RFID tagging

Using barcode or RFID (Radio-Frequency Identification) tagging on local storage devices can help streamline the tracking process. Each storage device can be assigned a unique barcode or RFID tag, which can be scanned or read using specialized equipment to update the inventory and track their movements.

Other Considerations

The other key factors that you need to consider are how to Manage Outages and thresholds, Vendor Management for warranties and updates, and a process for Re-Cycling (For example, what is the process of archiving and backup as related to tape-management, how long do you keep the storage and re-cycle it back into the system). You may have a specific process for recycling Dev, Test, Stage, and Prod environments.

• Describe the requirements to include data, report and performance information contributing towards the overall Program Evaluation, improvement in Business operations and accountability.
• What system generated automation can be run on the storage and provide reports for evaluation and management of the same?
• Describe the problem handling mechanism and process.
• Samples are what if storage fails or is defective – show the triggering events (ex, e-mail or other notifications).
• How do you store storage history?
• Should describe the continual learning, addition of omissions, new mechanisms etc., Describe how it helps in better capacity planning.
• Testing the storage requirements and audit the same on a fixed/periodic basis – schedule for the audit.
• If you are planning to take over an existing storage requirement and in the process of managing it – you would require a Checklist. This is for checking the validity of all assets under storage and based on the details propose desired dates of the takeover.

Authored by Vijay Chander – All rights Reserved – 2023

The post How to build a Storage Management and Operations process first appeared on TekTalk | Project Management Process Tool.

The post How to build a Storage Management and Operations process 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.