Tag Archives: Adoption

The Wikipedia Manual of Style: A Study in Governance

Governance is a fantastic idea. In fact, it is absolutely critical to the continued success of an application. There are times that governance, to me, seems to be a great idea on paper, but in practice it’s very difficult to implement. I was talking to someone the other day on the topic of governance, and I used the example of Wikipedia as a successful governance plan and execution. I thought it would be worthwhile to dig deeper into the topic as a great example to look to.

Of all places Wikipedia has a great outline of governance goals as applied to the IT arena.

The primary goals for information technology governance are to (1) assure that the investments in IT generate business value, and (2) mitigate the risks that are associated with IT. This can be done by implementing an organizational structure with well-defined roles for the responsibility of information, business processes, applications, infrastructure, etc.

The more and more I do true implementations of IT whether it be SharePoint, WordPress, or any similar technology is the role of governance. Items from controlled vocabularies to usage policies are essential the sustainability of an IT initiative especially in terms of ensuring that IT investments generate true business value. A lack of governance is always a primary reason why IT projects fail.

The Wikipedia Manual of Style

Wikipedia has an extensive governance model outlined in their Manual of Style. Everything from abbreviations, punctuation, etc is included in this one of many operating documents for Wikipedia. It is clear not only reading this document that it has been carefully thought out, but the power of their guidelines comes from adherence to the document.

In a policy and guidelines document it is noted on who is responsible for enforcing these policies.

You are a Wikipedia editor. Since Wikipedia has no editor-in-chief or top-down article approval mechanism, active participants make copyedits and corrections to the format and content problems they see. So the participants are both writers and editors.

Books such as Wikinomics probe how such a mass scale collaborative project doesn’t turn itself upside down, and it’s truly a site to behold. It becomes apparent that Wikipedia editors tend to enjoy adhering to the governance model, because they understand it is crucial to the long-term sustainability of the project. The editor therefore become stakeholders in there edits, and they understand that if they want their work to not be lost is an adherence to the governance documents.

That is of course not the whole story behind Wikipedia. The Wikimedia foundation does have a small army of administrator that constanty patrol the recent changes list, and ensure that the governance model is actually being utilized. So actually ensuring that certain individuals are empowered to a special degree of administrative rights also becomes a crucial factor in its success.

Applying a Best Practice in Your Organization

Let’s face it, none of will ever be doing something as wide-scale as Wikipedia (although never say never), and so the question becomes how can we apply the best practice from Wikipedia governance to our individual IT endeavors? Thinking through this I came to this short list.

Governance guides need to be thoroughly thought through and documented.
Those who contribute information need to be made aware of the governance guidelines.
A governance document should not be seen as a barrier to creativity and collaboration.
Certain individuals should be wholly devoted to the task of enforcing governance.
Those who consume information should have confidence that governance is being enforced to maintain findability, accuracy, etc.

I’d be interested to know how these overriding principles are being used in other successful governance implementations. I’d venture to bet that successful initiatives mimic much of the list above. Whether SharePoint or Wikipedia the same governance principles apply and are necessary.

The Four C’s to Sell MOSS

You’ve been tasked with bringing some order to the chaos of your various organizations’ file shares, e-mail servers, and externally facing websites. After all the research and analysis you’ve done you’ve decided that MOSS 2007 is the optimal solution to solve the problem. The problem? Selling it to management. You can demo MOSS with all its fantastic features and Office integration, but your management needs some “bullet point” reasons why they should invest in MOSS.

In Essential SharePoint 2007* the authors lay out the “four C’s” of company portals that MOSS can satisfy. These can be used as a good starting point to sell them and bring MOSS into your organization.

Communication is a fantastic reason to bring MOSS into your organization’s processes. Many companies are plagued with disseminating important information both to internal and external individuals, and MOSS can aid in delivering timely, relevant, and accurate information to your target audience. Through the use of MOSS sites geared for news, announcement web parts, blogs, and audience targetingâ€”MOSS can greatly help your organization accomplish this much-needed functionality.

Collaboration is the strong point of MOSS and also the easiest to sell. Your organization struggles from discerning which document is the most recent, and people in your organization realize that e-mailing around a document is not an effective way to collaborate. Here is a great time to talk about the workflow capabilities in MOSS. Demonstrate an approval workflow which engages the management instantly by showing them how the whole process can be automated, contained in one area, and management can see what’s holding up the workflow. Add onto this team sites with robust document management capability with an extensible security model, and you’re well on your way to convincing them.

Consolidation is probably the reason you were tasked to find a better solution than file shares. There is no way anymore to know where to get what and if it’s even accurate. With enterprise search you can ensure that your users can always find the document (with a good metadata structure/information architecture). You can also sell the Business Data Catalog (BDC) which can crawl those old file shares and bring them into the same search interface. You’ll also see eyebrows rise when you show them the business intelligence capabilities in MOSS such as Key Performance Indicators (KPIs) which will help your management make the best decision on the most up-to-date information.

Consistency is something that we all long for in our IT applications. Right now your public facing website, other marketing materials, and even standard company documentation can’t look the same for any length of time. With the use of master pages you can be sure that the interface changes you make will be reflected across your entire MOSS installation. Having problems keeping that PowerPoint template up to date? Creating a content type will ensure that your users will always have the latest version of the companies template.

These are four great selling points of MOSS to bring your management on board. When partnered with some simple demonstrations that will create a strong case for MOSS.

*Jamison, S., Cardarelli, M., & Hanley, S. (2007). Essential Sharepoint 2007. Reading: Addison-Wesley Professional.

2 Replies

The Most Trivial Aspect of Designing Interfaces

I’ve been doing UI work for almost a decade. I’ve seen a lot and been through many fads (although I won’t claim them if asked). For a long time I thought the most important part of designing interfaces was the way it looked, and I was caught up in the next DHTML fad that would come across my RSS reader. Well, thankfully I’ve grown and realized what’s really important, and I’ve come to realize that an interface’s appearance is not the most important thing.

Note: Please don’t think I’m saying that the way it looks is not as important, but is pales in comparison to our following discussion.

What? You Mean Users Come Here?

When I heard first of User Experience (UX) I had a hard time wrapping my arms around it. I made it more difficult then it is supposed to be. In short, UX is the discipline that aims to understand not only who your users are but what they are trying to accomplish with your application. When you understand UX then you create an interface that facilities these user’s behaviors and desires. I found this great definition of UX:

The term “user experience” refers to a concept that places the end-user at the focal point of design and development efforts, as opposed to the system, its applications or its aesthetic value alone. It’s based on the general concept of user-centered design. (Source)

I love this definition, because it illustrates that UX “places the end-user at the focal point” which is critical to your applications success. When you neglect how your users will interact with your system then ultimately, and I guarantee this, it will be a failure.

We’ve all been on sites that have left a sour taste in our mouth. Maybe we are forced to use this sites, and when we use them we’d rather complain about them then actually use them. Whether it’s an intranet or public-facing site we still have the same possibility for failure. Often times schedules push the necessary time to understand UX to the back-burner in order to “get something out in front of the customer.” Doesn’t that seem ridiculous? We want to get something out for our customers so they can benefit from it, but we don’t do the careful assessment necessary to ensure that this happens?

Practical Steps to Facilitate UX Research

Here is a short list of items to remember when developing your next application to conjure UX research.

Spend some meaningful time interviewing a wide-range of potential consumers to uncover what they would use your application for.
If you’re replacing a legacy system then be sure to ask what about the current system frustrates them.
Let your feedback from the consumers drive those tense decisions that often play out between the development team and management.
Diagram workflow to understand all variations your users can get from your application.
Usability testing will become invaluable to see how users actually use your system as opposed to a hypothetical discussion.
Engage user feedback and understanding when developing your information architecture (labels, navigation, etc).

We are all users, and we all have strong opinions on how interfaces should look and function. The only problem is when we start designing applications that cater to our personal or internal desires and not what aides our customer. UX doesn’t have to be a burdensome process that puts your project behind schedule, and if done correctly you’ll see immediate and lasting positive effects from your effort.

Siolon

Musings on SharePoint, User Experience, and More