shopify stats

4 ROI Killers for Productivity IT Projects

14
Jan

You’ve seen it all before.  The organization CIO, CEO or C-whatever-O comes back from a conference and after seeing a whoop-de-do presentation by a technology guru and reading the autographed copy of her book, launches an Information Technology initiative that’s going to change life as you know it at work.  Maybe it doesn’t start that way.  Sometimes the big IT productivity project is part of a well thought out strategic plan and has been talked about for months or even years.  In either case, everyone is focused and energized.

And then reality pays a visit.  Company sales go down and discretionary cash becomes tight.  Times are tough, but the project must go on!  Changes are implemented, systems get put into place, and then…

Nothing.  Nada.  Bupkus.  The flowers aren’t blooming bigger or smelling sweeter.  The sun isn’t any brighter.  And your work life is no better, and in fact may be worse.  People are complaining more about the new “system”, no one knows how to use it and as a result, avoid it at all costs.  Company productivity doesn’t improve, and you look back over the carcass of another failed IT project.

So what happened?

Our business, by and large, are productivity IT projects.  Over the years, we’ve experienced a truckload of IT projects that have gone well, and perhaps an equal amount of them went wrong.  In fact, we’ve been contracted to come in behind failed IT efforts and re-animate the lifeless bodies of technology newly installed in organizations to save the day…and generate the ROI anticipated.  We have certain things that we stress repeatedly before ever starting to increase the likelihood of success.  Since most psychological studies highlight that people are more influenced by pain avoidance than pleasure achieved, we can look at these as things not to do.

For those that are seeking to sabotage their own IT efforts and absolutely destroy the highly touted ROI that your new technology toys are expected to bring, here are 4 surefire ways to succeed in company failure:

1.     Don’t Establish an Effective Plan

Every technology failure or success is 50% technology, 50% other stuff.  This is goal setting as well as an execution plan.  If, in the interest of time savings and being too busy to get key folks together, you don’t get their takes on what they want out of the technology and a picture of what success looks and feels like to them, you already have one foot in the grave.  Without that, some well-meaning people in IT, either your own or vendors, will act and implement according to their best intentions or vague direction that doesn’t provide a complete picture of what should be done specific to your organization.

Often when budgets are tight, we see the planning stage cut woefully short, especially to save money of expensive consultants or time (“Gotta have this now!”).  Unfortunately, you pay for this in spades on the back end.  The old adage I learned years ago at IBM was…

There’s never enough time or resources to do it right the first time, but there is always time to do it again.

Many technologies are very powerful out of the box, but produce vastly different experiences as a direct result of how they are implemented.  We’ve set up over 600 SharePoint portals in the past decade, and every one of them had unique requirements for information architecture, governance, data migration, metadata, workflow and more.  If you try and wing this stage and skimp on requirements definition, you complete the failure daily double.

2.     Have No Success Metrics

Companies that fail with implementing IT projects not only don’t know what success looks like, they have no way to measure it.  Often that means there is no baseline for the current processes that aren’t working, they just feel wrong.  Companies that succeed get in the habit of measuring critical processes, and that very focus starts to make them better.  New ideas, reduction of steps and other improvements are brought to the fore by the people involved, and it becomes obvious when technology is needed in order to get to the next level.

For instance, we implement a lot of Business Process Automation (BPA) or workflow processes that automate things like routings, approvals and dissemination of vital information.  In the work we do with government contractors on Capture and Proposal Management, the energy expended by teams of people to respond to federal proposals is tremendous, yet many still bang away trying to consolidate documents using email attachments and squeezing the life out of Proposal Managers, burning them out with 20 hour days in order to meet deadlines.  This results in a poorer submission document that leads to lower win rates, not to mention higher turnover of staff.  Companies know this isn’t the way to do business, yet often cannot reveal the baseline data on how long it takes for content data calls to be returned, or subject matter expert approvals to take place.  This is a perfect application of technology to automate notifications and track these time lapses.  The firms we see that succeed with higher win percentages know, or at least can provide solid estimates, of these metrics using the old process, and by measuring those after a system is installed (which now becomes very easy), they can constantly tell what’s working and ratchet up continuous improvement.

Evaluate these success metrics at t=3 months after installation, then at 6 months and 1 year.  That evaluation becomes part of the culture and spotlights places where course correction is needed.  It’s important to recognize that all technology projects follow some variation of the graphic below, where initial productivity decreases during the learning phase, and then increases after reaching the nadir of effectiveness as people begin to embrace and improve their work with the new technology.  The trick is to minimize that valley of decline in terms of magnitude and time.  Tracking these metrics provides that focus and get the technology return happening in the shortest possible time.

productivity pic

 

Figure 1-Technology Productivity Curve

3.     No Publicity

It’s funny, but basic change management practice is completely within the control of organizations that are implementing improvement technology, yet is so often the reason for failure.  Publicizing any and all upcoming changes that IT is putting in place, many times, is often overlooked.  There is nothing that is resented more than the feeling that new, complicated technology that impacts work is done has been foisted upon people.  Clearly everyone is not a critical decision maker whose inputs will control the technical direction, but at a minimum all users of the new technology need to be informed of change that is in the works.  This allows people to mentally plan and understand when things are going to take place and how it impacts current projects on their schedules.  This is going to seem like overkill and repetition, as no publicity isn’t the norm for companies, but inadequate publicity is.  Saying it once in a corporate email is not enough.  Newsletter briefings, more emails, roundtable discussions—all of these reinforce the importance of the technology to everyone involved and dispel the belief that the entire thing may simply be someone else’s problem.

4.     Cut Training Efforts

This may be the biggest cost-savings effort that organizations take (often because software licensing and other costs are so large) that almost guarantees failure seen by lack of adoption and standardization.  It leads to bad technical deployments too.  Imagine turning your 16 year old teenager loose on your family sedan after giving him a book on driving with no lessons from you during ride-alongs or classroom training.  What could possibly go wrong?  As much as we want employees to help us save cash by going the self-taught route, this never works and costs much more than it saves.

We have seen this many times during Portal implementations using SharePoint.  Users with no clearly defined rules of engagement and ways of doing things begin setting up siloed departmental sites according to the ways that make sense to each of them.  Trouble is, rarely is that consistent across users, leading to inconsistent metdata structure and ineffective enterprise search capability where people in the organization can’t find anything they didn’t personally file.  Kind of defeats the entire purpose, eh?

Sooner rather than later the lack of formal training results in near complete lack of adoption of the new system for anybody who didn’t already know the technology before you brought it on board.  They either won’t have time in their busy days to teach themselves, or will become so frustrated with the cluster that the system becomes that they avoid using it.  At a minimum, this extends the bottom of the technology productivity curve in Figure 1 much longer than is necessary.  Worse, people simply abandon the improvement technology and go back to the old, comfortable and known way of doing things that you were trying to replace.

Do you have more ways to kill your productivity project ROI?  Let us know what they are and how you overcame them.