Structured Innovation: Change Management Processes for Innovation Professionals

Process Makes Perfect: A Builder’s Guide for Tech Rollouts

This article is written by Karl Sorensen. As Director of Construction Technology and Innovation, Karl uses his expertise to optimize the project delivery process at Mid-Atlantic general contractor DAVIS Construction. His unique role allows him to elevate operational efficiencies while developing new processes that encourage team members to continue redefining the construction experience. With 16 years of industry experience working for commercial, residential, and federal builders across the United States, cultivating a passion for digital transformation and generating new ideas, Karl has learned to resolve long-standing industry challenges with progressive and innovative ideas.

This is part of our innovation best practices series focusing on providing and explaining key skills required for new innovation team members or those starting new teams by showcasing industry best practices.

---

Understanding your Customer

The longer I’m involved with construction technology and innovation, the more I wonder if I should’ve minored in human psychology. Change management, which is at the heart of organizational innovation, is not just about technology, it is about people and the motivations that drive them.

While each construction organization may define innovation and innovation roles slightly differently, the same core tenets remain true:

• Innovation is primarily viewed as people, process, technology (in that order).

• Innovation seeks to find solutions from problems, and not problems from solutions.

• Success relies upon the improvement of objective metrics and subjective experiences.

One of the reasons that I joined DAVIS, and more generally, remained in the industry innovation role, is for the positive influence I might impose upon project delivery. My focus is not merely operational efficiency, although incredibly important, but improving jobsite experiences of the front-line workers who are performing the work; my customers.

My first encouragement to anyone who is looking to innovate is to first know your customer; know their name, know their market sector, know their work, and know their goals. Even if there is a clear objective, each persona will have their own unique perspective of the problem and how to define success.

For example, consider how different personas view the same challenge; timely material procurement:

• A superintendent is concerned that untimely material delivery could cause impacts to jobsite production and work sequences.

• A project manager is concerned that untimely delivery could cause schedule delays, uncomfortable conversations with the owner, and a chorus of change order requests.

• A project engineer is concerned that untimely material delivery could be the result of their lack of planning, stemming from approved submittals and buyout coordination.

• An owner is concerned that untimely material delivery could impact milestone dates and postpone operating revenue.

• A trade partner is concerned that untimely material delivery could lead to extra storage costs, site logistic headaches, or damaged material on-site.

Put plainly, a “one-size-fits-all” approach is not effective for change management. So whenever a problem must be solved, understand the full scope of the problem by understanding each of the customers that this problem affects and the specific pain that this problem is causing.

Once you have a clear grasp of the customer’s needs, it’s time to approach innovation with structure. This is where a methodical change management protocol becomes crucial.

Structured Innovation

I have received my fair share of industry pushback to “structured change”, citing that construction is too nuanced or too specialized to have standardized change management. In my opinion, however, if surgeons can create their own standardized pre-operation and post-operations checklists, despite every patient being unique, construction can, too.

It’s been my approach to segment change management into four phases:

• Study/discovery

• Pilot

• Phased rollout

• Production (or Enterprise Rollout).

In this article I’ll explain how we approach each phase of the change management process for the rollout of a new technology, including highlighting key considerations for innovation managers and helpful resources to use at each stage. The goal is to provide a training document / checklist which can be referred to consistently with links to helpful resources and collateral materials.

---

Contents

• Study / Discovery

• Pilot Phase

• Phased Rollout

• Production (or Enterprise Rollout)

• Helpful Resources

Reading time: 8 mins

---

Study / Discovery

The first stage of the innovation process is study and discovery. This is where we investigate, define, and scope problem statements from across the organization.

At this stage it is important to accept all inbound requests for innovation (so as not to stifle innovation), but there must be a clear and established criteria against which each problem must be assessed. Some companies may even require business cases to accompany each innovation request, as to encourage each submitter to thoroughly evaluate and qualify their own requests.

As Prakash Senghani has written here before, the innovation criteria is a framework developed when defining the vision of an innovation program. It allows us to examine and prioritize all of the innovation program initiatives against the company’s strategic priorities. To effectively rank priorities, it is important to complete first a quick pass on all inbound initiative requests to rank those further exploration.

Once we have ranked the highest priority based on need and impact, the next step is to define the problem, quantify and re-prioritize it to help inform a go/no go decision. When undertaking the detailed review of the initiative, key considerations and questions to answer include:

Considerations

1. Who are the internal/external subject matter experts that have relevant knowledge?

2. Was this challenge researched previously? If so, can I reference previous artifacts or decisions?

3. Can this challenge be mapped? Consider using a Business Process Model and Notation (BPMN) methodology to help visualize the whole process.

4. How does this challenge/opportunity compare with other competing priorities?

5. What is the go/no-go criteria and who makes this decision?

With this information we will have a holistic understanding of the problem including where it ranks and the key stakeholders. If we move to progress to the next stage, the next steps will be clear based on consideration #5.

Helpful Resources

1. Defining the Problem: A3 Criteria, BPMN mapping

2. Quantifying the Problem: ROI, Risk Assessments, Costs of Not Changing

3. Prioritizing the Problem: RICE Methodology

*See resources sections for example documents

Pilot Phase

Once we have reviewed and studied the most promising initiatives, these initiatives will be scheduled with available resources. If there are more initiatives than available resources, then initiatives may be shelved until future years, otherwise, hiring (or subcontracting) additional resources might be essential.

Generally speaking, and depending on the size of the initiatives and organization, only a few formal pilots (2-5) should be pursued in any given calendar year.

This tends to be the golden number as (depending on the scale of your organisation) having too many pilots can run the risk of creating organizational change fatigue or burnout. Being stringent on our innovation criteria and ranking system, allows us to define which projects should advance beyond Study/Discovery.

Key goals during this phase are to:

• Define the pilot scope (including timelines)

• Identity success metrics

• Find a pilot team (and aligned project)

• Set expectations with your pilot team and tech vendor (kickoff)

When setting up an official pilot, innovation managers should make the following considerations:

Considerations

1. What is the criteria I should use to choose a solution to pilot? Should I pilot one solution or multiple solutions, concurrently or sequentially?

2. What is the scope of the pilot? Include answers to questions such as what is the pilot to achieve, who is the pilot team, how long will the pilot run, what success criteria must the vendor achieve?

3. Is there a cost for piloting? Who will carry this cost? What kind of agreements need to be in place (contract, NDAs, etc.)?

4. Is the pilot team appropriately oriented to use the solution? Are their expectations appropriately set?

5. Is the tech vendor’s expectations appropriately set? Do they understand the scope and boundaries of the proposed pilot?

Helpful Resources

1. Defining Pilot Scope
   At DAVIS, we create a Request for Pilot (RFPi) which consolidates pilot specifics into a concise document which is then given to the technology vendor. From there, I am able to align expectations with the vendor, ensuring that the correct scope is deployed and correct metrics are pursued.

2. Identifying Success Metrics
   What does success look like and will you recognize it when you see it? Discuss with your customers and end users the characteristics of success. Note, “success” is not defined by whether the product moves into production, rather, you have uncovered sufficient information to make a product decision.

3. Finding a Pilot Team
   Identify end users that feel the pain of the problem you’re trying to resolve. These team members will be the most eager to test new solutions and provide the most detailed feedback.

4. Conduct Pilot Orientation
   One key step that is often overlooked by innovation teams is pilot orientation. If you request that pilot users test a product, but don’t appropriately train them on the product - you might not get the feedback you need. At DAVIS, we create a clear checklist of actions we want our pilot testers to complete, training them on how they can complete the checklist with the new product. Along the way, we will answer questions and make sure our pilot teams are completing their pilot checklists.

credit: Rick McCleary

Phased Rollout

Once a pilot solution has satisfied success metrics and achieved the organizational buy in, it will move to the rollout phase. A “partial”, or phased rollout (as compared to an enterprise wide rollout), is oftentimes preferred because it allows for us to advance the tech adoption process and continue testing, while still leaving us an easy opportunity to exit the relationship.

In a phased rollout, we deploy the solution to a larger testing group (market sector, region, department, etc.) for an extended period of time (1 year or less) with preferred pricing, while increasing the demands of the solution. This allows us to ensure the solution can scale and perform at a larger scale without the risk of being fully committed to a new product.

Key goals for this stage are:

• Negotiating a partial enterprise (or bundled) agreement

• Identifying success metrics for phased rollout

• Setting up the software environment to accurately reflect organizational needs

• Creating/Reconciling workflow standards to align with product capabilities.

To achieve these goals, innovation managers should consider:

Considerations

1. Can I use the feedback from the pilot phase to improve the product/market? Can I use pilot feedback to negotiate a better MSA?

2. Who should receive licenses in a partial rollout?

3. Which technical team members are involved and can they assist with data ingestion (or migration), solution customization, and integrations? What kind of cybersecurity standards need to be met to protect our data and our clients’ data?

4. Have I defined a rollout schedule and communicated this to the vendor and end users?

5. What kind of department best practices and standards need to be set?

6. Can the technology vendor support the increased number of users and their demands?

Helpful Resources

1. Negotiating Partial (or Bundled) Agreement
   At DAVIS, we’ve created a MSA Checklist to evaluate each technology vendor contract. This checklist ensures that we mitigate risk, set the appropriate expectations/standards, and receive our desired solution.

2. Identifying Success Metrics
   See previous section.

3. Setting-up the Environment
   When setting up the environment, it is important to work alongside the IT and data teams to create data integrations, set data standards, and perform data ingestion. Additionally, collect the appropriate software compliance certifications to mitigate risk and satisfy data integrity (SOC, FedRAMP, CMMC, etc.)

4. Developing Workflow Standards
   In addition to technically setting-up the environment, it will be equally important to functionally setup the environment. Engage with end users and department heads about how the solution ought to perform and set workflow standards.

Production (or Enterprise Rollout)

After the pilot and/or phased rollout stage(s), the innovation team should have sufficient information to decide whether the solution should be rolled out across the entire organization.

At this point, there should be a strong relationship between the technology vendor and client, good product/market fit, as well as strong acceptance by end users. If each of these are satisfied, it may be a good idea to negotiate a long-term agreement (1-3 years) with the solution provider to ensure that a solid partnership can be formed. In some cases, it might be beneficial to negotiate an even longer agreement to establish a true long-term partnership.

Key achievements during this stage should be the same as the Phased Rollout, with the addition of:

• Finalizing internal handoffs

• Establishing internal resources

• Scheduling recurring check-ins.

Consider Asking these Questions

1. Can I use the feedback from the phased rollout to improve the product/market fit? Can I use feedback to negotiate a better multi-year MSA?

2. Have I validated data flow, customizations, integrations? Have I identified who owns the data, who enters the data, and who is accountable for the correct data?

3. Does the product comply with organizational cyber-security standards?

4. Have I created and deployed training through my LMS platform? Where can I store training resources in-house?

5. Who is responsible for approving new feature updates? Who is responsible for responding to internal questions about the product? Is there an internal business owner and technical owner of the solution?

Helpful Resources

1. Internal Handoffs
   From a scalability and scope standpoint, it doesn’t make sense for the Innovation Lead to stand involved with the product beyond rollout. If an end-user and technical lead (IT) are identified, they will now be responsible for meeting with the vendor CSM, evaluating product/feature updates, and training team members.

2. Internal Resources
   Now that this solution will be living indefinitely at the organization, it will be important to create internal resources (trainings, job aids, etc.) for team members to reference and use. Unless the organization is willing to personally train each new hire, creating internal, accessible resources will be key.

3. Recurring Check-Ins
   Not quite as often as other phases, scheduling a 3-month, 6-month, and 12-month check-ins with the vendor and end users is helpful to make sure success metrics are continuing to be achieved. Beyond the initial year, check-ins can be reduced to yearly (or whatever cadence best serves the team).

The key to successful innovation in construction lies in understanding the human aspects of the process and following a structured, methodical approach to ensure that new technologies are not only adopted but are also integrated effectively into your organization. By continuously engaging with stakeholders and refining your approach, you can drive meaningful change and achieve long-lasting success.

---

Helpful Resources

Business Process Diagram

A3 Process

Popularized by Toyota, A3 is a structured problem-solving approach for continuous improvement, named after the A3 paper size (11” x 17”). Karl Sorensen has modeled his A3 worksheet from the Lean Enterprise Institute and concepts created by John Shook, author of Managing to Learn, Using the A3 Management Process.

---

This article is written by Karl Sorensen. As Director of Construction Technology and Innovation, Karl uses his expertise to optimize the project delivery process at Mid-Atlantic general contractor DAVIS Construction. His unique role allows him to elevate operational efficiencies while developing new processes that encourage team members to continue redefining the construction experience. With 16 years of industry experience working for commercial, residential, and federal builders across the United States, cultivating a passion for digital transformation and generating new ideas, Karl has learned to resolve long-standing industry challenges with progressive and innovative ideas.