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.

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.

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.

Manage Code Repositories

Introduction

In today’s digital age, managing code repositories (source code and associated documentation) are the lifeblood of many businesses. They contain the instructions and blueprints for the software and applications that drive operations, support customers, and generate revenue. As a result, losing access to these critical assets can have disastrous consequences, from downtime and data loss to security breaches and compliance violations.

To address these risks, an Enterprise System Integrator (ESI) will implement a set of policies aimed at safeguarding the source code and documentation of its customers. These policies require deliberate actions, such as regular backups, version control, access controls, and disaster recovery plans, to ensure that the code and documentation are protected against loss, corruption, theft, or misuse.

One of the key provisions of these policies is that the source code and documentation remain the property of the customer, even if they collaborate with third-party Application System Integrators (ASIs) to develop or maintain their software. This means that the customer retains full control and ownership over their intellectual property and can decide how to share or license it with others.

However, this provision also implies some potential challenges and limitations for both the customer and the ASIs. For example, the customer may need to ensure that their ASIs comply with their policies and standards, which may require additional due diligence, training, or auditing. The customer may also need to negotiate the terms and conditions of their relationship with their ASIs, such as the scope of work, the ownership of the derived work, and the liability for any breaches or damages.

On the other hand, the ASIs may face some restrictions and dependencies on the customer’s code and documentation. For example, they may need to adapt their development tools, processes, or methodologies to fit the customer’s requirements, which may incur additional costs or delays. They may also need to collaborate closely with the customer’s IT or legal teams to ensure compliance with the policies and regulations, which may require more communication and coordination.

Overall, the ESI’s policies reflect a balanced approach to managing the risks and benefits of source code and documentation in a complex and dynamic environment. By encouraging deliberate actions and clear ownership, the policies can help mitigate the risks of loss and misuse while promoting innovation, collaboration, and value creation.

Define the code management requirements

The following are the requirements set by the Enterprise System Integrator (ESI) for Application System Integrators (ASIs) to develop source code:

• Utilize and maintain an industry standard-based source code management system following industry best practices for source code control. Approved source code should include the following features:
  • Authenticated access for commits to know who committed changes
  • Authorized access to define access control rights by the ASIs
  • Versioning support – most version controls use incrementing numbers
  • Revision history on files to meet CUSTOMER audit requirements
  • Atomic commits to support multi-file check-in
• Maintain version control for source code assets to support recovery from prior versions.
• Maintain all necessary documentation related to the appropriate source code assets. Documentation should include, but is not limited to, technical specifications, business requirements, change requests, and release notes.
• Maintain appropriate segregation of responsibilities between developers and code reviewers at a level necessary to protect the source code from unauthorized changes.
• Manage deployments consistent with CUSTOMER change management policy which requires CUSTOMER written approval prior to any source code migration to production.
• Protect source code from unintended loss by:
  • Ensuring that production and test code cannot be altered without appropriate approvals
  • Ensuring that backup copies of the source code management system are performed daily and rotated to off-site protected storage.

Define the Unified Code Management Guidelines

1. Code Repository: It is recommended to have a single code repository for CUSTOMER systems that can manage source code across multiple ASIs.
2. Access Privileges: ASIs are responsible for managing access privileges and provisioning access rights for the code repository.
3. Comments and Requirements: ASIs are responsible for providing comments for each commit to the source code. These comments should include links to requirements.
4. Testing: ASIs are responsible for making sure that the checked-in code contains test suites that address the requirements and submit test reports.
5. Continuous Integration: ASIs are responsible for configuring continuous integration (CI) jobs, as mentioned in Section DevOps. This will ensure that the deployed projects run through test suites and are validated before deploying to the application server.
6. Code Quality: ASIs should ensure the quality of code for platform-shared service components only (with appropriate supporting documentation). This can be achieved by conducting code reviews with respective team leads before migrating code to higher environments.

With the above guidelines, unified code management across multiple vendors results in improved code quality, increased collaboration, and easier maintenance.

Version Control

Organizations rely heavily on version control systems to manage their application code base, which is typically spread across multiple vendors. Since considerable effort and time is invested in developing these applications, it is critical to protect these assets. In a multi-vendor environment, IT policies should be implemented to prevent overlap and merge conflicts when multiple resources are working on the same code base. To ensure that source code management systems are effective, they should include features like authenticated access for commits, revision history of files, atomic commits of multiple files, and versioning and tagging. In addition to version control systems, it is also necessary to have a separate build artifact repository to store release builds. To ensure that release builds are protected, they should have authentication and authorization access.

Best Practices

Branching

• The SDLC involves regular releases for almost every project due to bugs or ongoing enhancements.
• Assigning priority to each reported bug helps to keep individual releases stable.
• Complex bugs can cause release delays, which is why branching at each major project milestone is important.
• Running several development threads in parallel can help to avoid delays caused by complex bugs.
• Using branches for each major release can address the above issues.
• Changes in one branch must flow to other branches, but without rules and guidance, propagating changes can lead to instability.
• Unintentional overwriting of existing changes, merge conflicts, and lost updates are some of the issues that can arise.
• Different branching models are available, and the following sections describe these models, their issues, and how to address them.

Trunk Release

The trunk is often referred to a master or main release. On most projects, there is a single code base for all developers which is derived from code repositories. The code base is a piece of software which is produced with a set of files. Every code base consists of a range of individual changes.

Branching out Milestones

Code repositories help in branching milestones which occurs quite frequently.

• It’s a good idea to create branches for major releases to work on development and bug fixing simultaneously.
• Sometimes, new code releases or bug fixes are not initially stable.
• To maintain project timelines, it’s important to keep working on new enhancement requests even while stabilizing production releases.
• To avoid halting new development tasks and changing policy on the code line, it’s recommended to branch the release code line, which usually happens at code freeze.

Hotfix Branches

Hotfix releases are emergency fixes made to production release branches and use code repositories. Hotfix branches should be created from the production release branch. After completing the fix, the changes should be merged into the release and development branches.

Now we have seen the various ways for code repositories. You can build one for DevOps too and draw out similar flows. Check out more of these blogs by checking back regularly.

Authored by Vijay Chander – All rights reserved 2023

The post Best Way To Manage Code Repositories For multiple ASIs first appeared on TekTalk | Project Management Process Tool.

The post Best Way To Manage Code Repositories For multiple ASIs 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.