SharePoint Report 2008 Released on CMS Watch

After months of work, the new SharePoint Report 2008 has been released.  I collaborated with  CMS Watch to develop a full 190 page research report that exposes what SharePoint does well, its limitations and what businesses of all sizes need to do to be successful when implementing the tool.

I encourage you to review the sample content and review the TOC.

If you have feedback on the report, I'd love to hear it. 

Portals: Build it and they may come, but they won't know what to do when they arrive...

Many of our customers ask how they can spur adoption of new portal technology.  In cases where the IT department is leading the charge, we see a lot of "build it and they will come" approaches.  In much the same way Kevin Costner's character in Field of Dreams built a baseball field on his farm to encourage ghosts of baseball players to visit and play the game, IT groups hope that by simply exposing portal functionality to their end users, those same users will figure out what to do with it.  The trouble is that most employees are too caught up in their daily tasks to focus on the use of yet another tool, let alone see the opportunities for making their lives easier.

Portals technologies and other "productivity" tools come and go.  There have been lots of them over the years.  The prime example would be word processing software.  Does anyone remember the resistance to computer-based word processing over a typewriter?  Does anyone remember the fights that erupted in the executive offices when word processing centers (that existed in many large companies) were replaced by a far fewer number of individual secretaries armed with tools like the DOS-based Displaywrite word processor (an IBM created word processing packages from the early to mid-80's), WordPerfect or any of the other word processing packages of that era?  Or how about when the concept of an executive doing their own typing was introduced!  <GASP!>

The difference between a word processor and a portal is the number of functions.  More than likely, anyone familiar with a typewriter can guess how a word processing package functions.  And, with minimal fiddling, could probably figure out how to type out and print a document. 

By contrast, portal technologies encompass a number of functions -- some of them not so obvious.  The fact is and remains that IT or any organization pushing the adoption of a portal product, must help their user community.  This help comes in many forms, but here are some best practices for not only helping introduce the portal, but driving usage:

1. Pick a few Functions that have broad appeal
   Find those one, two or three functions that virtually everyone in the organization needs or wants.  The old term for this is the "killer app."  Effectively it's any feature of the portal that employees will immediately see value in using and something that you can make instantly accessible.  For example. surfacing a phone directory or portions of frequently used applications -- like electronic pay stubs.  The function needs to be something that users "need" to use as opposed to something that they could use (given the imagination to integrate it into their work).  One customer we recently spoke with implemented an employee lookup feature for a single department and it's now the most utilized feature -- by everyone from the mailroom to accounting to the receptionist.   As a result, this one feature is driving usage of the more traditional functions within their portal.
   
2. Train, Train and Train -- but do it quickly
   Most organizations miss this basic concept.  They also tend to focus on "all day" or other time consuming "big bang" sessions.  Remember that the portal is supposed to improve productivity, not create a huge hole in productivity.  By taking valuable resources away from their jobs for a day or more to try and consume loads of information, you not only create a down day, but the trainees will inevitably forget everything but the phone directory by the time they leave the session.  Instead deliver training in very small information blocks that take an hour or less.  Again, if we assume that the portal starts with a few key functions, developing training for these functions to fit within an hour or less session is not all that challenging.  If the functions are too complicated to show folks how to use them in that time, rethink the function.  Further, don't stop there.  Embed ongoing "training" into the portal, such that users can get to 30 second to 1 minute "mini-training" sessions on contextual content.  For example, if your portal has the ability to manage documents, embed links to help material literally next to buttons or links for that document management function.  A firm called Portalogiks has a product called "Virtual Training Academy" that contains 60 "modules" that fit this very description.  Their flash/shockwave-based materials are 30 seconds to 4 minute videos that present focused content around one specific function of SharePoint (e.g. how to upload a document).
   
3. Communicate Frequently
   One key to adoption is frequent and useful communication with the user base.  Users tend to forget or simply don't know that the portal may house useful functions  or, in the case of SharePoint, new approaches to accomplish the same task (see our blog entry on using SharePoint Search within Office's Research function).  Again, keep the communications focused around one topic that can easily be consumed in short order by your user community.
   
4. Flagrantly Encourage Participation
   One of my former managers, Sue Hanley, used to promote the idea of "bribery" for portal users.  Effectively, the portal won't survive without an active content contributor community and a broad consumer base.  Since the challenge is really a "chicken or the egg" problem, you should consider developing programs that encourage both the consumer and contributor communities.  In spirit of bribery, creating contests with prizes or a simple "gold" star program will help motivate both groups.  What works for your organization will probably be different from other firms, so do a little research and experimentation to figure what sells -- we've seen everything from lunch in the executive dining room to additional vacation days to iPod/Zune giveaways.
   
5. Make Incremental Improvements
   For a whole host of reasons, the big bang (rolling out all features at one time) approach simply doesn't work.  By contrast, introducing a new portal with a small set of core, broadly used functions tends to get the ball rolling.  However, without continued improvement, usage will fall quickly (or simply stagnate).  Instead, ensure that the portal continues to expand and grow.  This means not only in terms of functionality, but also approach.  There's a really good chance you won't get it right first time around.  Make sure that you become comfortable with changing how and what you're doing within the portal to keep up with feedback you're getting from your user community.  We typically recommend to clients that they make changes at least once a quarter, but no more than once a month.  This keeps any improvement scoped for a successful rollout and at a comfortable "consumption" interval, such that your users are not overwhelmed by changes.
   
6. Measure and Measure Again
   Don't guess at the portal's success, make sure you establish success criteria and gather both quantitative and qualitative data.  Use this data to continually evaluate if you're hitting your goals.  As the portal matures these measures will change, but do not become complacent.

While this list contains just six best practices, they are probably the most frequently ignored.  And, obviously, these best practices represent only a segment of what you should be doing  overall.  However, from what we've observed, just doing these six things well will vastly improve your overall success.

Effective Project Management in Small Organizations

I've had the good fortune to work in a number of different organization sizes, in addition to working with a wide array of individuals, project types and technologies. In large part due to this broad experience, I've seen my share of successful, mostly successful (in spite of team member actions to the contrary) and failed projects. In all cases, I've learned a good deal about what makes project successful and not so successful. Particularly in small organizations (either in terms of employees or revenue), making projects successful proves to be challenging, since mistakes can't simply be brushed aside by adding more money, resources or both. As a result, smaller organizations need to be especially careful how they manage their IT projects. Unfortunately, these are the very same organizations that have little or no discipline around managing projects and, generally, think a bunch of really smart people simply "get it done."


Most recently, as Consejo was completing a series of projects for a medium-sized customer, I found myself helping them think a bit differently about managing projects -- gathering requirements, deciding what functionality "get in" to what phase, how to assign resources, how to perform solid on-going management and how to test and deploy the project once complete. While Consejo won't be involved in this next project phase, the information we shared with them is relevant for a great number of companies. As such, I thought it would be worth sharing what I shared with them. To that end, here are some general best practices we have developed at Consejo to help us and our customers manage projects to a successful conclusion.

• Make sure you understand what you want to build
  Another way of saying this is "make sure you document, review and validate requirements." I suppose this goes without saying, but Consejo has done work for more than one customer who felt that the business users (the folks who create requirements for applications or IT projects) simply needed to "tell" the IT group what they want. Often words and/or phrases like "simple," "shouldn't be hard," and "this isn't rocket science" creep in to those descriptions. Unfortunately, these customers often give requirements like "needs to be easy to use." While this is truly a requirement, what's missing are the details like: what is "easy" in the context of this requirement, what metrics do we use to measure successfully meeting this requirement and, most importantly, who's the audience for this "easy" application? Don't get me wrong, a reasonable person could arrive at approximations of "easy" on their own, but as the project starts to get close to finishing up and folks are rushing to meet deadlines, both IT and the business tend to get pretty picky about requirements; (over generalization coming) business users want to continuously tweak the application and IT simply wants to establish that they've met a particular requirement and move on. So, be sure to document, review and validate requirements up front -- before the coding or development begins.
  


• Establish a good change control system
  Almost no one can argue that requirements are fixed once they've documented, reviewed and validated. Even in the best case scenario, requirements change -- the business climate changes, the audience changes, new insight emerges or the Earth starts spinning in the opposite direction. Ultimately, something always changes. However, the difference between a well-run project and one that will spin out of control, is how the collective team developing this solution manages changes. Consejo recommends having a well-established and formalized process for defining, submitting, validating and approving changes to an in-process project. Project teams must understand precisely what the new requirements is, how it fits with the existing requirements (e.g. what changes and what doesn't), the impact to the project effort and/or duration and, if applicable, the cost of the change (which is usually tied to increases or decreases in effort -- but not always). More often than not, a bad project is the result of an unending set of changes, mid-project, that no one (including the folks providing the requirements) keep track of well enough to be able to establish whether the new application meets the modified requirements. This situation usually results in a very heated back-and-forth discussion at the end of the project, where no one is happy with the final outcome.
  


• Set project scopes so that you can meet requirements quickly
  Very long projects tend to yield the most defects and the most dissatisfied end users. Especially in IT, where the underlying technology changes rapidly, long projects simply aren't practical. Consejo recommends that customers define project scopes that can be accomplished (start to finish) in three months or less. This may seem unreasonably short, but consider that projects that take six months or longer suffer greatly due to changes in business climate (e.g. external to the organization) and organization needs (e.g. internally driven requirements). Having personally worked for organizations that had a "13 week year," a three month project allows organizations to quickly realize benefit without being unreasonably sidetracked by either internal or external forces. In addition, having such a tight project delivery schedule forces both IT and the business to focus on the highest value requirements and/or features, pushing other features or requirements out until later phases. To illustrate this problem, consider projects that take six months or longer. Businesses typically make changes to any number of aspects of approach in the market -- be it advertising, new product launches or competitive advantages. Making the business wait for a six to twelve month project to complete, just so that business changes can be integrated into this new application is an unreasonable expectation (especially if IT doesn't want to get a flood of change requests). A three month time line is much easier to manage and provides more immediate opportunities to improve the application once the development cycle has been completed.
  


• Use the "metrics for success" to test the project outcome
  Testing anything seems to be counter to corporate culture. This statement may seem overly dramatic, but I've been involved in more than one project where the customer expected less than a week's worth of testing for a project that took three months to complete (I've also worked for firms that understood testing to be the period immediately after the application was completed and place into production -- when real customers were using the tool). Further, these same customers are the ones that tend to "tell you" the requirements, without documenting and validating them. If an organization truly wants to be successful, it takes the time to document requirements and indicates what success means in terms of satisfying a requirement. They then use this documentation to craft a testing strategy to ensure success. For example, if "easy" to the customer means that a user can get to or access a particular function within two clicks, then there should be a corresponding test scenario that allows a tester to validate the application has met this metric. If there isn't a formalized approach to testing, you end up with developer-test solutions and developers inherently know where not to go to break their own code.
  


• Find the right people, not the convenient people
  In today's market, it's tough to find qualified candidates, get them involved in your project and/or find a candidate willing to work for what you can afford. Most often, the best resources are busy, stretched to thin and/or asking too much. If anyone has recently tried to find a good SharePoint resource, you understand what I'm describing. However, finding the right resource to lead, manage or participate in your project is critical. When describing the "right" resources, I want to be clear: the right resource isn't necessarily the most technically savvy, but the best well-rounded individual. The right resource, beyond being technically qualified to participate in the project, should understand and adhere to good project management practices (even if they're not a project manager), they need to be a good team player (I've met many "smart" and technically superior resources who were terrible team players) and, most importantly, they need to be able to find the answer if they don't have it themselves. In short, they need to be flexible, resourceful and have good "people skills." Some companies make the mistake of reallocating resources who are underutilized to projects when their short of team members -- either out of convenience or ignorance. This was common in the mid-nineties, when administrative assistants were made into "web masters" because they were enthusiastic and the web was thought of as a "toy" (this was especially true when companies were starting to create intranets). These admins may have understood HTML, but they didn't understand what the impact was to the organization or how to make the intranet work for the organization. In addition, However, consider this: the better resources in the market can often find faster ways to get your project done -- even if their per unit cost is higher, the project will likely cost you the same. In addition, these resource also understand how to make this new application "real" for your organization by being able to interact with the business and, potentially, end-customers.

This list is certainly not exhaustive, but it covers the points that are often overlooked by organizations taking on IT projects. I hope it's useful to you and I would certainly appreciate any feedback you may have.