Transition and Operationalize Incoming Projects

Create a document and release process that prepare the operational and support team to take over project support on launch day.

Analyst perspective

Formalize your project support plan to shift customer service to the service desk.

At some point in every development cycle, a project should be declared to be ready to go live. For it to be released without issue, testing needs to be conducted in all environments and with all scenarios. Testers need to complete the work as expected, on time, and through as many iterations as possible. In many cases this is an impossible dream.

The reality is that many operational and support teams are an afterthought and are not involved at all in the development, testing, and training of products, making it difficult to proactively set up operations and prepare to support end users. Escalations to the development team become challenging and difficult to manage, especially if that team has been immediately reassigned to the next job.

This research walks you through creating a process and template to enable team members to create relevant documentation at each stage and prepare the service team to support the product at launch, ensuring the project can move into business-as-usual support as soon as possible.

Mahmoud Ramin, PhD
Senior Research Analyst
Infrastructure and Operations
Info-Tech Research Group

Sandi Conrad, MBA
Advisory Fellow
Info-Tech Research Group

Executive summary

Your Challenge

• Teams are siloed and focused on getting the work done for which they are responsible.
• The backlog of projects is big, sprints are short and may allow teams to work on multiple projects in quick succession, and expectations for productivity are high.
• When projects are launched, the expectation is that the operations and support team will pick up where the project team left off. However, many assumptions are made, and in the end, the end users feel the impact.

Common Obstacles

• The definition of done may differ among the development team, support team and end users, and product improvements are all seen under different lenses. Are they bug fixes or enhancement requests, and who makes that decision?
• Metrics for each team are specific to their work and do not cross over to the transition phase between them. No one owns the transition phase.
• Documentation may not be a priority within IT overall. It may not exist or may not be centrally located if each team is using different solutions.

Info-Tech’s Approach

• Identify information needed to create a product profile so the operational and support teams can know the product and support it at launch.
• Define appropriate touchpoints at various stages of product development and identify the people best suited to contribute.
• Create a template and make it easy for the teams to fill in standard information with checkboxes and dropdown menus where appropriate.
• Create action plans for operational initiatives, a training program, and an early life or hypercare support program, then move to business-as-usual support.

Info-Tech Insight

Embed transition into the project plan as a strategic phase, with the project manager accountable for its execution. Assign documentation to the teams closest to the work. Look for efficiencies in documentation, transferring knowledge while it’s fresh in their minds and using AI tools where possible. Prioritize knowledge transfer to ensure operations can sustain and extend project value.

To dramatically improve the end-user experience at project launch, embed transition directly into the project plan

Embed transition into the project plan as a strategic phase, with the project manager accountable for its execution. Assign documentation to the teams closest to the work and prioritize knowledge transfer to ensure operations can sustain and extend project value.

Challenge

New projects are launched without advanced notice or preparations for the support and operations teams.

Result

New users are dissatisfied and frustrated with new products, and the service and operations teams are scrambling to catch up.

Why does this happen?

• IT teams are stretched thin and have different priorities and metrics. Project launch quality is not measured.
• The IT teams are only collaborating where mandated for the continuation of the project.
• Once the project goes live, the development team goes onto the next priority and doesn’t receive or act on feedback.

Transition can be a catalyst for improved value delivery

• Define the lifecycle needs for the entire support team and create a guide to enable the team to easily follow the process.
• Create a hypercare support process that improves the launch communications and quality and delights your end users.
• Create a feedback loop that includes acting on known errors and workarounds with a goal to provide continual value to end users.

Project launch quality will dramatically improve, resulting in:

• Increased customer satisfaction
• Faster time to value for new product
• Improved developer productivity
• Improved technician productivity

Everyone in the project lifecycle benefits from an integrated knowledge-sharing process

Regardless of the method of product development and delivery, communicating requirements and working together to create a holistic approach will improve results for end users and technical teams. Start with an awareness of the information and level of support needed. This will improve and create effective communications between different technical groups and will lead to the product, operations, and support teams operating as an integrated, cohesive team.

It’s important to right-size the approach to align to project methods and match the scale of details to the deployment complexity.

• Waterfall deployments will require a large amount of documentation and training prior to launch, and the hypercare period may be long.
• Agile deployments will require incremental updates to documentation and training prior to launch and may have short-term or minimal hypercare needs.

Benefits

• End User

  • Single source for issue reporting
  • Excellent support quality
  • Improved communications
  • Product releases get better each time

• Service Desk

  • Well trained before launch and ready for anything
  • Know what to expect and what requests are new vs. broken features
  • Direct channel to product team for continual improvement
  • Operations are proactively set up for management and resilience on launch day

• Developers

  • Fewer interruptions on day one of the new project
  • Awareness of the needs of other teams and end users
  • Able to transfer knowledge as they’re working on the project while the information and timing is conveniently available.
  • Better insight into impacts of known errors

Guided Implementation

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is 3 to 5 calls over the course of 2 to 4 months.

What does a typical GI on this topic look like?

Blueprint deliverables

Key deliverable:

Project Transition Template

Build the transition template and define process guidelines and ownership for:

• Service priority and service level objectives
• Maintenance and change
• Knowledge transfer
• Policies

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Project Transition Presentation Template

• Define process scope, objectives, success metrics, integration points, workflows, and accountability.
• Develop general transition and communication plan.

Operations Checklist

• Build checklists for the teams that require them.
• Define the guidelines as to who will use the checklist and when.

Transition and Operationalize Incoming Projects

Phase 1

Define Current State and Build a Process

This phase will provide you with the following outcomes:

• Clearly defined challenges and goals
• Template for defining support documentation from the architectural team

This phase involves the following participants:

• Project sponsor and lead facilitator
• Service desk manager
• Enterprise architect lead(s)
• Developer lead(s)
• Operations lead
• Training lead

Think holistically when creating project plans to end the project after transition to operations, not before

At the project level, get a clear understanding of support capabilities and demands, and communicate them to the service desk and operations team to proactively bring them into the planning step.

Inputs for planning and creating new products/services should carry through to operations and support

1. Who is your audience? Is the product/service for internal users or for external customers too? Does testing feed into training and support documentation?
2. What does the product/service do? Does the product have all requested features and integrations? Knowing how the product should behave is critical to knowing if it’s broken or released without full functionality.
3. What are the operational needs? Has the product/service been set up with the right monitoring tools and threshold? Has it been added to the disaster recovery and business continuity plans? What are the backup and storage needs?
4. What are the training needs? Define expectations for training for end users and the support team. Create videos and how-to articles for end users, and schedule walkthroughs and create knowledge articles for technicians.
5. How will the product/service be supported? Define involved vendors and identify expectations for first-level support and all escalation contacts. Define the process to transition from hypercare to regular care.

Consider your current development process and how that enables or challenges support

Is a project really production ready if it can’t be supported outside of the development team?

At some point in every development cycle a project should be declared ready to go live, but to ensure it is released without any issues, it needs to be tested in all environments. This may lengthen time to release. All scenarios need to be considered, and all testers need to complete the work as expected, on time and through as many iterations as possible. Aiming for perfection may delay the release well beyond acceptable timelines, so there is always a need to find the right balance.

There may be multiple tools used throughout the application development lifecycle that store information needed for the next stage of operations and support. However, this information is rarely passed along, and teams may not know what information is available and who owns it.

In many cases projects are released with known errors, some more impactful than others. In other cases, the service desk isn’t even made aware of the new deployment before or during launch. This can create chaos for the service team, the deployment team receiving escalations, and the end users who are just trying to get their work done.

Everyone has goals and metrics that are specific to their function in the project, but often these are not tied together with an end-to-end vision that ensures that everyone in the value chain is preparing for an excellent customer experience. This can be realized through a cooperative, cross-functional approach that emphasizes open feedback loops and continuous improvement, ultimately ensuring a smooth project transition and seamless experience for the end user.

What is your current state?

• Discuss reasons why your current process isn’t working.
• What problems are your end users experiencing? Do you have feedback from product launches?
• What issues do your colleagues have downstream?
• Where is your data stored and how easy is it for other to access and sift through? How annoying is it when you’re expected to stop doing project work to find old notes? Do you prioritize this ask?

1.1 Define the current state and challenges

2 hours

Input: Project information

Output: List of challenges, List of goals, Vision

Materials: Project Transition Presentation Template, Project Transition Template

Participants: Project sponsor and lead facilitator, Service desk manager, Enterprise architect lead(s), Developer lead(s), Operations lead, Training lead

Discuss the good, the bad, and the absence of project documentation. Summarize challenges and goals in the Project Transition Presentation Template.

1. As a group, identify who is impacted by your current project handover process, including customers.
2. Identify document stores and critique the effectiveness of each. Discuss how and where project data is stored today and how easy it is for other teams to navigate.
3. Discuss how these documents and the handover process are working for training, support, and operations.
4. Identify how each stakeholder group is affected by existing methods.
5. Note the areas that are working well to ensure they are not negatively impacted by changes and as a reminder that good things are happening!
6. Identify any potential barriers to success.

Download the Project Transition Presentation Template

Connect the dots between project transition processes and improvements to operations and support

A poorly launched project can feel like a failure if end users can’t get the support needed on day one.

• A project launched without the knowledge of the service desk creates confusion and more reactive work for the development team, who may be scheduled to start something new.
• To provide proper customer service, organizations should involve all parties involved in the design and build phases to collaborate for a seamless transition of projects to the service desk.
• By confirming what information should be cascaded across teams, and added to the transition document, the product teams can start the process of knowledge transfer early and with little extra effort.
• The simple act of creating an inventory and documentation of known errors or issues can improve the decisions surrounding the launch and can result in reduced time for hypercare or warranty support by the design team.
• The infrastructure and operations teams can ensure the product is supported, backed up, and monitored, and they can plan for maintenance tasks as needed.
• The service team can create categories, reports, catalog items, problem tickets for known errors and asset and configuration items.
• In this transition process, knowledge transfer plays a key role. Users, the service desk, and other support teams need to know how the new application or service works and how to manage it when an issue arises.

Info-Tech Insight

Involve the service desk in the transition process via clear communication, knowledge transfer, and staff training.

1.2 Define goals and beneficiaries for an effective project handover

1-2 hours

Input: Project information

Output: List of challenges, List of goals, Vision

Materials: Project Transition Presentation Template, Project Transition Template

Participants: Project sponsor and lead facilitator, Service desk manager, Enterprise architect lead(s), Developer lead(s), Operations lead, Training lead

Determine goals for the project handover. Ultimately the customer needs to see service remain the same or improve, but it’s important to make project handover effective for the technical teams.

1. Look at your list of stakeholders from the previous exercise.
2. As a group, discuss how you can mitigate the issues mentioned and find quick wins in the process.
3. Document your vision for how teams will work together to ensure a smooth transition from project to operations.
4. Identify what improvements should be seen for each stakeholder.

Download the Project Transition Presentation Template

Integrate the service desk into the project management lifecycle for a smooth transition of service support

Service desk involvement in the development, testing, and maintenance/change activity steps of your project lifecycle will help you logically define the category and priority level of the service and enable service level improvement accordingly after the project goes live.

1. Document audience needs, project expectations, and key design elements needed for ongoing support.
2. Record key service level objectives (SLOs).
3. Record key elements that will need to managed and monitored, such as integrations and data transfer.
4. Align testing process with end-user documentation and training plans. Create knowledge articles for known errors.
5. Provide specifications for the operations team to add product into the configuration management database (CMDB), asset management database (AMDB), and storage, security, and monitoring processes.
6. Streamline and shorten transition from hypercare to regular support.
7. Prepare service desk and support teams to support product at launch.

Create a template for the team to fill out at every stage and store centrally for easy access

This template will be used for every project

• Define what information is collected at each project stage and what is necessary to flow through to the operations and support team.
• Identify who will be accountable in each team to ensure documentation is cascaded to each subsequent team.
• Ensure project managers are enforcing the process and building it into their timelines.
• Identify where access rights can allow everyone to access information so relevant documents can be linked. Where access is restricted, require the information to be copied into an accessible document or transferred to a central data store.
• Where definitions, policies, and standards exist, consider listing all the options and letting people check the right boxes to make it easier to fill in the form without having to look up terms.
• Use the developer option in Microsoft Word to add checkboxes, dropdown lists, and more. Enable this by clicking File › Options › Customize Ribbon and selecting Developer on the right-hand side.
• Color-code text to make it obvious where information needs to be filled in; the template uses blue to indicate this. Use textboxes and tables where appropriate.

Info-Tech Insight

The downloaded template will meet many organization’s needs, with customization required primarily for the dropdown menus.

Determine outputs required at each stage of the product lifecycle

Three primary roles and functions exist in a product lifecycle to plan, build, and run the solution. Each role serves a different purpose in how the product provides value to the organization and customers. In the planning stage, the architecture role identifies the customer, expected functions, and value. In the design and build stage, the engineering role ensures the product is fit for purpose and can meet warranty requirements. In the run stage, the operations role provides the warranty to ensure the product continues to perform. Operating level agreements must be in place with feedback loops for continual product improvement.

The product strategy is critical to understanding stakeholders and technical and business alignment

The architecture role determines what solutions and services will meet the business requirements and provide long-term value to stakeholders. Documentation should provide clarity on the service function to ensure the service meets utility requirements and on the view of the customer to better understand how and when they work and the warranty for user interfaces, as well as identifying business continuity needs and integrations with business systems.

When planning a service, you’ll want to ask these questions:

• Who is the product designed for? How would you describe their technical proficiency? What type of device are they typically working on?
• If there are multiple user personas, do they all have the right interfaces for the way they need to work?
• What does their business flow look like?
• What are the warranty requirements for availability?
• Are there any regulatory constraints and reporting to consider?
• Are there any policy exclusions to note or new policies required?
• Who will be accountable for this information cascading to the next teams?

Identify what information is needed to define your product strategy at the architecture stage

Modify Section 2 of the Project Transition Template with the architectural team and operations service representative. Include information gleaned from business users and the architectural role to truly understand service requirements for design, build, and operations. Project name and description will follow the product through to deployment and daily use.

• 2.0 Roadmap — Note frequency of product updates.
• 2.1 Business Flow — Include how the product is used and can include a diagram with modules, related products, and services.
• 2.2 Project Purpose — Describe the reason for the product and who its customers are, including personas.
• 2.3 Service Consumer Personas — Personas tell you about your users, including their technical proficiency, the devices they use, when they use the product, and whether they are internal or external to the organization or both.
• 2.4 Customer Expectations — Define when the service will be functional (business hours) and how it will be classified and prioritized. Drop-down menus are useful here to use standard organizational terms.
• 2.5 Regulatory & Security Constraints — Ensure the right security, privacy, and audit capabilities are built into the solution. These constraints may be critical to future updates, integrations, and user groups and may determine operational needs such as archive and retention requirements.
• 2.6 Policies — Policies may be easier to define if existing standard policies are listed for the teams to choose relevant ones. Or, if all apply, they can be asked to check exclusions and define the reason for the exclusions.
• 6.0 Access Rights — Access rights will vary depending on persona requirements. These have been listed at the end of the document.

1.3 Identify what information is needed to define your service strategy at the architecture stage

1-2 hours

Input: Project requirements and specifications

Output: Defined product strategy

Materials: Project Transition Template Section 2, Product Strategy

Participants: Project sponsor and lead facilitator, Service desk manager, Enterprise architect lead(s), Developer lead(s), Operations lead

Include information gleaned from business users and the architectural role to truly understand service requirements for design, build, and operations.

1. As a group, identify what information is collected during the planning process that will benefit the operations and support teams.
2. Note where the information is currently stored and how and when it is collected. Discuss the optimal time to transfer appropriate information to the workbook and knowledge base.
3. Define who is accountable for ensuring this information is added to the document. Responsibility may be determined on each project as the project team is defined.
4. Use the template as a starting point and modify it to suit your organization’s needs. This group will work on sections 2 and 6.
5. Add the accountable party to each section’s title as a reminder, to ensure each section is filled out for each project.
6. Replace listed policies with your own and link to them for reference.

Document project description and service priority in the Project Transition Template

The engineering/design team will be responsible for most of the documentation as they build and test

The engineering team will document the environment and technical specifications and will confirm costs. They will also be involved in writing documentation to ensure they can support future updates and enable the operations team to further support the product upon release.

When designing a service, you’ll want to ask these questions:

• Who are the key product roles within the design process?
• What vendors participated in the build and will be involved in ongoing support?
• What are the configuration items that make up the product or service, where are they hosted, and what is the structure for disaster recovery?
• Where are the technical artifacts and code stored, and can they be accessed by all relevant technical teams?
• What are security and privacy exceptions and remediations?
• What are the backup, storage, and archive requirements?