What’s the rationale for your technology project?

There are typically one or several underlying reasons why organizations invest in and roll out new technology.

Among these reasons could be typical business drivers such as increasing revenue, controlling costs, improving client responsiveness, or enabling worker mobility.

The project rationale could stem from a single compelling event. For instance, an infamous data breach occurs in your industry and compels your organization to make data security a paramount consideration.

In my last post on Achieving Adoption: Ideas for Keeping Users Productive and Engaged, I explored how nailing something so basic as your project rationale can be a positive influence on rollout and  long-term adoption. I’ve found that organizations quite often do a masterful job of developing a rock‑solid rationale during the funding cycle, only to forget about leveraging it when the project is underway.

A clearly stated and properly leveraged rationale touches every aspect of your project, from which product you select, to how you rollout, communicate, train, and evaluate project success. Most importantly, when users — the ultimate arbiters of project success – understand why learning and effectively using a solution matters to your organization, they are more apt to become personally invested in using the solution properly. Achieving this personal investment puts you well on the way to attaining adoption.

In a perfect world I would be delighted if every technology initiative came with a comprehensive communications plan anchored by a well-crafted rationale. In future blogs we’ll provide access to templates and videos that will help kickstart a communications plan.

But the truth is many small and medium businesses simply don’t have the time or resources to implement a comprehensive communications plan for each technology initiative. As an absolute minimum however, a well-crafted rationale may suffice.

Indicators of a missing rationale

I can always tell when new technology, absent a thoughtful rationale, reaches a user base. The feedback and commentary are the same from Stuttgart to Melbourne to Boston:

“Why are we doing this? We never asked for this.”

“The legacy system worked just fine. This needlessly complicates my job!”

“IT is at it again!”

“I just don’t get the point. I’m not going to use it.”

Don’t blame your workforce if you are getting this feedback. Professional workers are entitled to know why they do things. They chafe at change that seams pointless.

Dos and don’ts

The good news is that building a strong rationale is simple. Here are some do’s and don’ts to help you get started.

1. Do: Craft a rationale that everyone can relate to. Avoid jargon and corporate speak. Here’s a simplified example:

Most of us have personally experienced identity theft or know someone who has. We can relate to how disruptive recovering from this can be. Now imagine how a client might feel after it was determined that we allowed their sensitive data to fall into the wrong hands. Protecting client data is everyone’s responsibility. We must have technology that allows us to effectively work and protect client data. Our current tools and processes fall short. Rolling out X-tech in FY‑’XX is part of a larger initiative to ensure that we keep pace with client expectations.

2. Do: Engage and leverage the management team early in the process. In answering the question about what managers do, management theorist Peter Drucker said two key functions of a manager are to motivate workers and communicate to them. Circulate your rationale with the executive team well before you engage the rest of the workforce. Request their support in reinforcing the rationale to their subordinates at every opportunity.

3. Do: Piggyback on any larger initiatives. Try to develop a nexus between your technology and an overarching directive. If revenue, security, client service, or any other business driver has been stated as key to organizational success, then try to effectively relate your rationale to one of these. 

4. Don’t: Overwhelm users with details they don’t need to know right away. Doing so will step on your rationale, which you want to stand alone. If your project timeline allows it, build a communications plan to tease out details to the workforce at preplanned periods over time. This approach keeps your technology top of mind.

5. Don’t: Rely upon the training event to initially convey your rationale. Doing so means that you’re conveying the rationale and presenting the technology to your users at the same time. For many, learning something new is stressful enough. A user is told to “go to training for the new system” and then it’s up to the poor trainer to communicate the organization’s rationale and present the technology in one sitting–a tall order indeed. Users don’t like surprises. Communicate your rationale earlier and separately.

6. Don’t: Conflate a project rationale with a project charter. The former is a statement (no more than a few sentences) designed to tell your management team and workforce why the technology matters, the latter is a project management tool that can range from a paragraph to several pages and contains a project definition, statement of scope, objectives, stakeholders, and participants. The latter could at best bore and at worst totally confuse your workforce.

Workers want to succeed at their jobs and help their organization succeed. They tend to support new technology when they clearly understand how it helps. The end game for building and propagating your rationale should be a workforce that’s clear and comfortable on why new technology is in their hands on or their desktops.