Starting anything new carries risk and uncertainty. This is especially true when starting decision automation projects. Moreover, most practitioners lack a playbook if they are doing this for the first time, and there are unique risks that previous project successes cannot inform. The purpose of this article is to lay the groundwork for how to successfully start a decision automation project. Accounting for all of the project risks early delivers dividends later in the project.

Practitioners might not have a shared baseline on practices, and some team members might struggle to articulate the business value of their approaches. Vendors might not care about these team gaps because they typically emphasize tooling and technology prematurely, without dedicating enough time to defining the business case, discovering requirements, or knowing how it will all fit together. These challenges make it difficult to connect the dots between business needs and implementation, which is critical for success. Moreover, project risks increase when objectives are unclear, rapidly changing, or disputed—especially when insufficient time is spent early in the project where it is sorely needed. The most common risks of a project surface within the first few weeks and are easily mitigated with team building, discovery practices, and sharing. Jumping too quickly into technology and implementation details takes the focus off questions such as:

• Are we focused on the best candidate decision to automate?
• What business case measures can we compare between candidates (impact, North Star metrics, general alignment to other strategic projects)?
• Do we have everyone on the team we need? What skills are missing?
• Are the resources on the team sufficiently allocated to finish the project? Are there any resources in name only?
• Does everyone on the team know why they are on the project, and do they understand the goals?
• Is anyone blocked or uncertain about what we are doing? Anyone doing this for the first time?
• What does “Done” look like? How will we know when we get there?

Acquiring software licenses for an automation project does little to answer these larger questions. In other words, picking a vendor or a technology is a very small part of delivering value to an organization. These questions need to be answered in some form for every project to achieve success.

One: Slow Down to Speed Up

In the early stages of an automation project, there are multiple pressures to move forward quickly. The pressure for early haste is real and introduces one of the first project risks. Project sponsors demand rapid progress toward returns, and software vendors push for a signed license agreement, taking an early bite out of the budget. There simply isn’t time for wheel spinning when the budget depletes. And yet, the majority of risks carried by a typical automation project occur within the first three to four weeks—the types of risks that, if materialized, might cause the project to fail. While many projects fail (I have worked with companies that have failed three times on the same goal), they are just as likely to accept compromised results for the money invested. Where I stand, that is also a form of failure. That said, buying time early in a project creates space for alignment, allaying fear, uncertainty, and doubt.

Two: Find The Best Problem

Every business case carries assumptions and risks. Best practice dedicates just enough time to compare competing problems and associated business cases before spending money. Building solid business cases supports diligence and ensures payback on investments.

The best problem (and associated business case) to start with is the problem the team and stakeholders agree on and can articulate clearly. If the team is newly formed and lacks muscle memory, then having a moderately sized project delivered gets the engine started. There is nothing wrong with this, and there are many other factors contributing to the selection of the best problem. That said, the team needs time to discover candidates to explore scope and impact.

Business problems typically reveal automation opportunities. These opportunities focus on big-picture activities that don’t depend on technology. Instead, the team and stakeholders should work together (perhaps with sticky notes and whiteboards) to map journeys.

While project sponsors may have candidates in mind, additional opportunities often emerge as journeys are explored. A well-constructed journey map details how a process is experienced today, highlighting flaws, their impact on people, KPIs, productivity, cost, and general friction. Automation opportunities often become evident during journey mapping. There’s more in this article on Problem Statements and North Stars.

Three: Carefully Select Team Members

Automation projects depend upon people—often the best in the IT organization. Project teams are more like baseball teams with specific skill sets. Success requires in-depth knowledge of data, processes, logic, and compliance.

Competent SMEs are essential but always needed elsewhere. The challenge is to free them up for the project. A common mistake is to place the name of an SME on a project roster when they already have a full-time job. Moreover, sharing resources such as a SME only works for short periods of time. Key people must be full-time on a project.

As a best practice, list out all of the skills, disciplines, and know-how required for the project, making them a key part of a Go/No-Go decision. Common titles to think about include SME, Data Scientist, Integration Architect, DevOps Engineer, Enterprise Architect, Product Manager, Engineering Lead, Software Engineer, UX Designer, and Program Manager. Marketing tends to inflate and distort the meanings of these titles, so define them locally if necessary.

Four: Discover Risks

Risks typically stem from unwarranted or unvoiced assumptions. Every automation project benefits from discovering and organizing assumptions. The first step is a brainstorming activity where team members and sponsors brainstorm as many assumptions as possible about what they believe is true about the project (scope, timeline, impact, value, people, cost, post-delivery lifecycle, and anything else that could be relevant). A great example of how to do this is covered well in “Lean UX.”

These risks should be prioritized and a mitigation plan put in place for the top candidates. Discovering risks in the form of assumptions is a powerful tool for teams to pressure test their thinking. Unvoiced assumptions can kill a project if a risk emerges without a mitigation plan in place.

Five: Practice Coaching

Most automation projects begin with a high level of uncertainty about the future. Many team members may be inexperienced. If a project must succeed the first time, then it’s a reasonable mitigation to onboard a coach during the critical phases of a project. This person will cover a wide swath of best practices, technical expertise, and business impact. A good coach easily transitions from business strategy to project execution. Sometimes coaching requires specialists depending on the need.

Six: Build Strong Leadership

Every team needs a leader—a “cheerleader.” The qualities of the right person vary; however, they must operate within the value system of the organization, have a history of competent delivery, and be good with people. While they will have a high tolerance for technical language, they must also have the gift of translating team activities into stakeholder-friendly language. They will not waver in the face of adversity and are open to ideas. Above all, they operate with a value system that will guide the team to go-live and beyond. Ideally, this person has deep ties with the business and is frequently working with technical teams on strategic problems. The ideal leaders are big-picture people who know when something is working and when it’s not. Every project will have critical pivots or inflection points. Success depends upon navigating these moments with an open mind and a willingness to make hard choices.

Summary

Acceleration is achieved early in an automation project by aligning, planning, expressing, and mitigating risk, picking the right people, avoiding a premature leap to technical engagement, and finding help when you need it most. Getting started well pays off later. Some might consider these points truisms, yet it’s surprising how many projects go off the rails early.  At best, only some time is lost while leaving the tracks, and at worst, another wreck will enter the lore of the organization making the next attempt less attractive and shrouded in clouds of disbelief.