Do you expect results from SharePoint? Then do the hard work.

I was inspired to write this after reading Andrew Gilleran’s article, “Who cares about the SharePoint End User?”

Since my job revolves around SharePoint, it may surprise you to learn that this is the question I dread more than any other:   “So tell me all about SharePoint! What can it do?”

I dread it because this is really what they are asking:

“How soon can you zap my company/department/team with SharePoint’s amazing superpowers and POOF! fix everything that’s wrong? Oh- and it will work perfectly forever, and everyone will automagically know how to use it, right?”

The conversation usually devolves into a recitation of features, and this response:

“So SharePoint peels the potatoes and makes julienne fries? AND it cleans my oven? While I sleep?? AWESOME! How soon can you be done? We have a big meeting next Thursday- I’ll slot you for a 5-minute demo. That should be enough time for you to show us how it works!”

Soon enough, the conversation changes:

You promised me SharePoint could slice and dice AND make me look 10 years younger. It’s not working… I have no idea who owns that site- no one’s used it since you created it last year… I know you invited me to training class but I don’t have time. Isn’t SharePoint supposed to be intuitive?”

 (I am barely exaggerating, as many of you know.)

What’s wrong with this scenario?

Opening with “Tell me what <technology X> can do,” rather than, “Here’s my problem: _________. How can <technology X> help me solve it?” invariably places the technology person at a major disadvantage.

Would you walk in to an auto dealership and expect the salesman to sell you the perfect vehicle without knowing anything about  your transportation needs? Would you hire a builder and assume that the home with the most popular floor plan will automatically suit your family perfectly? Yet that is exactly how big companies (who should know better) decide to use SharePoint, and how they frame their expectations.

Unless you can define a specific reason for wanting SharePoint around which its deployment can be focused, its successful implementation will always be a crapshoot. In fact, I will go so far as to predict that unless you can articulate specific reasons for which your company plans to use SharePoint, your deployment will fail.

PLEASE NOTE: by “specific reasons,” I do NOT mean “improve collaboration” or “increase productivity.”

Those are NOT measurable goals. They are NOT hittable targets. They are vague concepts whose definition constantly changes. They are corporate buzzwords tossed around by salesmen and executives who have no idea how SharePoint really works. If anyone tries to sell you SharePoint with nothing more than those two promises, be very afraid.

I especially hate the rampant use of the word “collaboration.” It is not a “thing” that can be “improved” or “increased.” It is a behavior; it is a state of mind; it’s the result of many sub-actions and practices, an organic process that is often only recognizable after the fact. It means something different for every person and every organization.

Once you have defined what collaboration means FOR YOU, and you can analyze your company’s practices to locate the breakdowns in how they do their work which inhibit or impede collaboration as you define it- only THEN you can apply technology to help address those breakdowns. The technology cannot identify your breakdowns. It cannot analyze your processes. It cannot reveal your shortcomings. You have to do that first, in a technology-agnostic vacuum.

Then, if you choose to do so, you can open the SharePoint toolbox and select the correct “wrench” to tighten that bolt and (hopefully) stop that annoying PING that occurs every time you turn a business process corner. Or, more likely, you can present your findings to the SharePoint expert and allow him/her to recommend ways that SharePoint might be able to make a difference. Those recommendations must take into account a variety of factors, including:

  • Version of SharePoint in use
  • Current supported version(s) of Office in use
  • Current supported browser(s) in use
  • Mobile device expectations
  • Previous experience (if any) with SharePoint
  • Level of impact on users and expected “change aversion” to new technology
  • Training options (if any)
  • Support options and long-term maintenance of the platform
  • And more…

SO- If we know all this- why do we continue to fall into the same traps over and over again?

The answer is: if they told you how much work it took up-front to really make SharePoint work, no one would ever purchase it. So that part is glossed over:

“Once your governance is in place…”

“Once you’ve mapped out your corporate vision…”

“Once you’ve planned your security strategy…”

That’s like saying, “Once you’ve earned a million dollars…” or “Once you’ve trained to run a marathon…” What comes next is smooth sailing in comparison. The level of agreement and cooperation it takes to effectively implement SharePoint in an organization can strike fear into the hearts of even the most dedicated administrator.

SharePoint is a true platform, relying on active, informed engagement from all parts of the enterprise. Often these are parts of the enterprise who rarely (if ever) even communicate with each other. You cannot just install it and walk away. It is a living organism that requires constant attention. It demands a level of expertise that cannot just be handed over to “that one guy who doesn’t seem to have enough to do,” or learned in a week-long seminar, or achieved by passing a certification exam.

To successfully meet these challenges- to deliver a solution that truly improves the work life of those who use it, brings value to the business and a positive return on the (considerable) investment in people and hardware- you must aim for measurable results that SharePoint can help you achieve. The more vague and amorphous the reasoning behind SharePoint’s use, the more impossible is becomes to ever know if it’s making any difference at all.

Before you begin, you must identify as many critical success factors as possible. These are ideally formatted as responses to the question, “We will know that SharePoint has succeeded at our company when: ____________.”

Outline as many scenarios or measurements as you can whose presence serves as an indication that SharePoint is doing what it’s supposed to be doing. NOT acceptable are responses like, “… when productivity is up” or “… when there’s more collaboration.” Rather: “…X% more projects are completed without going over budget” or “… every department’s expense report is submitted by the 25th.”

Not only can SharePoint facilitate achievement of these goals, it can help provide the data required to ascertain whether the benchmarks were met.

While you’re at it, finish these statements:

  • Our standard process for engaging SharePoint support is ___________.
  • Our standard process for providing SharePoint support is ___________.
  • For non-standard SharePoint support, escalation process is __________.
  • The highest permission level an end user may be granted is __________.
  • Our response to user-initiated “site borking” is _____________.
  • Our stance on SharePoint Designer is _____________.
  • Our stance on SharePoint accessibility on mobile devices is ____________.
  • SharePoint training will be provided by ___________.

Ignore these aspects of managing SharePoint at your own peril. These are not things you should plan on figuring out as you go along. Every one of them has the power to bring an unprepared SharePoint team to its knees- and this is just a short list. Get it done beforehand, and make sure all the right people are at the table when you do it. Yes- it’s called a Governance Plan, and Googling that term will show you more than you ever wanted to know about the part of SharePoint that no one seems to have time for.

Have you ever regretted a major purchase? ANY purchase? Think about it. What would you have done differently? What research would you have done? What questions would you have asked? How much money would you have saved? A shovel cannot dig a hole for you. It is just a tool. By the time you realize you should have rented a ditch-digger, how much time and effort will you have wasted? How much is too much?

“If you fail to plan, you plan to fail.”  Put in the time. Do the hard work. Only then do you earn the right to expect results from the technology.

Frantic User Stories: Relative URLS and the Quick Launch in WSS 3.0

Disclaimer: This article addresses the SharePoint 2007 Standard (WSS 3.0, not MOSS) environment. Some of my comments may not apply to other versions of SharePoint. Also, custom-developed solutions are not an option for any scenarios outlined in this article. I limit my approach to end user/power users who do not have
access to such resources.

A Frantic User emailed: “I deleted a list but the link is still showing on the Quick Launch. What am I doing wrong?”

Short answer: Nothing. The link was manually added to the Quick Launch. Manually-added links are not dynamically connected to the source list/library; therefore they don’t respond to such changes.

Long answer:When creating a content element (list or library), you must choose “Yes” or “No” in response to the question, “Display this list [or library] on the Quick Launch?” If you select “Yes,” the link will automatically be placed under the default content heading for the list/library type, and will point to the default view of the  list/library. In short, what you get in this scenario is a dynamic, relative link to the target list/library.
Continue reading

What puts the “dead” in “deadline”?

“Companies certainly shouldn’t expect overnight success…. on average, it takes one to two years past initial deployment for companies to reach their target adoption rates for social technologies.”

The above quote, from from Ann All’s post on Underwhelming Adoption of Social Technologies in the Enterprise, caught my eye as we inch closer to the rollout of SharePoint 2010. I certainly consider SharePoint a “social technology” so this insight definitely stood out to me. I am ever more concerned with post-deployment outcomes and making sure we are ready for the other side of that deadline date.

All’s post led me to this post by Laurie Buczek. Buczek refers, somewhat dejectedly, to an unsuccessful project which she walked away from after 2 years: “We deployed just another tool amongst a minefield of other collaborative tools – without integration. To make it even harder, we underinvested in transition change management.”

Clearly, flipping the switch is not enough. What happens next is the true indicator of the life or death of the project. Are you ready for the aftermath? Do you have a long-term training strategy? Do you have a dedicated support structure? Will users know what to do when they need help? Do they understand how the new product mixes with the old ones?  If you cannot answer YES to all of these questions, you may find yourself wanting to take the same walk Buczek did.

Of course no one expects instant adoption. But what DO they expect? Is there an adoption strategy? How will you know if you’re on track? Will you be able to point to metrics that indicate whether adoption is even occurring? What are the key performance indicators?

Planning and preparation are not a waste of time. As pointed out above, they are investments. They pay off later, which is why they are so often pushed aside in favor of “right now” deliverables demanding faster turnaround. But they matter. Their absence is a colossal risk.