Summary – TLDR

Digital plan:

  • Supports strategic objectives with digital projects.
  • Defines the technologies, processes and resources needed.
  • A digital vision for improving operations and efficiency.

Precise, measurable objectives:

  • Separate wishes from real needs.
  • Use techniques such as the design sprint.
  • Define a long-term vision and map the user journey.

Building the team:

  • Choosing the right lead matters: an experienced decision-maker dedicated 100% to the project.
  • Build a mixed team: a multidisciplinary development team plus subject-matter experts.

Staying the course:

  • Avoid excessive shifts in priority.
  • Test often and demonstrate quick wins.

Training and change management:

  • Involve users and provide ongoing training.
  • Tailor training to each person’s role in the organization.
  • Put follow-up mechanisms in place and involve leadership.
  • Involve leadership — they will have to communicate and take part in the process proactively.

For those with time to read, here it is.

Strategic planning is a peculiar kind of intellectual gymnastics. Setting a clear, motivating direction that gives you the ability to calmly say no to opportunities that would pull you in two isn’t simple. Managers have to hold the strategic course in order to reach the objectives they’ve set.

Along the way, the exercises used to define that direction generally surface the specific areas needing improvement. Naturally, an organization that aspires to do better has to modernize. It must avoid at all costs listing innovation as an engine of change without ever actually making it real.

The digital plan

Without being an end in itself, a digital plan is generally one more step toward an organization’s digital modernization. It lets you back the organization’s strategic objectives with digital projects. It is, in a way, a technology roadmap to follow in order to make the coming years’ strategic statements real.

The plan specifies the technologies to adopt, the processes to change and the resources needed to reach the company’s strategic objectives. A company’s digital vision describes how it will use digital technology to improve its operations, increase its efficiency and deliver better value to its clients.

All too often, this is where things get complicated.

The steps to reach the organization’s ambitious vision are sometimes long and tedious — much more so than anticipated. There are several questions to ask: where do we actually start? How do we keep the project from turning into the kind of institutional project we hear about in the news? How do I structure my organization for the best impact? Should I make it a product? How do I protect my intellectual property? And where does cybersecurity fit in all this?

Once the strategic planning exercise is over, day-to-day operations catch up with managers who had the best intentions. Often, managers caught in that situation say they should have dedicated a mixed team, entirely insulated from operations, holding both the business and technical expertise; capitalized the project better by setting clear guardrails; taken the Minimum Viable Product (MVP) or Proof of Concept (PoC) to market or into the field faster.

Those are lessons learned that could save you a lot of time and money.

Making the digital plan real

There is no magic recipe for making a digital plan real. It takes will and determination, without ever stepping outside business logic.

Here we put forward a working thesis. It is by no means the only one and it certainly leaves plenty of grey areas. No two projects are really alike. But it can serve as a base, and several lessons learned are scattered through the approach.

1. Define precise, measurable objectives

The crucial part of the initiative is separating wishes, wishful thinking and fashionable trends from what actually generates value for the organization. It would be presumptuous to start writing lines of code or integrating solutions without having laid the project’s foundations and given the team’s effort a direction.

There are several techniques for setting a project’s priorities. We favour the design sprint, a technique invented and refined by Jake Knapp, who works at Google Ventures (GV). It’s worth knowing that the vast majority of GV-funded companies have been through this process.

The steps proposed for defining a project are relatively simple.

  1. Set a long-term objective: define the project’s ultimate vision to guide you throughout the process.
  2. Sprint questions: turn the challenges and uncertainties into questions phrased as “How might we…?”. Problems become business opportunities.
  3. Map it: represent the user journey or the workflow as a map, which helps identify friction points and improvement opportunities. A well-defined map lets the team see clearly where to focus and which parts of the problem are most crucial.
  4. Ask the experts: consult internal or external experts for valuable perspectives and deep insight into the problem. This enriches the collective understanding and makes it possible to validate or challenge the initial assumptions.
  5. Target: select one precise target, the smallest possible, to focus effort on. By concentrating on a single target, the team maximizes its chances of producing concrete, testable results.

2. Build a team

Choosing who carries the ball on the project is a step of capital importance. We see three scenarios far too often on projects like this.

The lead

  1. Handing the project to a manager who already has plenty on their plate. Even if it “makes sense” for that person to own the file given their responsibilities, the reality is that however well-intentioned they are, they won’t be able to carry every file at once.
  2. Handing the project to the youngest, most “tech” person in the group. That can be a good decision if the person is dedicated 100%. But if they aren’t at the organization’s decision-making table, or don’t have enough experience in the field, they will struggle to steer the file properly.
  3. Handing the project 100% to an outside party. Knowledge of the field and of the company’s reality matters too much for the project to succeed that way.

It all depends on the project’s importance, of course. But if the project carries weight and is strategic for the organization, we believe it’s better for an experienced decision-maker to be dedicated 100% to the project for a period of time.

A mixed team

That person will need to bring a mixed team around them. Here, too many companies make the mistake of thinking one programmer can do everything. As in any industry, the profession has a great many specialties. You will certainly need specialists at specific moments during the project. So it’s better to turn to a multidisciplinary firm. Even if it costs more per hour, in the end it will certainly be cheaper than carrying dozens of salaries. That team will need to work with subject-matter experts to reach the expected results. Those experts are the heart of the project’s success. Give them the time to bring the best of their knowledge to the development team.

3. Stay the course

When we talk about agility in programming, we’re talking about a relevant, useful methodology for avoiding major errors. The danger of agility is disorganization caused by too many shifts in priority.

Without turning away opportunities mid-project, you have to hold the course on the vision set at the start. The beauty of programming is also its greatest danger: everything is possible. You have to learn to say no! Even when the ideas are good, even when leadership would like to go here or there, even when a client might like feature X or Y. Managers don’t necessarily see the financial danger of supporting too many different features across too many different applications.

What you want instead is to demonstrate quick wins. To do that, you have to test often. Put the tool in as many hands as possible even if it isn’t finished, to gather as much feedback as you can and adjust the product. Some people will lose faith in you, because they’ll find bugs. That’s completely normal. It’s the reason we wrote point 4: train the staff and manage the change.

By building on wins, where the tool delivers value, it will be easier to consider the next steps.

4. Train the staff and manage the change

Living through change is humanly difficult. You have to be aware of that and live with it. To make acceptance easier, you have to act proactively. We recommend that you:

  1. Involve users throughout the project. Give them standing by asking for their impressions based on their expertise, and act on their recommendations.
  2. Provide simple training suited to their role in the organization, and support them as they use it.
  3. Put follow-up mechanisms in place to assess progress and adjust the strategies if needed.
  4. Involve leadership (internal or client-side) so they understand the rationale behind the project’s objectives. Leadership will have to communicate and take part in the process proactively, including through the harder stretches.

These four points have to be taken very seriously. The biggest risk on an innovation project — for an external product as much as an internal tool — is adoption.

Having the right support

Like any strategic initiative, a technology innovation project carries risk. That can include employee resistance to change, higher costs than expected, unforeseen disruption to existing operations, and technology that doesn’t meet expectations. Those risks are controllable. Bringing in a firm that has been through this process many times is certainly an asset worth considering.

We hope this piece helps you prevent and mitigate some of that risk.