Skip to main content

VOGTLAND - Mark Vogt's Blog

Go Search
Home
  

Other Blogs
There are no items in this list.
Introduction

Microsoft Sharepoint is changing the world, in much the same manner as email did in the early & mid 1990's...

If you're not already aware of it, Microsoft Sharepoint is what everyone calls "collaboration software". If I jumped on an elevator with President Reagan, and I only had 10 floors to explain to him what Sharepoint was, I'd say "Sharepoint is a website-building technology which requires nothing more than a browser. The sites you can create are equivalent to "virtual workrooms - the kind you always dreamed about having for each of the projects you work on with other people. When you're working on projects together (let's face it - that's the PRACTICAL definition of "collaboration"), you've got lists of various kinds plastered all over the walls of whatever little closet your boss is letting you temporarily use. Task lists, Needs lists, Goals lists, Don't-Forget lists, Questions lists, Calendars (really just an "event list" - isn't it?)... the list goes on (get it?). When the items on the lists are all checked-off, YOU'RE DONE.

You always wished you could have a separate "project room" for EVERY single project you worked on, but no building could ever have enough rooms. Sharepoint is as close as anyone has EVER gotten to providing "virtual" project rooms, and it actually works quite nicely.

There - and we're only on the 5th floor...

:-)

So now you know what Sharepoint IS, but that's not why you're looking at this book. Likely you already KNOW what Sharepoint is, and are experiencing some kind of PAIN related to how your organization is using it - which likely is BADLY.

I detest using terms without defining them in a practical manner, so let's start with the most important term you'll find in this book - GOVERNANCE.

You can find all the textbook definitions you wish, but in the end, "Governance" means nothing more than "not letting people run amuck"...

That said, "Sharepoint Governance" then means "not letting people run amuck whilst using Microsoft Sharepoint".

This naturally leads to the question "HOW can people "run amuck" whilst using Sharepoint?"

The following list provides pretty decent coverage of all the ways many organizations have

commonly been able to mis-use or otherwise run amuck with Sharepoint since it first came out in 2001:

Common ways to Run Amuck with Sharepoint

- users see content they shouldn't

- users to change a site's branding (look & feel) when they shouldn't

- users create sites they shouldn't

- users create features in their site which cause the underlying servers to grind to a halt

-

Dedication

This book is intended for all those people whose bosses told them "Go figure out how to govern Sharepoint - right now."

This book is for those people who Googled countless websites, forums and blogs, drove to all the popular bookstores, and skimmed through every book on the shelves whilst sucking down latte after latte...

... only to realize that pretty much everybody was regurgitating the same snippets of text from the same sources at Microsoft...

...only to realize that no one seemed to really be speaking from genuine experience....

...only to realize that no one really gave you an actual solution - instead just a bunch of high-brow, abstract "visions".

This is book is for you, so you can tell your boss that now you ARE governing Sharepont.

Quickly Finding Hidden and/or Forgotten Requirements: The Key to Successful Sharepoint Solution Projects
I had an epiphany today which got me out of bed at 4:00a...
 
At my current workplace I've repeatedly experienced some "Sharepoint Projects" that internal customers initially are convinced are "micro projects" and apparently ideal fits for Sharepoint eventually snowball into larger, longer, more complex projects wherein Sharepoint can't quite do what they want....
 
:-|
 
Everyone suddenly gets all disillusioned & frustrated, and pointing the finger at Sharepoint as the culprit, which I find annoying. Instead of focusing on the 95% of the "initial" requirements which were met swiftly & completely by Sharepoint, they end up focusing on the remaining 5% of the "eventual" requirements which Sharepoint struggled with.
 
 Hmmm...
 
"Eventual" Requirements...
 
This scenario played out enough times (and truth be told on even NON-Sharepoint projects) that I must have been working on it even in my sleep, because the epiphany hit me just minutes ago:
 
THE REAL CHALLENGE IS THIS:
HOW TO QUICKLY, COMPLETELY & ACCURATELY UNCOVER ALL 'HIDDEN' AND 'FORGOTTEN' REQUIREMENTS AT THE BEGINNING OF THESE 'MICRO' PROJECTS ?
 
That is, in a company culture that appears to DESPISE - and therefore attempt to skip in its entirety - that part of the traditional SDLC model wherein Solution Needs Assessments and its subsequent Solution Requirements Definition are exhaustively performed, the end result is INVARIABLY the same:
- The Customers naively coerce developers into Solution Construction with only partial requirements;
- The Customers naively coerce developers into Solution Deployment with only partial testing (due to partial requirements);
- The Customers naively begin using The Solution;
- The Customers FINALLY begin uncovering the HIDDEN REQUIREMENTS and FORGOTTEN REQUIREMENTS;
- The Solution does not - and SHOULDN'T be EXPECTED TO - meet these HIDDEN and FORGOTTEN requirements;
- The Customer gets angry, and wants to blame The Technology for what is THEIR oversight.
 
:-(
 
End of Epiphany. What I've realized is that for Sharepoint - and many other technologies, in fact - the MOST CRITICAL KEY TO SUCCESS is finding a way to QUICKLY, COMPLETELY & ACCURATELY capture REQUIREMENTS:
- QUICKLY, because The Customer DESPISES this activity, and will forever & always deem it an UNnecessary waste of time & money;
- COMPLETELY because every damn project I've seen struggle and/or fail can invariably find incomplete requirements as THE root cause;
- ACCURATELY because sometimes requirements are OVERSIMPLIFIED, and this is just another form of being INCOMPLETE.
 
This then is going to be Mark Vogt's QUEST - and possibly the topic of an entire booklet...
 
The Quest for Holy Grail of Methods: Quick, Complete & Accurate Solution Requirements Gathering.

 ‭(Hidden)‬ Admin Links