After many months of hard work and more than a few struggles, I’m happy to say that I have in my hands a printed copy of The SharePoint Shepherd’s Guide for End Users: 2010. Before I talk about the upgrades that the 2010 version of the book has over the 2007 version of the book I want to take a step back and explain the journey that I’ve been on with this project – to tell the story of the book’s existence. While I’ve talked about the self-publishing process, I did so from the perspective of the financial impacts and didn’t focus much time on why I decided to self-publish. However, I think there’s an important story to hear about how the SharePoint Shepherd’s Guide came to be. Of course we’re now in our second edition so the story is really about the first version.

For most of my professional career I’ve been a consultant. I’ve worked for myself. I’ve worked for a large accounting firm/consulting company. I’ve worked for smaller consulting companies. I’ve more or less always been doing full solution creation. I’ve been taking a set of parts and assembling them into solutions for customers. Sometimes those solutions involved servers and sometimes those solutions involved software. During that time I noticed a disturbing situation that consulting companies find themselves in – and customers don’t realize that they’re creating such stress inside the consulting companies.

Consulting companies hire consultants – that is they hire folks who can go out and do work at a customer location. They don’t necessarily hire folks who are the best at documenting or writing documentation. In fact, by and large, the consultants I’ve met over the years are challenge oriented – they’re always looking for the next challenge to overcome and while writing documentation can feel challenging, it’s not exactly the kind of challenge most consultants are looking for. Hey want to create the next solution and documentation feels like busywork no matter how important it can be.

On the other hand, customers often wisely ask for documentation on the systems that the consultant has built for them. They want to be able to maintain it once the consultant is gone and they want to make sure that the users use whatever was built because a system that isn’t used is useless. For the most part the only person who can document a system is the person who built it and so consulting companies ask the consultant who did the work to write some documentation. What follows often succeeds but only after a great gnashing of teeth. The consultant begrudgingly does whatever it is the customer wants in the way of documentation – and absolutely not a word more than is required.

The problem is that this sets everyone up for negative feelings. The consultant doesn’t like the work of documenting so feels some angst for both the consulting company and the client for making them do this work. After all, don’t they know that the consultant is highly valuable and can’t be bothered to do such things as documentation? (Tongue planted firmly in cheek) The consulting company is frustrated because they want their consultant on the next project. The customer in the end is rarely truly satisfied with the documentation provided because the goal was “minimally acceptable” rather than excellence.

What’s perhaps more criminal about this whole process is that it’s repeated for each customer … over and over again. Consultants find the end of each project painful. Consulting companies realize that key resources can’t move on to the next project. The customers may like the solution but often struggle with the level of detail in the documentation. Most solutions built on top of SharePoint have a high amount of overlap in what must be documented. After all SharePoint is a platform and the platform does a lot. The way that items are edited, columns are added, lists are created, etc., are all common to most of the solutions built on SharePoint. Most of that documentation isn’t unique or different from one project or customer to the next.

My situation as a consultant is a bit different. While I’ve been consulting I’ve been writing and editing during the nights and weekends. I’ve got over 100 book projects to my credit and counting everything 20 book projects with some sort of author credit. So for me writing isn’t a burden, it’s therapeutic. It’s something that I can do to unwind, to relax at the end of a day or week. As a result I don’t mind writing documentation for customers. To me it’s a nice change of pace. (Yea, I know some of you are reading this thinking that I’m sick – I’m ok with that.)

One day I was going to lunch with my buddy who shared that he was writing the same documentation for how to edit a list item in SharePoint for what seemed to be the millionth time. He was exasperated because every new client meant doing the same stuff over and over – because if they were going to pay to have it custom generated then they expected their screenshots in it. Of course, that just meant he had to redo everything. During the discussion the idea came to me … what if you could standardized most of that and sell it as a package and then you would just have to fill in custom details with a little bit of work – instead of starting from scratch each time. It could dramatically reduce the amount of custom frustration and create a better set of deliverables in a fraction of the time.

Thus was the genesis of the SharePoint Shepherd’s Guide. That was the moment that I knew that I needed to generate content that could be reused for corporations who needed documentation for a part of their custom solution – that wasn’t really custom. Thus began the materials that would eventually become the book. I realized that having a set of corporate training materials for end user SharePoint concern was going to be an awareness problem. There are dozens of folks that have materials – if you know where to look. However, most of those organizations struggled to get the message out about their materials. They also didn’t scale down to the smaller organizations. The model for materials really works well for organizations that have 100 people or more but corporate licenses just don’t execute well for smaller organizations. With my background I knew that the answer had to be a book. Smaller organizations could purchase the book itself through distribution and the larger organizations could get the economies of scale with the corporate licensing.

Sometimes I describe the SharePoint Shepherd’s Guide as a book that is not a book. That sounds odd even to me; however, it makes sense when you realize that it’s a way for larger organizations to evaluate the materials and for smaller organizations to buy the materials in a way that works for them. So why am I so happy about the release of the book? Because for me it’s the way that people get to see all of the hard work. It’s the way that more people can benefit from the things we’ve done. With that in mind, let’s take a look at the new book in comparison to the previous edition.

I’ve already given some of the stats for the book in my previous blog post. However, things have changed a bit as I laid things out and got to a final stage. Let’s go through the numbers:

	2007	2010	Increase
Page Count	377	556	47%
Tasks	116	181	56%
Index Pages	0	18
Decision Trees	0	6
Background Chapters	0	4

So what does all of this mean? Well, in short we tried to address every single concern that we heard about the previous version. This includes desires for some different types of content in places as well as the desire for an index –something that is only necessary for the printed book.

I’d encourage you to go learn more, or buy a copy at The SharePoint Shepherd’s Guide for End Users web site.