Mark Schneider's SharePoint Taxonomy and Governance Blog

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.

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

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

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%
 

 

Why develop a taxonomy at all? Why not just use a "plug and play" search appliance?

Why do you need a taxonomy when there are a number of excellent search appliances available?  The problem is that the effective ability to organize, search and manage your company's intellectual property requires that the context and intent of the information be understood.

Authoritative documents are governed by the author's intent at the time and place that the final document was published.  Automated appliances are great at grinding through mounds of data, but they can't determine what you intended when the document was published.  Was it an official document?  Was it intended for open distribution?  How accurate is teh information?  What contextual information is needed in order to accurately understand the document?

A search appliance can help you find your information, but it can't help you manage or protect that information. 

Effective management of information always starts with a taxonomy of information policies that identify and define critical genres of information within your organization.  Once you have those genres or categories established, you can determine the governance, security, and lifecycle models that will manage those documents in their proper context.

Appliances are wonderful for finding things, but they can't tell you what to do with the information once you find it.

© 2008, Mark Ragar Schneider, All Rights Reserved

Picking a Winning Pilot Project for Your SharePoint Implementation

Choosing a good pilot project is critical to the success of your SharePoint implementation.  Let's be honest about the real purpose of a pilot project.  You are trying to gain credibility for yourself and SharePoint in the eyes of the end users.  Frankly, most IT departments are trying to recover from one or two "less than perfect" implementations over the past couple of years.  The technologies being implemented were probably quite rigid and fragile, so IT had to over-control the project.  Despite the best efforts of everyone involved the project was most likely late, over budget, and didn't work very well.  If IT was especially well funded and had the support of senior leadership, then these problems were camouflaged or simply forgiven.

No, I'm not psychic and I am not thinking of you personally.  This is just the way things have gone for IT up until the introduction of SharePoint-class tools.  SharePoint really does change the rules and boundaries that have hamstrung IT departments for so long.

However, easy as SharePoint is to use, it is vitally important that you choose a small fast and impressive pilot project to begin with.  Choose something with absolutely no risk of failure and use it to catch the end user's imagination.  The slightest hiccup in your preliminary implementation will compromise your newfound credibility.

As I say in my workshop, NASA didn't start out building a moon rocket.  First they built the Mercury and made sure they could keep a guy alive in low Earth orbit.  Then they figured out how to get two guys up into space with the Gemini.

Do the same with your SharePoint implementation; start really small and widen your scope slowly.  Build fast and simple solutions.  Build and master your Mercury project before you build your moon rocket.

Ragan Media / Newsgator Webinar on SharePoint Secrets Went Well

It was an honor to speak on Governance and Taxonomy during Ragan Media and Newsgator's online seminar "SharePoint Secrets Revealed" this week.  Here is a link to the slides that I presented.

(CLICK HERE FOR COPIES OF MY SLIDES)

(CLICK HERE TO GO TO THE REGAN MEDIA SITE FOR THE WEBINAR)

(CLICK HERE TO GO TO     RAGAN MEDIA)

(CLICK HERE TO GO TO     NEWSGATOR)

Best practices and governance

Over the weekend, Bill English, Ben Curry, Bleeker and I had an email discussion about best practices.  In a recent post I posed the question “what is a best practice?”  In order to fully appreciate the discussion, it is important to remember that best practices depend entirely on one’s role and goals.  An electrician is not going to have the same best practices as a surgeon obviously.

Todd Bleeker has a developer’s view, Bill English has a system administrator’s view, Ben Curry has an architect’s view, and I have a management/leadership view (more or less). 

·         My original statement: “A best practice balances resources, schedule, risk and performance to find the correct solution to a problem.”

·         Bill English revised it as follows: “A best practices balances resources, schedule, risk, performance and culture to find the correct solution to a problem.”

·         Todd Bleeker then modified it further: "A best practice is a course of action which balances security, risks, scheduling, performance, maintainability, and culture to find the right solution to a problem."

·         Ben Curry put it this way : “...limited resources is often what drives the best practice - whether a people or financial constraint. Many times, we simply don't get to do "the best practice" because of resource limitations or common sense.”

Each of us has a different role within the SharePoint world, so we are going to see things a little differently.  My focus is on making good solid business decisions with regard to technology.  It is possible to follow all of the best practices and still go out of business.  Compromises and shortcuts are necessary in the real world.  The truth of the matter is that if it costs $100,000 to protect certain information, and the risk is $50,000 if it is compromised, then the best practice is probably to provide minimal security.

On the other hand, if you ask Bill English the best practice for setting up a server farm, you will find out how things really should be done.  Todd can give you the best way to build a web part, and Ben can show you how to integrate your farm into your larger computing environment.

I can help you figure out how to get the most bang for your buck when you have to pick and choose between various best practices.

Ben, Todd, Bill and I together are an example of a Governance Team.  When new technical situation presents itself, we together are much better at governing than any one of us are alone.  We won’t immediately agree, and we may even argue, but we all have roughly the same goals.  Our viewpoints together help us to triangulate on a correct solution set for a problem, based on the real-world situation in which we operate.

The Governance and Taxonomy Workshop helps you jump start your governance team and establish the framework for your best practices--the taxonomy.

 

Don't forget the SharePoint Best Practices conference in September! 

CLICK HERE FOR MORE INFORMATION