Improving Project Hand-Off

• April 29, 2021
• Steve Greenblatt

When is a project complete?

For some, completion is defined by satisfying requirements, receiving a sign off, or achieving client satisfaction. Although completion signifies a finish line associated with contracts, scope of work, payments, and a transition to move from one commitment to the next, completion of an installation simply marks the next phase in a project’s lifecycle. For integrators or consultants, the culmination of a system installation may be their last involvement. For end users and technology managers who support them, it marks the beginning of a journey and the first day of system ownership and usage.

In AV, most projects have distinct phases that are critical and require synergy; however, they are not always planned properly to have a seamless transition. While there are times when the same organization or team will design, develop, implement, and test a solution, it may not be the same resource for support, maintenance, and upgrades. Therefore, there needs to be a plan in place for continuity of service and support. When a technology manager assumes responsibility for a system that they didn’t design, develop, or implement and are tasked with supporting it, they run the risk of struggling to be effective without proper planning and preparation.

For simplicity, let’s presume that a project is limited to two phases that are delineated by pre- and post-client usage. (As a note, this can be different from client acceptance or completion of implementation. That can be discussed another day.) “Day One” would include the installation, commissioning, and testing leading up to substantial completion and turnover of a working system. “Day Two” can be defined as the ownership of the completed product, production usage of the system, support of users’ needs, and maintenance of the system to ensure operation.

The critical importance of a bridge between Day One and Day Two can often be overlooked by both technology managers and AV service providers. In the waning stages of a project with the finish line in sight, it is common to lose focus on the last 5 percent of requirements, needs, or open items. It is human nature to be looking ahead at the next commitment or opportunity as well trying to conserve time to protect project profitability that can be easily eroded. However, it is also critical to maintain focus and ensure a responsible and successful handoff between implementation and support. This step can be a difference maker on a technology manager’s ability to support users as well as the client’s overall satisfaction with the project and installation team.

Although Day Two needs can last indefinitely and Day One has a start and an end, there is a disproportionate amount of planning that goes into each phase from the onset. While there is typically an elaborate process for defining the requirements of the project, presenting a design and specification for bid, vetting a contractor to provide the implementation, negotiating pricing, and deploying the solution, little is discussed regarding what will happen when the initial scope is complete. When the dust has settled and the client is left to take ownership of what they received, some may be in a successful position to step in and effectively use and maintain systems without a hitch. On the other hand, others may be challenged by the complexity of the technology, the unfamiliarity of the installation, or the inability to get up to speed quickly with a basic handoff. What may be a time to celebrate the pinnacle of completion for an integrator and consultant may also the beginning of a challenging and frustrating jaunt for the technology manager or team responsible for supporting the systems that were recently completed and turned over. If the baton is not effectively passed from Day One to Day Two, there will be significant challenges no matter how good the quality of work and effectiveness of the project implementation. In some cases there are plans for support by a third party; however, unless they are staffed onsite and engaging regularly with users, it is critically important for technology managers who work for the end-user organization to be knowledgeable about how systems operate and proficient with how to provide support in the times of need.

Aside from the need to be comfortable with the system operation themselves, technology managers have a responsibility to support users through a variety of means including training, offering on-demand helpdesk support, and hands-on troubleshooting when issues arise. As systems are used more regularly, familiarity will increase, as will confidence in system performance; however, over time issues will arise varying from identifying defects to break/fix maintenance requirements, to addressing changing needs of users and support staff.

The value of system usage and user feedback can also lead to the realization that the actual application or workflow that was intended for the system may differ from what was understood during the system design or implementation. Especially when dealing with custom solutions, the ability to fully define all the requirements and the specific details of the final product upfront can be challenging, thus a plan for post-turnover support becomes critical to ensure long-term success. In some cases, this Day Two plan is simply a break-in period of 90 days where the integrator or service provider supplies a round of user preference changes made to the system based on feedback. These changes can come in the form of adjustments to nomenclature, button placement, automation timing, level settings, or alerts. Longer-term options for Day Two support may include an annual agreement with an integrator or service provider to address ongoing needs and provide quarterly updates to help maintain system operation and refine functionality to best suit both the needs of the user and operator. In software, this is commonly known as “iteration” and refers to the process of releasing a deliverable and providing refinement based on client usage, feedback, and feature requests. This can be a very valuable process and prove critical to hitting the mark and ensuring long-term success and satisfaction.

There are many ways to help ensure that technology managers are in the know about the systems they own, and ultimately need to support and maintain. Here are a few strategies:

The ideal situation has technology managers being involved in defining the requirements, designing systems, and providing detailed direction on the system functionality and operation. When that is not the case, participation in project meetings, taking an active role in discussing system operation, and carefully approving functionality prior to implementation can be a great starting point for ensuring comprehension and a favorable outcome.

Identifying the Day Two person or team responsible for running or supporting a room or collection of systems during the early stages of the project can significantly increase the chances of their comprehension and comfort level with the systems when they are turned over. Going further with this idea, having this same support person or staff take an active role in witnessing the system installation, commissioning, troubleshooting, and testing can go a long way toward establishing familiarity with the systems, as well as having confidence that the final product will be manageable and easy to support.

One of the trickier areas for support, maintenance, and updates can be the software-driven device and more specifically, programming or configuration of system functionality. Unless the programmer who has authored the control code or audio DSP files will be retained to support, troubleshoot, and maintain the software aspects of the system, it is important that the details of software approach, comfort level with the coding style, and availability of comments and documentation accommodate a successful handoff and facilitate effective support and future modifications. Should the programmer who is taking over the programming be unfamiliar with the language used, be uncomfortable with programming approach, or unable to decipher the code documentation, they will struggle in addressing troubleshooting, maintenance, and upgrade needs.

Since it is a fact that all systems will change over time, it is important to be comfortable with what it will take to make changes. For some, this may involve a relationship with the integrator or service provider who originally provided it. In situations where technology managers are self-sufficient, there is less of a need for concern. However, in all cases it is critical to maintain good habits of updating drawings, documenting revisions, establishing a change and maintenance log, managing source code versions, and following best practices and stewardship.

Regardless of whether technology managers are acting as in-house integrators, where the transition between Day One and Day Two may naturally present less of a challenge, or whether a systems integrator is involved where a clean handoff can be critical, it is still important to be planning for Day Two needs as early as the project’s inception, design phase, and Day One kickoff. Efficiency, effectiveness, and end-user satisfaction only comes with proper planning and execution.

Steve Greenblatt, CTS, is president and founder of Control Concepts, a provider of specialized software and services for the audiovisual industry.