I’m happy to announce that my “Website Governance: Guidance for Portals, SharePoint, and Intranets” has just been published. It’s an update to my Methodologies and Best Practices document on governance which is the most popular document that I’ve written for Burton Group (out of 17), even though only came out in March of 2009 and therefore has had less time to accumulate document views than others I’ve written.
I updated the document based on some new ideas and clarifications that have been needed since its original publication. The main updates to the doc since publication are as follows:
- Clarified the alignment with IT governance and service management
- More detailed diagram of the document hierarchy
- Added option to define roles and assignments separately
- Added “cultural tenets” methodology
For more on what I’ve changed and why, click here.
I just had a good conversation with a client about whether setting up a chargeback model for SharePoint would be a good idea for them and how to design it. This is a common question that I blogged on over at the Collaboration and Content Strategies blog (see Do Chargebacks Work for SharePoint, Portals, and Collaboration?), but thought it could be useful to provide the set of questions I use to diagnose a portal chargeback situation and determine if it is the right path to take and how to design the model. It’s probably useful to read that previous blog posting first to see where I’m coming from.
1. What’s the governance structure (e.g., federated I assume)? How many other sites using it?
- Rationale: Validating that the organization fits the standard situation where there is a federated model where I’m talking to the central IT provider and there are many potential adopters of the enterprise portal.
2. Rollout maturity: Where are they on the curve of network effect? How many other sites could potentially use it?
- Rationale: Collaboration technology thrives on network (aka snowball) effect where the more people use it, the more valuable it is. You don’t want to disincent usage. But once the portal is rolling and users are addicted, it may be possible to shift chargeback models from a tax to a utilization model to prevent abuse and provide a more fair sharing of the cost burden based on usage.
3. Pricing: Cheap? Subsidized?
- Rationale: It can help adoption of the chargeback if not all cost recovery is addressed by the fees. For example, maybe 50% of the infrastructure is centrally funded and the other 50% is recovered through chargebacks. This is not essential though. 100% recovery through chargebacks can help provide the business a clearer view of costs and value.
4. Competition/lockin: how easy for units to say you’re too expensive and use something else? policy or regulatory barriers?
- Rationale: A common problem with chargebacks is that potential buyers start haggling with you or just go to a SaaS provider who is a few bucks cheaper. Then all information sharing and network effects go out the window. This works best when there are barriers to users going outside the centrally provided service.
5. Chargeback maturity: do other technologies use chargeback too? Is there a “tax” model that has been used”?
- Rationale: If business units aren’t used to being told they have to pay a chargeback they may balk at the idea, even if it is a good one. In an extreme case there may not even be an accounting/financial process where chargebacks can be implemented. Same goes for “tax” -if you’re just one of many the business will understand your proposition much better.
That’s it. From these 5 questions I can now tell a client whether they share characteristics of other organizations I’ve spoken with that have been successful or unsuccessful with chargebacks. I can also determine whether it is better for them to do a usage or tax-based assessment. And provide a few areas to beware of (and hence prepare for) as well.
Governance problems have plagued all sorts of websites, but in my experience they seem to come up disproportionately in SharePoint installations. In researching and writing my new document “Website Governance: Guidance for Portals, SharePoint, and Intranets” (slated for publication in March) I wanted to figure out why that is. Here is what I found out about why SharePoint has proven to be particularly vulnerable to chaos when ungoverned:
- Ease of deployment: SharePoint is easier to license and install than other portal products. That’s great, except more parts of the organization will be tempted to set up servers. Decentralized installation and setup of the servers often leads to siloed installations that do not conform to the organization’s best practices or technology standards.
- Grass roots nature: SharePoint’s ease of use has proven to be a double-edged sword. While it opens up self-help collaboration and content capabilities for a broader swath of information workers, it also places creation in the hands of a large number of non-IT users who are only minimally monitored. This can lead to poor findability and an inconsistent user experience.
- Lack of multi-farm management: SharePoint lacks enterprise-wide management features that other portal products have had for years. The highest level of management in SharePoint is the server farm, but enterprises wanting unified policies and governance across multiple server farms have few tools to accomplish this. Microsoft has made a step to remedy this situation with a Cross-Site Configurator that was specifically developed “in the context of IT management challenges that have arisen with the rapid growth of SharePoint deployments.” However this product is unsupported for now and is not a part of the official WSS build.
- Frequent overlaps with other installed capabilities: SharePoint provides an integrated set of capabilities that often exist in separate products that an organization may already have installed. A team that has been managing a content management, search, collaboration, or portal system for years may wake up one day to find users starting to leverage SharePoint for the same capabilities. The result is information segregation and a quick call to the CIO to make a decision on coexistence or shutting down one of the overlapping alternatives.
This doesn’t mean that SharePoint cannot be governed. But they do point to the importance of creating a statement of governance early in the planning cycle for SharePoint. While some large SharePoint deployments rise above all these problems, it is rare and difficult for them to do so without a governance structure in place.
I was happy to see the Wall St. Journal had a 3 page section in the 5/14/07 issue on “Business Solutions: Building a More useful Intranet”. But I was disappointed to see the total absence of any mention of the importance of trimming down the information presented based on the the user’s profile. The “Portal” word was invoked once, but not explained or associated with “contextual delivery”. Personalization – not mentioned.
There is an interview with Kara Coyne from Nielsen Norman Group. I had the pleasure of sitting down with Kara a few years ago and discussing how I thought that the human factors industry was not keeping up with the times by continuing to treat screen design as a static home page issue – as if one was laying out a newspaper ad. But here she is, on page R6, responding to a statement about clutter by saying
What upper managers often don’t understand is, the more items that there are, the less likely it is that users are going to see your item. If you have too many choices, you’ll end up tuning them all out.
Right! That statement is the perfect lead-in for the need for a technology that helps line up information about who a specific user is (a profile compiled from the directory, HR information such as title and department, skills inventory, heuristic analysis of their contributions and attention stream, and self-profiling or “opt in”) with metadata about the content to determine what would be important to that individual. It’s personalization and portals have been doing it a very long time. You can make it very complicated if you want to, but even in its simplest form it can have tremendous value by narrowing down the information to be sorted through.
The problem is not that there are too many items on the intranet or on the home page. The problem is that no effort has been taken to determine which items are of value to a given user. 99%+ of the information on an intranet is useless to any one individual, so any simple filtering of information – even just by department or job function – can have a huge impact. Why force them all to see the same thing when technology has existed for years to help winnow down the information? Search (which is mentioned in the section) is part of the picture (the “push” part), but not a winning answer for home page design.
The American Electric Power example they give (winner of a Nielsen Norman Group award) is once again a demonstration of an advertising-like devotion to examining “the” homepage as a static work of art. Any design review, in my opinion, should be dynamic. It should start with asking what the main types of users are and then asking to see what the homepage looks like for each type (the executive’s homepage, a call center agent’s homepage, an IT developer’s homepage, etc.). The design has to serve the function and only by knowing what various users need from a website can you determine if the design is appropriate. And no one design will meet the majority of needs of even the top 5 categories of users, so why spend all that time on usability of a non-optimized page? The AEP page looks beautiful in a generic way, but why is it forcing an information worker to click and dig to get their information instead of caring a little bit about who they are and bringing it to them? Maybe it does, but that’s not apparent from the web page shown.
Also, on a separate peeve, I’ve spoken many times about the value of collaboration when used in context. The AEP site has a button at the top called “The Agora” that’s described as “a new area where employees can meet and collaborate”. Does the user need to go to a special area to collaborate? Does that mean the rest of the intranet is not for collaborating? I can’t tell from the picture or text, but I’ve seen that quite often when I’ve done design reviews. If someone’s job is to track sales leads, for example, collaboration should be used in context – right there next to the sales lead system and displaying collaborative discussions and documents relating to the sales lead being examined. Information workers rarely stop what they are doing to say “Gee, I think I’ll go collaborate for a while and then get back to work”. Collaboration can have its own home page and entry point too, but contextual collaboration is where I see collaboration having the most value.