paulchinonline.com

The Soft Costs of Intranet Failure

By Paul Chin

Originally published in Intranet Journal (29-May-2008)

back back to portfolio


Remember the story about the boy who cried wolf? It was about a shepherd boy who entertained himself by repeatedly crying out that a wolf was threatening a herd of sheep. Villagers would come running to the boy's aid only to discover each time that the boy was playing a prank on them and there was no wolf at all. Eventually, a real wolf came by and gobbled up the boy because the villagers ignored his cries, believing that it was another prank.

Intranet developers who cry wolf too many times—failing to deliver their proposed system, failing to provide requested upgrades, or failing to fix bugs—can raise the ire of users and cause them to stop responding to their announcements. These accumulated failures are very costly not only in terms of dollars, but also as a matter of perception.

When we attempt to measure the consequences of any project failure, either casually or through a formal post-mortem process, the hard losses are always the most evident and quantifiable. How much money did we lose? How much time did we waste? But aside from the obvious losses associated with the financial cost of equipment and software, and the time used for planning and development, the damage created by other's negative perception of the intranet development team can greatly devalue it—not to mention the intranet team's own sense of worth.

Although soft losses aren't as apparent at-first-glance, they are far more difficult to repair than hard losses. With each failure and unkept promise, the possibility of future system success is greatly diminished. Three of the biggest "soft" consequences of project failure include:


Loss of Developer Credibility and User Trust

Intranet developers promise all sorts of things in order to satiate hungry users looking for easier and better ways to do their job. But developers' ability to follow through on these promises vary depending on the complexity of what needs to be done and the developers' ability to carry it out in a given time frame.

The danger here comes from raising the expectations of the user community—especially if a specific date is announced for the deliverable—and then failing to meet these expectations. Do this too many times and users will eventually treat everything the intranet team says as background noise, and accompany this reaction with a rolling of the eyes and the muttering of "whatever" or "here we go again".

Depending on the collective mentality of an organization's user community and its overall corporate culture, intranet developers only get so many chances to deliver what they promised. Break these promises and the intranet team's credibility can be permanently marred. And once credibility's lost, users will no longer look at their intranet team as a source of answers, but rather as a hindrance to be avoided at all costs.

What's even worse is if users are tech-savvy, or have tech-savvy people within their department, they might end up taking matters into their own hands and find other ways to fulfill their needs. And this opens up a whole different set of problems.


Loss of Support from Management

Senior level management support is the tie that binds everything together. They are the ones authorizing the appointment of employees to new roles in an intranet team—especially important when dealing with a multi-disciplinary and multi-departmental intranet where potential candidates might need to be pulled off another job or project. They are the ones who, by their mere involvement, assure the user community that an intranet is going to be a real system and not one small group's self-interest pet project. And they are the ones writing the checks for all required resources.

But if an intranet team sells an idea to senior management, wins their support, gets the green light, and then isn't able to make good on their promises, they're going to have to answer some serious questions. If they continually fall flat or miss scheduled milestones, they will have to provide justification for their continued existence—not only for their role within the intranet team, but for the system itself.

The accumulated effects of repeated failures will make it next to impossible to win managerial support and trust for future projects because all managers will see are dollar signs being flushed into a toilet. This is the real coup de grâce: You lose managerial support, and everything will fall apart.


Loss of Developer Motivation and Morale

Nothing sucks the life out of a developer more than having to repeatedly witness the death of projects they pour their blood and sweat into. This is especially true of bigger projects that take months or years to build and implement. Sure, there are those who take no pride in their work and only do what they do for the paycheck. Most of us, however, like to have some sense of accomplishment at the end of a project.

Having worked in an environment where revolving door systems was the norm, I know firsthand how demoralizing it is to work on consecutive projects that, for whatever reason, don't see the light of day. Developers will eventually become passive aggressive, ambivalent, and apathetic toward everything they work on. This results in a kind of self-fulfilling prophecy where developers will be asking themselves, "This is just going to fail like everything else I did, so why bother?" And by adopting this attitude, consciously or sub-consciously, they become the cause of the very thing they hope to avoid.


It's Not Only About the Dollars

Project failure and unmet expectations can have protracted soft consequences long after hard losses are corrected. Newly procured hardware and software can always be redeployed and used for other purposes, or even used to take another crack at the project they were originally purchased for. But the real question is whether the intranet development team will be given the chance to do it, and will users and management place any faith in the development team's ability make good on their promises.

There will always be circumstances beyond your control, but the important thing to keep in mind is that people actually expect a positive outcome when promises are made. So how often do you think villagers will tolerate your cries before you're eaten by a wolf?


Copyright © 2008 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.