Mark Schneider's SharePoint Taxonomy and Governance Blog

WWSD - What Would Steve Jobs Do?

Steve Jobs is a remarkable man, and his impact on the world is enormous.  The man was the original high-tech "rock star."  He managed to be the coolest guy on the planet and an underdog at the same time.  He was unapologetically arrogant, demanding, and hard to work with, but he was also almost always right.  He had an uncanny ability to get the best out of people.  He was a visionary.  His rags to riches, to rags to riches, to rags to super-riches story is the stuff of American folklore and legend.  I'm proud that he was part of my generation, and I his.  He was Apples' greatest advantage and his absence is Apple's greatest weakness.

The problem Apple faces right now, is that Steve was THE guy at Apple.  It was all about his vision, his hunches, his dreams, his decisions and his leadership.  The people at Apple went through their professional lives thinking, more or less, "What Would Steve Do?" in every situation.  He was the gold standard and his way was right.  Those that didn't understand this probably didn't last long at Apple.  So, a new generation of visionary leaders has almost certainly NOT been developed at Apple.  The iPhone 4S launch this week was, to me, a clear indication that the folk at Apple don't have a clue what to do next.

Steve Jobs led his people brilliantly, but he didn't develop them to think and lead in their own right.  Good governance is not about controlling people, it is about guiding and developing them.  I don't know first hand, but I'm willing to bet there isn't a lot of governance structure in place at Apple right now.

If I am not mistaken, there are a number of people at Apple vying to step into Steve Job's rock star spotlight.  They would do well to see the movie Moneyball and learn that the answer isn't in finding a new rock star, but in establishing a team that fits together and works.  Good governance means making the whole more amazing than the sum of the parts.

I love Apple computer and I hope they find their way.

It's all about Peopleware

All technology personnel should strive to develop their skills and presence in three distinct areas:

1. Technological Expertise
2. Business Savvy
3. Leadership and Communication Skills

Technological Expertise is an obvious requirement for technical personnel.  Technology is a tool for solving organizational and business problems, and the better you are with technology the more problems you can solve.

Business Savvy is often overlooked.  Google, as an example, enjoys breathtaking technological depth, but they seem to have almost no understanding of their target markets.  Google technologies are often brilliant, but clunky to use and disjointed.  Google technologies are rarely smoothe to operate.  My understanding is that they are taking steps to correct this, and I wish them well because they really have a lot to offer.

Leadership and Communication Skills are last but certainly not least.  Brilliant minds need to influence, communicate, listen, persuade, and align if they are to have a meaningful impact.  All too often technology professionals are accurately described as aloof, isolated, irrelevant, uncooperative, confusing and ineffective.  Always remember that even technology is ultimately not about hardware and software, but "peopleware."

These skills used in concert are the hallmark of a world-class technology team.

 

The ICE Model for Project Issue Remediation

Here is the ICE Model I use for project issue remediation.

• Identification - Clearly identify the issue
• Communication and Collaboration - Let the right people know in a manner that is concise, clear and invites their help in solving the problem.
• Execution - Quickly act upon the solution

How to Write Crisp and Effective Emails

Although it takes practice to write crisp emails, the results are always better.  The best strategy with email is to keep things very simple and crisp.  My favorite approach is as follows:

· Think of your email as a PowerPoint slide.  People are trained to scan PowerPoint slides very quickly.

· This means that you have one brief introductory paragraph at the beginning, to get your point across.

· List the main ideas (between three and five maximum) as simple bullet points below the introductory paragraph.  Three is ideal but not always adequate.

· It can help to highlight the main words in each bullet, but use highlighting sparingly.

· In the Subject Line, precede the subject with a word like: FYI, ACTION, RESPONSE REQUIRED to let the reader know what you want.  Keep your subject very short and simple.

 

The last paragraph ties together the main idea of the email, and briefly describes any action to be taken.  This should be no more than one to three sentences.  Use this approach and you will find your emails are easier to write and much easier to understand.  Also, if called upon to put together a presentation, you can just paste the emails into PowerPoint as I did for today’s Leadership Meeting.

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

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 to Evaluate a SharePoint Consultant...

This is a BIG topic because SharePoint is not an application, it is a universe.  Really.  There are, and should be, consultants for many different aspects of SharePoint deployment use and development, including:

1. Training consultants

2. Business strategy, policy, governance and integration consultants

3. Project management consultants

4. Legal consultants

5. Line Of Business integration consultants

6. Business Data Catalog consultants

7. Business analysis consultants

8. Document management consultants

9. Operations and infrastructure consultants

10. Deployment consultants

11. Storage management consultants

12. System administration consultants

13. Master page consultants

14. Branding consultants

15. Migration consultants

16. Search indexing consultants

17. metadata management consultants

18. Consultants to manage teams of consultants

Usually when someone is writing about the way to choose and evaluate SharePoint consultants, they are thinking about a pretty narrow section of the possible skillset that goes into a SharePoint environment.  Most likely they are thinking about SharePoint administration or development.  This is because the people writing are most likely developers or administrators, which is fair.  But there is much more to the story.

The very best branding consultant may have very little expertise with SharePoint at all, at least not beyond the creation and management of Master Pages.

The best business analyst or project manager may only have a rudimentary understanding of SharePoint beyond a Power End User's level of technical expertise, and a healthy understanding of the various professionals that might go into a major deployment.

So, after 30 years of being a consultant, and being a corporate leader who hires consultants, here are my brief rules of thumb:

1. Check the person's references.  Very often the consultant will say "I ran a really big SharePoint initiative" when in reality they were one of the developers or administrators.  Give credit where credit is due, but understand that they are not going to be in a position to understand the larger business issues involved in making SharePoint happen.  Most SharePoint deployments are technical successes and business failures, when they fail.  A developer, administrator or architect is not likely to be able to help you mitigate business risks beyond ROI calculations and making sure requirements are met.  These are very important, don't get me wrong, but they are not the whole story.  So check the person's references if at all possible.  Make sure that the reference describes the consultant in the same role as the consultant described.  Make sure things went well.

2. If at all possible, ask to review the consultant's portfolio.  If the person is a branding or page consultant, then they should be able to show you a portfolio of their successes.

3. Check the consultant's successes with similar, and different technologies.  You do not want a consultant who is a SharePoint "one trick pony."  SharePoint is a great tool, but it is not the only show in town.  If the consultant can't discuss other viable solutions to whatever problem you face, then they are going to have blind spots.

4. Evaluate whether or not the consultant can work with real people in an everyday setting.  People are almost always hired for their technical and professional skills, but they are almost always fired for their lack of social and people skills.  If you hire a consultant who is long on technology and short on people then you are going to regret the decision.  One of the primary purposes of a consultant is to train up the people on your team by transferring knowledge to them. If the consultant hoards information and works in a vacuum, then you are going to be miserable.

5. Ask the consultant to explain how they will approach your problem. If they spew out a stream of technobabble, then they are not going to be good communicators when they assist you.  Consulting is all about communicating.

6. If the consultant has certifications, make sure they matter.  I am a PMP certified project manager, and I can tell you that it is quite possible to have this certification and be a lousy and untested project manager.  My practical experience is far more important.  Successful management of a 500 million dollar outsourcing project is far more predictive of success on your project.

7. Make sure the consultant is a truth teller.  If the consultant tries to tell you what he/she thinks you want to hear, then your situation will be worse for having them join your team.  Make sure you can trust the consultant to tell you when the emperor has no clothes.  They need to tell you politely, but they do need to tell you. 

8. Make sure the consultant has a ready made, built-in exit strategy.  Consultant should never be around for very long.  The consultants plan of attack must take that into account.

9. Ask the consultant to describe their engagement cycle.  If they can't effectively describe their method for entering the consulting engagement, establishing rapport, assessing the situation, proposing and validating a solution set, delivering a solution, and exiting, then they are going to be pretty random when they are on the job.

10. DO NOT hire a consultant who has not actually done the work before, and done it successfully.

11. Make sure your consultant has realistic boundaries and a realistic understanding of their own limitations.  If you have a consultant who thinks he/she can 'do it all,' then they are not a good pick for your project.  SharePoint is too big for any one person to do it all.  If they think they can, or even think they can do a big chunk of everything you need to have done, they may be big on ego.   The last thing you want is to hire someone who will hunker down, bight off too much, and grind to a halt as they try to overcontrol the technical aspects of the project.

12. Ask the consultant to describe their biggest failure and what they did about it when it happened.  If you have a consultant who can't describe a significant failure, then you have an inexperienced consultant.  consultants take on the big risks.  Failure is part of the deal.  The big question is how they handled themselves.  did they run and hide, or did they run toward the problem.  did they get the project or effort back on track or did they bail out?  If the consultant can't describe a major failure then they are inexperienced or defensive-- neither is good for you.  If they blame the failure on others, then they are not going to take ownership for their work when you hire them.  they should be able to clearly and cleanly discuss their own failure with emotional distance and a sense of closure.  You don't want a consultant who can't objectively evaluate their own work and own up to problems.  If they can't own their problems then, when they are working for you, they will hide their problems until the last possible minute.  When the problem is finally revealed, they may shut down emotionally or run.

And So Begins the SharePoint Best Practices Conference 2009

It is once again my honor to participate in the SharePoint Best Practices conference co-hosted by Mindsharp and Microsoft.  It is humbling to speak at a conference where so many experts are present at one time.  Not only are the best speakers in the industry present, but the people attending are of the highest possible caliber as well. 

With so many amazing professionals among the speakers and presenters, it is wonderful to be included in the speakers' list.  Accompanied by my youngest son John, I arrived Friday evening.  John and I arrived a couple of days early because the conference is at the La Jolla Torrey Pines Hilton just north of San Diego.  What a wonderful hotel.  The lounge, restaurant and outdoor pool area look out over the 18th fairway at the Torrey Pines golf course, where the Buick Invitational Golf Tournament starts in a couple of days.

John and I drove up the coast, spent some time at the beach in Carlsbad and went for a great hike into the state park right next door to the Torrey Pines golf course.

We had a great time hanging out in the Presidential Suite with various speakers and Mindsharp folks tonight.  Gourmet pizza was on the menu and the Super Bowl was on the big screen.

Just for fun I'll be posting photos at http://www.flickr.com/photos/markragarschneider/sets/72157613217598143/ .  The photo set so far is mostly about sunsets, desert hikes and the beach.  Once the conference actually starts there should be more opportunities to post photos of folks and happenings at the conference itself.

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

Support the Government but Wash Your Hands, a Parable...

A few years ago I was watching a presidential press conference.  At the time the press had been working hard to 'raise awareness' about potential biological warfare attacks.  One reporter asked the president what his administration was doing to protect the American People from pandemic.  Are there enough vaccines, is there a sufficiently robust contingency plan?

According to a few public health studies I've read over the years, over half the members of the press corps do not wash their hands after using the toilet.  Americans in general do not generally wash their hands after using a public restroom, and those that do wash their hands do not use good practice.

So, the most effective deterrent against pandemic would seem to be for the press corps to wash their own hands in an effective and purposeful manner.  What do they want the president to do, deploy the National Guard to enforce good bathroom procedures?

Don't get me wrong, it is very important for any modern government to have a well-thought-out plan for worst case scenarios, including engineered pandemics.  But as always, effective government begins and ends with personal responsibility.  You simply can't transfer the responsibility for your own actions to a central government.

This is a great analogy for collaborative vs. "top down" technical and business governance.  You need centralized strategic governance and policy management, but you also need to provide and support tactical freedom amongst the information workers you support. 

©Copyright Mark Ragar Schneider, 2009 All Rights Reserved

Best Practices vs. Urban Legends and Supersititions

In the olden days I worked with a major drive manufacturer in their semiconductor manufacturing processes as a consultant.  In those days there were so many interdependent variables and so few ways to measure and analyze them that scientists and technicians developed persistent "superstitions" about what led to a good yield and what did not.  If they washed their hands with a certain kind of soap on a day that the yield was bad, then they would forever ban that soap.

 

When measurement and statistical process control techniques improved, we were able to weed out many of the superstitions (my role was process control and measurement consulting).

 

I see SharePoint as being much the same.  Urban legends are occurring and persisting.  Because of the nature of SharePoint and its inherent decentralization, it is difficult to categorically prove or disprove a proposition, so the proposition persists.

 

Best Practices provide a good set of baseline behaviors against which unintended consequences, and their resulting urban legends, can be mitigated.

 

I hope to see you at the SharePoint Best Practices Conference... we'll battle the SharePoint urban legends together!

 

SharePoint Best Practices Conference

February 2-4

San Diego, California

www.sharepointbestpractices.com

© 2008, Mark Ragar Schneider, All Rights Reserved