When launching a new portal, companies often underestimate the operational impact of their initiative. It doesn't take long into a new portal project before governance needs to be discussed. The breadth of governance conversations can range from change management and training, policies and procedures, to portal strategic and operational supports, roles and accountabilities.
Generally, we start that conversation with: "What are you doing now?" Answers have ranged from "Nothing" to "Well, lots, but it's sort of messy". In other words, operational change is inevitable? and most of the time this will involve a change to the current effort and cost.
Adding a new platform, such as SharePoint involves other considerations. Much more than a static web content delivery tool, SharePoint generally is adding net-new capabilities to the organization. Capabilities such as collaboration sites, document management or search. These new capabilities come with an increased operational effort to keep them tuned and up to date.
So where do portal initiatives fall short in estimating operational impact? Here's what I think:
Failure to account for portal capability maturity
There are many capability maturity models for intranets and portals. At their simplest, they go something like this:
How important is the portal?
- Not important, use it occasionally
- Important, use it regularly
- Very important, couldn't do my job without it
I've never seen a portal initiative that wasn't trying to mature the organizational impact of a portal. In turn, the higher the portal goes on the maturity curve, the higher the operational overhead (help and service desk support, backup and restoration, disaster recovery, device support, etc.)
Failure in the budget approval process
Let's face it, most companies don't like seeing operational overhead increase, and capital spending approval processes all work toward minimizing the overhead that a project will introduce to the organization. I don't expect to change the way this works with one blog post, but what I will say is that not estimating accurate operational costs will always come back to haunt. Here's the premise I'd start from: If a portal initiative is promising the organization benefits it does not currently have, then it will have an initial cost, and an annual incremental operational cost. Period. Save the efficiency data for someone else. My new car SHOULD get better mileage than my old one, but that doesn't mean the repair costs aren't increasing each year on use.
Too little research
I've read too many business cases that don't account for some pretty common costs. A common example: You're decentralizing content control and publishing to each of your lines of business. What percentage of your employees' time is now spent writing, editing, or approving content? Was this calculated as an organizational cost? Probably not.
Some other common forgotten operational costs: platform management, steering committee governance, ongoing evangelism, sustainment supports (e.g. systems integrators, your portal product's support costs), increased help desk costs (especially when launching new capabilities.)
Failure to account for new capabilities
In addition to portal maturity, net new capabilities should also be considered. If you had an intranet that was a static web page oriented intranet with a poor search, and you are replacing it with a brand new intranet and introducing new platform capabilities, such as team sites, enterprise search and the lot, it's going to cost more to manage and govern those new capabilities. It's that simple.
The final key area I see organizations neglecting when considering operational overhead is the platform selection. My point above has already covered new costs related to new capabilities, but what other costs does a platform introduce? Learning and growth costs need to be considered. Platforms such as SharePoint will have ongoing training costs as support roles continue to learn the platform. Increased resource costs also need to be considered. Did you know that a SharePoint developer makes more on average than a .NET developer? And of course increased system integrator support costs are also a factor not to be forgotten. (Sorry if this last one sounds a little self-serving.)