Mark Schneider's SharePoint Taxonomy and Governance Blog

Noun Taxonomies and Verb Taxonomies Give Rise to Use Cases

If you spend any time Googling about taxonomies, you will find that there is healthy debate about the usefulness of taxonomies in actual practice.  The problem is that taxonomies can become over structured, confining, and can cripple the information worker's ability to act tactically.

Taxonomies have always referred to nouns.  Taxonomies are classification systems that use a hierarchy of increasingly specific nouns to describe, classify, categorize and organize a series of concepts.  So we have the plant and animal kingdoms.  We have the Periodic Table of the Elements.  We have first, middle and last names.  We have addresses that go from the general (nation) to the specific (street number).

Here is an important thing to remember as you read my blog--I'm driving the creation of a new kind of taxonomy, one that works in the context of automated information management systems.  The taxonomy concepts that I put forth in this blog are (and this is vitally important) VERBS not NOUNS!  My mission is to help organizations define a simple but profound taxonomy of verbs/policies/actions/behaviors that govern how information is put into action.  There is still a need for a NOUN taxonomy, but its purpose is to identify sites, documents, workflows, teams, individuals, audiences, etc. so that they can invoke one of the VERB taxonomy categories.

I call this VERB taxonomy a POLICY taxonomy for wont of a better term.  The marriage of a verb taxonomy with a noun taxonomy describes the organization's culture and business model very neatly.  This means that it is a tool that supports strategic planning, and the application of strategic planning, at every level in the organization.

SharePoint has my attention right now because I have wanted to bring about this shift in thinking about documents, workflows and other elements of organizational models, but there has never been a definitive tool until now.  SharePoint is still in its adolescence, but it is the closest toolset I have ever found.

I unveiled my methodology for using noun and verb taxonomies to create a framework for software development use-cases during the SharePoint Best Practices Conference this past week.  I'll be blogging on the topic next week, if not sooner.  All this talk about taxonomy concepts only matters if it actually helps you manage your data more effectively, faster, and more cheaply than ever before.  I believe the new concept of verb taxonomies is working well amongst my customers.  Now for the biggest stretch of my career. 

The framework that I spoke on at the Torrey Pines made use of a noun and verb taxonomy to map out use-case "regions" and approval/workflow boundaries.  On the one hand you don't want to lock down approvals and workflows--it is important to grant information workers as much tactical freedom as possible.  On the other hand you need to be able structure and manage how workflows and approvals work together to build a coherent knowledge management environment for your organization.

I believe my framework offers just such a tool, and best of all it is very simple to use.  It isn't software, it is a simple paper and pen diagram that can be used to frame use-case and workflow definitions.

Stay tuned....

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

Examples of Public SharePoint Sites

Here is a site that offers a catalog of public Internet sites that are created and hosted in SharePoint... pretty cool.  http://www.wssdemo.com/Pages/websites.aspx

A Project Framework Tuned for SharePoint Implementation Projects...

The VitalSkill cheat sheet (speedyproject) for understanding SharePoint project planning.  Note that this diagram shows where governance and taxonomy fit into the grand scheme of things, and what role they play in the SharePoint implementation and operations project.

Over the years I've managed a great many projects and programs.  The fundamental principles and best practices remain the same (see www.pmi.org) whether you are building a software system or a building a new bridge over the Mississippi river. 

However, having said that there is a need occasionally for fine-tuning project methodologies for a particular technology or task.  Not only do I have technology management experience with project budgets up to several hundred million dollars, I am also a fundamentally lazy man.  I believe in finding the simplest and most concise method for solving any problem.  I was also the lead architect for a $500,000,000 IT outsourcing project, so I have a decent handle on technology planning in general.  I also believe that laziness is a virtue in architecture, in that it encourages simplicity and elegance of design. 

Anyway, here is my project framework for SharePoint implementation projects.  When I developed this framework I had coffee with John Zachman on a couple of occasions and asked him how he created the Zachman framework.  for those of you who don't know, John Zachman is the grandfather of computer architects everywhere.  Way back in the day he created a simplified framework that would make it much easier to plan and organize technologies in an IT context.  He is something of a hero of mine, along with Grace Hopper who invented COBOL.  I ran into John Zachman a few times at architecture conferences and we seemed to get along pretty well.  For the price of a coffee in the morning, or a beer in the afternoon, he was more than happy to talk about clear thinking, technology planning, and dumb luck (all of which are necessary in developing a meaningful career in technology).

Well, I took John's principles to heart and added them to my own.  My goal was to come up with a simple reference tool that would make it much easier to organize a technology project.  I also wanted to make it easier for non-project managers to be able to sort through all the jargon and standards to understand what exactly is going on with their projects.  it is, in short, something of a cheat sheet on project management.

Here it is.  This is my standard project cheat sheet (which I lamely call speedyproject) adapted for use with SharePoint.  This little chart will help you organize your thinking with regard to SharePoint planning and implementation.  You can still use your favorite methodology.  This is not a methodology but a definition of concepts and how they relate-- in other words it is a taxonomy matrix for major project phases and activities.

Here is my matrix.  It also shows you how my Governance and Taxonomy Workshop fit into the project management cycle.  The Workshop gets your project initiated and moving forward in the context of SharePoint.

   

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

All This SharePoint Stuff is Going to be Normal Pretty Soon

What do I mean by "normal pretty soon?"  I tend to be drawn to new technologies that really matter.  SharePoint is one, the Amazon Kindle is another, and there are a few more.  One of these days I'm going to write a blog on how to recognize technologies that matter, but that is for a different day.

A while back I was an e-Commerce Strategy Consultant.  I had the honor of architecting what was, I think, the first online banking mall.  Over 20 banking associations pooled their resources to create a common back end-end of banking utilities that could be easily branded for each of their organizations.  This was back when XML was more or less science fiction, and so I had a great deal of fun building a bank around it.  By the Grace of God I picked the right pony in the technology race and the bank worked very well.

At the time I often spoke on e-Commerce strategy topics to audiences of senior executives.  My favorite speech was given in front of a large number of bank presidents.  I told them to go home if they couldn't explain why they wanted online banking.  If there wasn't a clear business need, then save yourself 20 million dollars (at the time), save your career, and save your sanity and just go home.  This was a rather startling approach for them, but it turned out to be good advice.  I would guess about 25% of the room did, in fact, go home.  On the other hand, the remaining bankers were ready to step up and "git 'er done."

At the time it was very important, when selecting a LOB solution, to make sure that it was "e-commerce capable," or "e-commerce ready," or some other phrase that indicated that the manufacturer had a sincere desire to slap a web page on the application sometime "real soon."  I did a lt of speaking then too, and I explained to my audiences that in two years or so e-commerce would be absolutely normal.  The day would soon come when the customer wouldn't even have to ask if a tool was "e-commerce capable" because e-commerce would be a natural part of everyone's thinking.  Of course this met with a great deal of skepticism.

Now, once again, you are struggling to find applications that are "SharePoint Ready," or to find custom gizmos that will hook up your LOB systems to SharePoint, or to find a consultant who can work a little magic for you.

Remember that you heard this here first!  In a couple of years you won't even think about SharePoint.  you'll still need tools and training, but it will all be normal.  LOB apps will ship with BDC connectors and webpart interfaces.  It will all be normal.

SharePoint is the new Windows, or soon will be.  When Windows was a baby called 3.X, it was an application interface that installed on top of DOS.  Over time DOS's funcitonality was subsumed into Windows.  The same is happening now.  SharePoint installs on top of Windows, but over time the two will become one virtualized program environment.

Trust me that this is the direction things are heading toward.  I am not psychic, it is just that this isn't my first rodeo.  I was actually a client/server consultant back in the day.  the whole concept of client/server blew people's minds.  They didn't know whether to laugh or cry.  When was the last time you brought in a client server consultant?

So What do You Do if You Can't Afford a Small Army of Consultants?

My blog post on evaluating SharePoint consultants was only meant to draw attention to the fact that there is far more to the story than development and administration expertise.  So how do you proceed using SharePoint if you don't have an unlimited budget?

1. It is always a good idea to get some help kicking off your project, especially where new technologies are concerned.  That is the idea behind my Governance and Taxonomy workshop.  It is best when it is completed before you have rolled out SharePoint, but can be used to put SharePoint "back on track."  It covers Governance, Taxonomy and a Project Charter.  And it is not, by any means, the whole story.  That is why I hold it down to two days, to limit your cost.  This may seem like a luxury, but it is hard to have a project end well if it doesn't begin well.

2. Next it is a really good idea to get a SharePoint MVP to come in for A DAY OR TWO to help develop and validate your deployment plan, infrastructure,and capacity plan.

3.Invest in SharePoint Administrator Training. Rather than invest in more consulting, at this point it is important to develop your own staff.  This is true whether you have a staff of two or two hundred supporting SharePoint.  You need to make sure you have the internal expertise to keep SharePoint alive and cared for.  This takes about four to five days of training with a live instructor.  There is a definite mentoring process that is needed to gel the administrator's thinking and behavior patterns organized, so a live trainer is essential IMHO.

4. Invest in Site Administrator Training.  This end user training goes by many different names, but you are going to need to have intelligent and motivated business folk do the majority of the heavy lifting when it comes to creating and maintaining sites.

5. Invest in Developer Training.  Although I hammer away at the economics of custom development, it is an excellent tool for your organization, when it is properly used and implemented.  Again this is, in my opinion, best done with a live trainer.

5. Do invest in a few books.

6. Go as far as you can with the out-of-the-box toolset, templates and webparts.

7. Join a good User Group.  I can't emphasize the importance of this enough!

8. Buy your custom BDC tools, web parts, and master pages off the shelf.  Use Bamboo Solutions, Lightening Tools, and other reputable tool manufacturers.  Their stuff is usually pretty cheap.

9. Establish a good relationship with a consultant or consulting organization that has strong developer and administrator skills.  This is, at the end of the day, where you will need the most help.

10. LOB integration is probably not something to do right away, so don't worry about this one just yet.  this is definitely not a Mercury Capsule project.  It is more like a Space Shuttle project.

11. Make sure your other technology partners and vendors are bonafide Microsoft SharePoint partners.  When it comes to storage planning, you are going to have to rely upon your NAS or SAN vendor and they are going to have to understand SharePoint.

12. Do go to conferences where you can rub elbows with vendors and peers alike.

13. DO NOT fall for every snake oil salesperson you meet in the SharePoint Space.  If somebody has a whiz bang tool or application that magically solves all your problems for you, then you are going to want to validate that it actually works.  Rule of thumb--if an application or tool takes away the pressure to think through your organizations' management and technology issues, then it is most likely bogus.  You are still going to have to do the heavy lifting when it comes to thought and preparation.  Again, that is why I created the workshop.

14. MOST IMPORTANTLY - Start small!  Remember to build your Mercury Capsule first (a site or site collection), then your Gemini Capsule (a larger site collection or two) and then your Apollo Capsule (your first enterprise deployment).

15. Wait a while before you start building externally-facing solutions with SharePoint.  It is much less embarrassing to mess up internally than it is to do so in front of the whole world.

16. Find a graphics, marketing and advertising agency capable of creating and modifying Master Pages.

17. Treat your internal SharePoint people very well indeed.  They are part of the most employable technology profession on the planet.  If they are any good at all, someone else is going to hire them if they can.  So don't overwork them, undertrain them, and under support them.  If you ignore them they will go away.

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

How Long Does it Take to Train Someone to Be a Competent SharePoint Developer?

Beats me, but here are some practical thoughts on the topic:

1. If you take a developer with 30 years experience in COBOL programming, and send that person to Java school, they will write COBOL programs in Java.  The same holds true for training SharePoint development training.  It isn't enough to teach your developer to grind out code according to a certain syntax and programming model.  You have to teach people how to think as well.

2. Your newly minted developer will not understand what SharePoint is or how it is used, unless you send them to "power end user" training.  It is quite possible to write technically correct, beautifully structured code that completely misses the mark as far as the warp and woof of SharePoint is concerned.  SharePoint is all about the end user, and if the developer doesn't take the time to find out what the end user does with SharePoint, then they are going to create bizarre and dysfunctional applications.

3. Developers would rather die, by and large, than go to End User Training.

4. The ideal SharePoint environment needs no development at all.  By this I mean that development should be avoided at all possible costs unless you really, absolutely have to have it.  Custom code costs tons to develop, tons to maintain, is a source of failure and security breach, and will cost you tons more when you have to uplift to the next inevitable version of SharePoint.  The economics are very much against custom code.  Custom SharePoint code should be as rare as custom Excel code.  You will still need custom code, but it should (IMHO) be your absolute last choice when trying to solve a problem.

5. There are a lot of great companies out there like Bamboo Solutions and LightningTools that make great web parts, BDC tools and the like.  Buy off the rack before you develop.

6. Few things are more dangerous than developers with time on their hands, so keep them busy doing something.

7. Let the end user try to find a way to solve a given problem before going to code. 

8. There are definite times when custom code is required: The need to aggregate information across unusual boundaries in the system.  The desire to create a custom web part that can be deployed everywhere.  An example might be a bank that desires to have a web part that calculates mortgage estimates according to the best practices of the organization.  That way all employees are on the "same page" when it comes to discussing and selling mortgage scenarios.

9. You aren't going to learn to be a decent developer from an online course, a book, or a series of magazine articles.  There is, in my opinion, a mentoring component to learning good development practices.  This is one area where I think it is vital to have a live instructor.

10. In the new world, the developers build the Lego's and the end users use the Lego's to build "stuff" in SharePoint.  Developers in a SharePoint context will spend most of their time building little bits and pieces rather than grand behemoth software applications.  Keep your requierments few, your timeframes short, and your process radical.

11. Customization can take on many forms - Custom workflows are a good idea, custom pages are a good idea as long as you don't violate the ability of the page to support inheritence for features you aren't currently using.  Custom data connections are going to be necessary in the long term.  Custom web parts will be necessary too.  Be careful about custom packages where a site template or definition comes to you heavily customized on multiple levels.  SharePoint is intended, IMHO, to offer the end user a series of tools that can be used to build and modify solutions as they arise.  SharePoint is not intended, IMHO to provide IT yet another avenue for tightly locked down and non-standard complex solutions.  I truly believe that the most cost-effective future is for IT to provide the tools and building blocks, and for the business user to use those tools and building blocks to solve specific tactical problems.

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

What to do with the Network Store

It not a good business model to spin undifferentiated (and unusable) data at 7200 RPM for all eternity, no matter how cheap disk is.  Though this is obvious, the network store is a time honored institution around the world and will not easily be made obsolete.  I wonder how much useless, undifferentiated and duplicate information is quietly going round and round all over the world?  I need to buy stock in a drive manufacturer.

Will SharePoint replace the network store?  Man I hope not!  The whole concept of a network store is dysfunctional.  We don't want to replace it we want to render it unnecessary.  We want future generations to laugh at the very concept of a network compost heap of useless data.  Essentially the model is (in my opinion) to use SharePoint to house, manage and use live information.  When the information in SharePoint is either ready to retire or be archived, then it is best migrated to FileNet or Documentum (or similar technology).  If the taxonomy, metadata and process models for SharePoint are well thought-out and implemented, the metadata pedigree for the file can be used to populate the metadata model in the permanent storage environment.

So does SharePoint replace the network store?  NO!  The goal is to ultimately hunt down and eliminate anything that resembles a network store by rendering the entire concept obsolete.  Keep in mind this is not a "Mercury Capsule" project.  It may not even be an "Apollo Capsule" project.  It must be, however, the long term vision for data storage in your organization.

This is one of the reasons my Governance and Taxonomy Workshops are "technology agnostic."  The leadership and governance teams need to focus on the business goals and needs, without being distracted by the minutiae of what any particular technology can and can't do in actual practice.  Define the problem set, the business requirements, and let IT develop the solution set using whatever technologies they choose to standardize upon.

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

Workshop Deliverables

Many people have asked me to provide a list of the specific deliverables that are produced during my two-day Goverance and Taxonomy Workshop.  Here are the basic deliverables.  Please note that I work with the client to taylor the deliverables and processes to best fit their unique objectives.  So, some clients will develop all of these deliverables through the two day workshop, and others will elect to focus their time and energy on a subset.

Governance and Taxonomy

Workshop Deliverables

MODULE 1: SharePoint Overview 

DELIVERABLE

a. A presentation to use in orienting the rest of the organization in the purpose and use of SharePoint 2007.

MODULE 2: Taxonomy Definition and Plan.

DELIVERABLES

a. List of Existing Taxonomies

b. List of products and services that need to be supported by the taxonomy plan

c. List of Regulatory Constraints that the taxonomy plan must address

d. List of “Line Of Business” systems and a high-level understanding of how the taxonomy will unify information across the various LOB systems.

e. List of Major Corporate Initiatives and high-level view of how the taxonomy supports each initiative

f. List of Major Distribution Channels and high-level view of how the taxonomy supports each channel

g. List of Major Governance Groups and high-level view of how these support and integrate with SharePoint collaborative governance

h. Top-Level Process Taxonomy

i. Validation Process to test the Top-Level Process Taxonomy

j. Secondary taxonomies and rubrics relating them to the Top-Level Process Taxonomy

MODULE 3: Governance Definition and Plan

DELIVERABLES

a. Federated Governance Model

b. Governance Goals and Best Practices Document

c. Governance Escalation Model

d. List of Governance Stakeholders and Their Goals

e. List of Federated Governance Teams

f. Org Chart for Governance Team

g. IT Governance Org Chart

h. Top-Level Site Administration Governance Team Org Chart

i. Site-Collection Administrators Governance Team Org Chart

j. Site

k. Site Owners Governance Team Org Chart

MODULE 4: Pilot Project Plan

DELIVERABLES

a. Project Framework

b. Priority Success Factors for A SharePoint Implementation Project

c. Risk Assessment Model

d. Project Information Worksheet

e. Project Design Worksheet (High-Level)

f. ROM Milestones and Schedule Worksheet

g. Core Project Team Roster and Roles

h. ROM Budget Worksheet

i. Risks and Risk Mitigation Worksheet

j. Project Constraints Worksheet

k. Project Assumptions Worksheet

5. MODULE 5: SharePoint Requirements Management

DELIVERABLES

a. Requirements Definition Model

b. Requirements Model for Collaborative Governance

c. Requirements Traceability Matrix (High-Level)

6. MODULE 6: Next Day Action Plan

DELIVERABLES

a. Specific Task Assignments, Metrics and Deadlines for Immediate Action

b. Short-Term Accomplishments Lists, Assignments and Deadlines

C. Elevator Speech

 © 2009, Mark Ragar Schneider, All Rights Reserved

If Your Legal Name is Skeeter then You Get Free Tuition at One of My Public Workshops

My youngest son wanted to see the movie "Bedtime Stories" today, and so my oldest son and I went with him to the local cineplex. The movie is one of the funniest movies I've seen in a long time, but half the fun was watching my youngest son bust a gut at all the various gags and jokes.

Adam Sandler stars as a ne'er-do-well named Skeeter who finally makes good through some very unusual means.  During the movie, I had a startling revelation.  I have been consulting, speaking, teaching, coaching and writing throughout North America, Europe and Asia for some 30 years.  To the best of my knowledge I have never, ever had a student named Skeeter.  If your legal name is Skeeter, please let me know, whether it is your first name or last name.  I'd love to give you free tuition at one of my upcoming "public" workshops. 

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

KMWorld.com Survey - What is SharePoint 2007's Most Important Feature?

 

KMWorld.com recently sponsored a survey to determine the “most valuable” feature of SharePoint.  The results were interesting, and for those of us who work with SharePoint not too surprising:

Collaboration  43%
Content Management 31%
Business forms/intelligence 6%
Search 4%
App dev 3%
Other 13%