Hi all
Some time back a publisher sent me a self-help SharePoint book pitched at end users. I figured that I don’t really represent an end user and the best way to review it would be to make Mrs Cleverworkarounds review the book. I mean, after all, getting the spouse to bring home the bacon is part of my quest to eventually be a kept man! However, my grand plan ran aground after a while – she got around halfway through the book and came back and said “It’s easy to follow and all, but I don’t understand *why* I am doing these things.”
As a result, I never published the review of that particular book.
If you are wondering what the point behind that little anecdote is, then read on.
“Seamless Teamwork” by Michael Sampson is a book that I knew I had to review – from when I first heard about it and read one of the chapters at its web site. Its subtitle is “Using Microsoft SharePoint Technologies to Collaborate, Innovate and Drive Business in New Ways” and as expected, this is a book that looks at SharePoint through a different lens to most of the technical books that I review (with the exception of Dux’s great project management book).
In fact Dux’s book
is actually a great frame of reference when reading this book because both authors have adopted a similar approach. Rather than focussing on the technology, both books focus on a specific problem domain and explain how to leverage the technology through the exploration of that problem. In doing so, they avoid the pitfalls of “end user” SharePoint books that lack coherence like the one that my wife was dissatisfied with. Why? Because there is a clear outcome to achieve by the end of the book.
Here is the funny thing, though. Both authors approach the subject matter from the perspective of a new project that needs to be successfully implemented, yet Michael actually uses SharePoint in a very different manner to how Dux does in his book. Does that mean one of them is wrong? Not at all. In fact it really hit home to me that if you can achieve *true* buy-in and shared commitment to a particular solution, then the technology aspects can be implemented in a number of different ways. Michael actually makes this very clear in his preface when he says
In a book of this nature, it is impossible to cover every eventuality, every situation, and every approach. What I hope you get out of it is a vision of how you can apply the capabilities of SharePoint to the work of your team, rather than a prescription of what you need to do at each and every point of a teaming process. Embrace the ideas that work for you and ignore the ones that don’t.
This book explores SharePoint through the “fly on the wall” view of “Project Delta” where an up and coming MBA holding brown-noser named Roger has kissed enough butts to be handed a high profile project to drive growth in the overseas market for his company. (Okay, so I am embellishing the back-story just a teensy bit). Through Roger’s eyes, we discover why email based collaboration is not sufficient for project collaboration, along with some teamwork theory, cleverly interwoven around the storyline. "Project collaboration” is broken down into more specific outcomes and explored individually, illustrating what capabilities of SharePoint are suited to these outcomes.
- Collaborating
- Finding
- Accessing
- Using for decision making
- Enforcing structure
- Publishing and managing
.. and that was just chapter 1!
Chapter 2 introduces the project management model used by Roger and the intrepid heroes of Project Delta. I like this chapter because he offers enough meat to theory nuts like me, while balancing useful and relevant SharePoint content. First up, five project phases are defined and explained, namely:
- Creating a shared vision
- Understanding the options
- Analysing the options
- Making a decision
- Concluding the project
This particular choice of wording has no references or footnotes and googling the exact terms leads me straight to Michael’s book so I presume that he is applying his own world view here. Next, we focus on getting the right people involved in the project. Roger has to identify the people with the right mix of skills, background and experiences to participate and this provides a nice dovetail to introduce SharePoint user profiles and “My sites”. As well as explaining the concepts and workings of this SharePoint feature, practical tips are offered to get the best out of it as well. The chapter concludes with a project team identified, assembled and ready to rock and roll.
Chapter 3 now focuses on the different audiences involved in a project, namely the project team, the project sponsors and stakeholders and “everyone else”. SharePoint team sites are introduced by examining the information needs of each of these groups and illustrating that one size does not fit all. The chapter walks through creating a site for each of these groups using a site and subsite hierarchy and the permissions required. Blank site templates are used (something I also tend to start with) and then some “projecty type” out of the box lists are created, as well as the ubiquitous wiki library and a blog site. Finally, some out of the box web parts are added to the mix.
All in all, a great example of a practical project oriented site that one could use or build upon.
Chapter 4 expands on these sites by switching focus from creation to actual use of the site. Michael writes about the “Seamless Teamwork Approach” to project collaboration and then uses this as a platform to explain alerting, RSS, basic usage of the lists, wiki and blog. The key theme of this chapter is the section about “teamworking protocol” – in other words, team members need to agree on the general approach to how they will work together. The most important point in this chapter deserves its own entire chapter.
It is expected – and absolutely beneficial – that people have disagreements and differences of opinion about key matters in the project. If everyone thinks the same, a team would not be necessary. However the key is that we will not allow disagreements to derail the progress of the project, because we agree to listen carefully and resolve our disagreements through candid dialogue and debate.
Chapter 5 through 9 now examines each of the five project phases that were outlined in chapter 2.
Chapter 5 is all about creating a shared vision. We examine the different types of vision (again from my research this view of vision seems to be Michael’s ideas and not based on any of the methodologies or academic stuff that I have read). We cover planning for engagement with stakeholders using a wiki, before the actual engagement process itself. Once again, this chapter is a deft mix of the product, the process and the rationale behind the approach. This chapter does not stick strictly with SharePoint either as we have the scenario of a PowerPoint presentation being viewed over a live meeting session for geographically dispersed stakeholders.
Chapter 5 also delves a little into some of the factors that cause the “chaos” that derails projects. The importance of timely notification of changing constraints or circumstances is covered by reviewing how the RSS and email notifications (tasks list connected to Outlook) are used. Finally, for some odd reason, Michael devotes two pages to placating those annoying mac users who, no matter that the problem is, has already tried to convince everyone that buying a mac is the solution…hehehe!
Chapter 6 is all about identifying options and starts out by examining how to effectively brainstorm using the SharePoint wiki (and confluence gets a mention also). OneNote is also covered and I found the shared OneNote notebook idea quite interesting as I have not tried that myself. This chapter is heavy on guidance and decorum around how brainstorming should be approached to get the most out of it. The chapter concludes with consolidating and synthesising the ideas.
Chapter 7 is all about analysing the options from the collated list. The key question here is “what could we realistically do?” This chapter is the first one to introduce the notion of a custom list. In the example, a custom list is used to track further analysis on each option. I loved the little governance interlude here, where Roger, being the angel user that he is, contacts Gareth, the ever friendly and helpful SharePoint support person to get advice on the best way to structure the custom list. (What sort of utopian fantasy world are you painting here Michael? 
). Seriously though, this is actually quite an advanced chapter in terms of SharePoint conceptual stuff, given that document based content types are also introduced here too and various permutations of mixing and matching document libraries, wikis and the perennial folder vs metadata debate. Thankfully, Michael did not poo-poo folders outright and instead gives one of the best write-ups I’ve seen on the pros and cons of folders vs metadata. He also covers site columns and how they can be scoped. This is great stuff.
The final section from this chapter is on meetings, with participants are either in the same location or separate locations. There are different types of meetings for different purposes and advice is offered on how best to run these meetings and when and what technology is appropriate to augment them. Microsoft’s free conferencing tool, “SharedView” is covered (something I never knew existed until I read this book – duh, Paul!) SharePoint meeting workspaces and Groove 2007 are covered also. The technology detail covered in this section is matched by great, practical advice on how best to use the tools, given the circumstances.
Chapter 8 is entitled “Making a decision.” Now our intrepid Roger has come to the crunch and gets a recommendation made, circulated and signed off. Here we use SharePoint surveys to do the task, but in reality, this chapter is not about SharePoint at all. The meat of this chapter is around the processes needed and advice on decorum in particular situations. There is a smattering of wiki and a good section introducing workflows in context of the feedback process, but fundamentally, the value of this chapter is in the non SharePoint material.
Chapter 9 is all about concluding the project. Roger’s butt kissing and pandering to stakeholders’ whims are finally at an end with confirmation that the final recommendation on project Delta has been accepted by senior management. Tasks include updating participants “My sites” with the project details as well as any skills learned, a blog post about the project in my-site, and the essential, but unpopular task of cleaning up all the loose ends of the projects from a compliance, archival and retention point of view. Some final housekeeping and we are done!
My favourite chapter of the book is actually not in the book at all. It is a separate chapter available from the Seamless Teamwork website and is all about SharePoint governance. I highly recommend this chapter, as it one of the best write-ups that I have seen on the topic so far.
Overall this is a terrific book, yet there are sections where advice is given that I would personally not take. Some things I flat out disagree with. But I need to fair here. I am currently surrounded by a dozen books on team dynamics, facilitation, soft systems methodology and risk management so I am not the intended audience for this book. Just because I have different philosophical approaches to some aspects does not detract from this book at all. In fact, it comes with the territory of a book like this and this is why I think it is such a great read. I personally find it quite easy to write technically oriented articles, but to delve into ‘soft’ topics like team dynamics, project chaos, developing shared vision and the like is actually much more subjective and I think, ambitious and difficult to write well.
If I was to make a broad comparison with Dux’s book, which is about the closest thing to a comparison out there, I would say that Dux covered more SharePoint feature areas than Michael and stuck fairly close to the project management body of knowledge. Michael on the other hand, delved deeper into some of the softer topics around how teams can deliver great projects. Apples and oranges really, and I think that both books compliment each-other exceptionally well.
The other commonality with Dux’s book is that readers with a technical audience who skip the preface will probably not like this book or consider it too light on in terms of low level SharePoint coverage. Michael is very clear in his preface here. This book is for users, information workers and project team members who want to make the best use of SharePoint for their team. To this end, Michael has completely nailed what he set out to do and should be commended for delivering the goods.
It is great to see SharePoint books coming out that delve deeper into the mechanics of team collaboration, before diving straight into product features and capabilities. Previous books have tended to gloss over the non technical side of team collaboration and this book fills the gap nicely.
Thanks for reading
Paul Culmsee
www.sevensigma.com.au
No Tags
Last year, Peter Serzo and I presented at the SharePoint Best Practices Conference in DC. We did an extremely serious talk called “SharePoint and SQL Reporting Services 2008 for the really really good looking” which rated rather well. As part of this, we recorded a bunch of screencasts that have never seen the light of day, so I thought that some would benefit from this being released to a wider audience.
.
