Technology Introductions – don’t try this at home.

“Never, never, never believe any war will be smooth and easy, or that anyone who embarks on the strange voyage can measure the tides and hurricanes he will encounter. The statesman who yields to war fever must realize that once the signal is given, he is no longer the master of policy but the slave of unforeseeable and uncontrollable events.”   ~Sir Winston Churchill

  http://amzn.to/2E36sCg

Keys to success #1 – Don’t underestimate the effort required

Whilst Sir Winston Churchill was referring to war, his warnings are accurate for Information Technology Projects.  Change failure in technology is legendary, (as are the volume of articles that follow IT failure!).   I am convinced most organizations do not look back far enough into the project to determine the roots of failure.  Most IT projects are viewed as beneficial to the organization and likely to succeed.  Optimism is fueled by a belief that profit is just around the corner.  Yet, a major source of failure is often overlooked. Executives, overwhelmed with stars and dollar signs in their eyes, neglect the key thing that will make the project a success: “what are we getting ourselves into?”  For the sake of expedience, they neglect serious Due Diligence.

Keys to Success #2 – Due Diligence: Preventing Unintended Consequences

Although an Information Technology project may not be part what we do every day, the systems themselves most likely have an impact on what we do to a greater or lesser extent, depending on our daily work.  Here’s the Point: Lurking in the background of every IT/System project are unforeseen consequences that occur by tampering with the heart of an organization.

Find a software engineer who loves the details. Treat them well. Feed them well. Care for them. And tell them to go find the mystery interfaces lurking in the background.  You’ll be glad you did.

Here’s an example: Suppose you want to change a system that fills orders for clients. A client orders something on the web and they expect to get it shipped to them. Now suppose you want to change that system … sounds simple, right? People then flock to a meeting where PowerPoint slides show how the new process will work. Heads nod in agreement. More slides show the dramatic improvement the new system will provide. Heads nod with greater energy. Finally, the Return on Investment looks very strong, and the leaders nod with approval. The project is launched with great aplomb. The energy and enthusiasm are contagious … at least at first.

But here’s the caution: Without effective Due Diligence, the clock is ticking on an unintended discovery that could likely bring the project to a grinding halt.  It’s not complicated – it just takes hard work to discover what you need to know to be successful.

To guide your Due Diligence, here are a few simple outcome questions (as opposed to geek speak).   They must be answered in detail!

1 – Who uses the system?
2 – Who supports the system?
3 – Who feeds data TO the system?
4 – Who receives data FROM the system?
5 – Who gets reports from the system?
6 – How old is the existing system?
7 – Are there data feeds specifically designed to have an old system talk to a new system? (These are often so deeply hidden no one can find them until the systems don’t ‘talk’. Very likely, they were built by someone who retired in 1980.)

These are just a few of the questions that should be asked (and answered thoroughly!) during Due Diligence.

Why don’t organizations take the time to do this?

1 – Generally, by the time the project is being presented to the organization, commitments to savings (in the next year? quarter? month?!) have been made. Those commitments have been registered, documented and remembered by a savvy finance person.
2 – The enthusiasm to get going outweighs the boring effort required to dig deep into the system’s parts. Novelty will always win over tedium. Count on it.
3 – “We know enough … let’s get started.”
4 – Details are overlooked because of expediency.

Pay me now, or pay me later. Truer words were never spoken.

As a leader, you cannot afford to overlook this key activity in your project. In the end, proper Due Diligence can save tens of thousands, even millions of dollars as you implement your new system. The missing component in large IT projects is a serious commitment to diagnosis, including diagnosis of (1) the magnitude of the change, (2) expectations of what the change will bring about, (3) systems linking to a primary system [system integrations] and (4) the pain of the ‘societal’ aspects of the project.

Find a software engineer who loves the details. Treat them well. Feed them well. Care for them. And tell them to go find the mystery interfaces lurking in the background.  You’ll be glad you did.

Keys to Success #3 – The Information Technology Consultant

IT Introductions are major investments in time, dollars, human energy, and business opportunity costs (the things you can’t do while you’re doing something else).  These investments are often mission critical systems, forming the DNA of the organization. They are data repositories, systems for order management and fulfillment, customer contact systems, and telephony interfaces. Clearly these projects can have a dramatic impact on organizational performance.

Given the major challenges of these IT introductions, organizations often use external consultants to advise and provide everything from project management to change management. External consultants have the expertise and they can staff up or down, depending on the needs of the project.

A few considerations:

IT consultants are not part of your organization – that’s a double-edged sword. They will take up much time learning what your organization does and that translates into $$$, Euros, Pounds, Yen … name your currency.  Not being part of your organization allows them to push and say things internal people may not feel comfortable addressing. That’s a good thing, and a key lever to use during organizational change.

IT consultants, however, will not be working for your organization after the project is done, at least not for a while. They are not as invested in the outcome as you are. They can leave; you remain.

During the sales process, IT consultants are likely to provide a glamorous view of projected savings, improved revenues, employee satisfaction, and myriad other benefits. This is normal and natural, but … their projections may not be realistic. I haven’t seen companies check out the BEFORE and AFTER effects of an IT implementation, comparing initial projections with actuals. You may want to consider that in your assessment and especially in your contract.

Finally, most IT projects run over on time and cost … it’s a fact of organizational life. When push comes to shove (and it often does) IT consultants will want to cut time to reduce cost. That’s not a bad idea, but it can cause problems if they cut critical process analysis steps.  I’ve seen it and it isn’t pretty.

Cutting the Wrong Corners Can Lead to Disaster

Organizations don’t do massive IT projects every day, and thus they need the assistance of IT consultants who can manage the details. A bit of caution is in order. Take the time to understand the relationship you have with the consultant, set careful boundaries and expectations. After all, they are working for you!

IT Projects and our day jobs – Keys to Success #4 – Our participation

We all have ‘day jobs’. That is, we work in finance, procurement, sales, human resources, and operations, among other roles.   When a major IT System change comes into our organization, sometimes we’re asked to join a team to help implement the new System. From a Change Management perspective that’s a great idea because it is critical to engage multiple stakeholders in the process to ensure a complete implementation. Organizational participation is critical to success.

But let’s go back to the day job for a moment. Our finance, procurement, sales, human resources and operations roles do not prepare us for the grueling details of IT/System implementation. Even the most savvy among us may find themselves bewildered by the project.

Here are a few reasons:

  1. We are brought together around levels of complexity that may boggle the mind a bit!  And what about the ‘day job’? Although we’re often flattered and intrigued by being selected to support the project, we have concerns about our current job.
  2. We’ve been asked to commit hours, days, maybe weeks and months to the project.
  3. We have other priorities to manage.
  4. We’ve heard the project has been attempted before … and failed.
  5. We’ve heard we have to travel, adding further complexity to an already busy schedule.

There’s risk in our participation
We are exposed to a brand new language.  There are new terms we need to learn.
So what can we do to be successful when invited to participate? Here are some tips based on my experience with IT/System Implementations.

  1. Work with our teams to delegate responsibilities to open bandwidth for your participation in the project.
  2. Gain a clear picture of our involvement – what are the expectations for time, effort, project deliverables?
  3. Ask for clarity on our level of influence – do we have the right to question process or protocol when it seems like things are not moving in a good direction?
  4. Learn the terminology, as painful as that may be. Meetings are difficult – meetings with non-stop misunderstood complex technical terms are impossible.
  5. You and I have a day job.  Our organizations want us to invest very heavily in a new system to improve performance and it’s to our benefit and the benefit of others to improve, so get on board and help. Just take the time to ask some questions early in the process to understand what you’re getting into.

The benefits? A central system brings together the component parts of our complex organizations. An IT implementation can teach us how the pieces fit together. In the long run, that knowledge can help build your career. But don’t be fooled – it’s going to take a lot of hard work.

Keys to Success #5 – Managing Scope

Occasionally, the film industry will produce a comedy about something that started small and turned into a nightmare. If they did a film about an IT/Systems project, it would probably best fit in the Science Fiction category, and the biggest reason is ineffective management of scope.  There are lots of terms for this, most notably ‘scope creep’ (which is an interesting double entendre, don’t you think!?)

Managing scope is a notoriously difficult problem for several reasons:

Let’s fix what we’ve never fixed!

When word gets out that a new system is being implemented, managers often see a way to resolve the chronic issues that have plagued the organization for months, years … even decades. It sounds like this … “As long as we’re doing ABC, let’s add XYZ.”

While scope is generally established at the beginning of a project, odd things appear during Due Diligence (which in my mind should be done well in advance of project start up). The whereabouts of Jimmy Hoffa (an infamous American union boss) were in the news as this writing because of the mysteries surrounding his death. There’s an analogy here for IT/Systems projects … some hidden system will present itself at the wrong time, causing scope creep.

Although people start with a clear view of scope, it is inevitable that new discoveries will cause change and additions, typically in terms of system interfaces developed long ago.

Beware the Infiltrators

There is a subtler reason scope is often increased — those who truly are opposed to the project will add scope, giving the appearance of interest and participation, all the while subverting the project by adding layers of demanding complexity that will ultimately sabotage success. And then they’ll say “I told you this wouldn’t work.”

What to do?

Every two-year-old kid has one very powerful word: “No.” Why not use that as a lever?  Have the person who adds scope articulate the impact to the project, in terms of dollars, human cost, opportunity cost, project delays and additional consulting fees. While they may have a valid reason for adding scope (improved ROI) it’s a real good idea to get a sharp understanding of what the addition means, and that they’re committed beyond their criticism.

Stay alert!

Be wary of someone who says you’re not a team player if you won’t add scope.
It takes managerial discipline and courage to set very hard boundaries around a project – but it is one of the best ways to ensure project success, to finish on time and within budget.