Go to page: 1 2  Printer Friendly Version

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.

Go to page: 1 2  Printer Friendly Version