The SharePoint Implementation Market needs to grow up!

We’ve all watched the industry make the most of the "SharePoint boom" that Microsoft has created by releasing SharePoint 2007 in 2006. This led to various problems in the market surrounding the product.

How did this unravel?

  • significant issues in the initial RTM release
  • no governance up front by Microsoft on how to implement solutions on top of SharePoint
  • immature SharePoint Solution Integrators (SI’s) who implemented poor solutions
  • slightly more experienced SI’s going in and patching up the damage caused by the first attempt at the solution

This has led to a huge misconception of the product and lots of SI’s walking away from SharePoint projects due to getting seriously burnt and it all "being just too hard".

Why did it happen?

We’ve all seen the devastation its caused in the market place for various reasons:

Everyone is doing everything

"This is a platform people!"…treat each implementation as another solution on a single maintained infrastructure! Don’t let SI’s come in and do everything, it’s unlikely they’ve got the skill sets to do both Infrastructure AND Solutions! There are immense skills sets to do this, SI’s should stick to what they’re good at:

  • If they are known for implementing networks and servers they’re unlikely to be any good at implementing a Document Management System on top of SharePoint.
  • If they are known for implementing a Document Management System on top of SharePoint, they’re unlikely to be able to architect networks and servers!

Hopefully you get where I’m coming from! It also means that your people have to know so much and training people up becomes a nightmare. The other issues is you have pockets of knowledge and usually too much dependency on one person in the team. This results in SI’s dumping junior guys into implementations where they’re learning on the job, but being charged out at "SharePoint Developer" rates.

I’ll finish this bit with a question…"Would you let an electrician come back and hang some doors in your house?" e.g. "Would you let server admin guys write CSS and XHTML to build your Internet Site in SharePoint?" The sad thing is plenty are!

Microsoft’s "Certification"

I can confidently say this now as I have all four MCTS certifications for SharePoint, which are broken up into Administration and Development for both MOSS and WSS.

This really doesn’t test anyone’s skills deep enough to be worthy of a certification compared to other Microsoft certifications out there. If you took on someone who had an MCTS in MOSS Development and ask them to go implement a large scale Business Data Catalogue solution or InfoPath solution, they’d be stumped.

The certifications just don’t go deep enough and SI’s and Organisations just assume that an MCTS MOSS Dev certified developer can do everything in the MOSS stack which is ridiculous!

"Dog of all trades, master of none"

Organisations buy into the marketing and then realise that there is a lot of implementation to be done after it’s all installed to make it operational. Blogs are no where near ready for Enterprise 2.0 out of the box! Check out my Leveraging the SharePoint Platform series to read more on this.

Cutting Corners

There are so many ways to do things in SharePoint (see SharePoint Implementation Approach Comparison Chart) and usually because it’s such a complicated and expensive process to purchase and deploy the base platform, when it comes to implementing the initial solutions such as Intranets…corners are cut! Mostly by not investing the time in Developing Solutions properly and just hacking away at out of the box files because its quicker.
A lot of projects have been awarded to the SI who had the cheapest quote and it’s usually due to the overhead costs of doing things properly over getting it done. This always bites the Organisation up the backside, but by that point its too late!

Upgrades too hard

I’ve seen plenty of implementations where corners were cut and then there was no confidence when it came to even try to upgrade the underlying platform. This has left organisations stuck on RTM with lots of bugs and missing new functionality available, for example, the extra Search functionality in the Infrastructure Updates.

Blame game

We’ve all been there…"it’s the SQL server"…"its the development code"…"its the load balancer"…"it’s the SAN". There’s a lot of blame pushed around. This causes lots of projects to stall and people aren’t all that helpful and trying to pin point the issue as a team. They tend to only even investigate it once every other possibility, other than their precious area, has been discounted.
Often the support team, due to not having any knowledge, throw it straight at the developers…even though it could be a simple security administration issue that they are responsible for.

Poor Development Tools

So most Developers do cut corners because the tools just aren’t helpful enough and the community has done an amazing job of writing them.

I’ve created a new ‘Ultimate SharePoint Development Tool‘ page on the wiki which explains what SHOULD be available to Developers on this platform. Please please please get on their, log in, and add the features YOU want to see!

Microsoft rely on the community too much

With SharePoint 14 on its way, I’d really like to see the content available on its release and not slowly being released on MSDN on a case by case basis. This will be especially so with FAST integration and Performance Point being put into the Platform. The community shouldn’t have to rely on other community members to publish information on how to do things. The MSDN Forums are great, but the information is not structured and makes it hard to find solid authoritative content.
If SharePoint had been released before the Internet was prevalent, it would have failed because Microsoft would not have been able to keep up with the support calls that occurred. Internet Searches save SharePoint consultants on a day to day basis!

What next?

So I’ve already discussed some of these things in my most popular blog post ‘Solution Development in SharePoint 2007′. This is now broken down with a bit more responsibility shown:

What Microsoft need to do

  • Don’t rely on the community – focus on MSDN content being ready for SharePoint 14! Link to community content and leverage it if it isn’t in MSDN.
  • Focus on the Developer Tools - if the tools are easier to use and conform to standards, they’ll be more successful implementations out there and more developers will come on board from .NET world…forget about it otherwise…leave it to the Community!
  • Split up the exams – they need to break up the exams to isolate particular skill sets. Sure, have a platform framework cert, but then also have separate ones for InfoPath, BDC, Excel Services, Search for MOSS Dev for a start!
  • Learn from other platforms – they need to open their eyes and ears to other platforms like SAP who have already been through this pain, I don’t want to be tarred with the same brush that a lot of SAP engineers are across the World!
  • Partner Badges – Microsoft should award more distinct Services badges for SharePoint. Differentiating between those who can do Infrastructure and those who can do Implementations both Customisations and Development (see Defining SharePoint Development on the
  • "Dog of all trades, master of none" – be more honest on where SharePoint’s strengths are and in the sales material that the Organisations see, indicate where it’s not ready yet or better still leave it out!

What SI’s need to do

  • Be Bold – sure there’s work out there in the infrastructure space, but if it isn’t your strength…be bold and stick to what you know. There’s plenty of work out there and Organisations will respect you in your strengths and not judge you on your weaknesses.
  • Partner - if it isn’t your strength, partner with another SI that can do it with their eyes closed…then they can let you do the bit they can’t do and you form a perfect partnership!
  • Train your team – there’s plenty of SI’s out there who are "too busy" to give their team time to skill up properly. Schedule time for your team to skill up and have programs to find team skill gaps.
  • Best Practice – spend the time investing in setting up a Development practice to develop and deploy solutions properly.
  • Transition to support – when you implement these solutions, ensure that they are transitioned to support. Trust me, it’ll do you huge favours in the future where you don’t just get dumped every error!
  • Work as a team – For the market to trust Partners, people need to play as a team and not fall into the blame game.

What Organisations need to do

  • Isolate – Like other platforms, have separate SI’s for Infrastructure and Implementations (Customisations and Development). This mitigates lots of risk around having all your eggs in one basket!
  • References – Do your homework and get solid references for previous projects. Sounds obvious, but you’d be surprised how many large projects have gone a stray and the SI’s still continue to get work!
  • Get Help with Tender Requests – ask Microsoft or an independent consulting firm to help write tender requests. Don’t just cut and paste from sources and then complain when the quotes come back and they’re too expensive because they’ve put so much contingency in as the scope was open ended. SI’s will stop responding if this carries on in the market place!
  • Don’t just assume SharePoint - don’t just assume that just because the Organisation has SharePoint that everything should be implemented in it! This is regularly occurs, know the limitations and boundaries of the platform. ASP.NET Web Forms and WPF Applications are still the answer to solutions.
  • "Functional Requiremetns" – Keep your requirements Functional without technology to drive this.
  • Don’t compromise – don’t go for the cheapest option and cut corners, ensure quality in all implementations.
  • Define levels of support – define the levels between each time involved in the SharePoint platform.

In Conclusion

I’d love to have the $$$ to fly and speak at the SharePoint Best Practice Conference on this, but unfortunately the bills take priority! ;-) I would strongly recommend that people keep up with the conference and also the generosity of the presenters in distributing their slide decks after the fact! Great work by all but especially Ben Curry in organising it all!

9 thoughts on “The SharePoint Implementation Market needs to grow up!”

  1. Great post, Jeremy! I agree that too many SIs get involved in projects they are not qualified to do. Designing solutions on top of SharePoint is not a job for “techies.” There’s a reason to why surfboards are designed by surfers and that sailing boats are designed by sailors. They understand what is required. Similarly, SharePoint solutions should be driven by the business and their requirements and not by the SIs showing off all the bells and whistles that they understand technically. That does not mean some SIs cannot develop expertises in designing certain business solutions, but as you say, that’s completely different to being an expert at enabling SharePoint as a platform by providing the infrastructure services required.

  2. This is your best work yet – reflects a real maturity in your thought process and putting everything into perspective. Great work Jeremy

  3. we’ve been saying the same thing for the last year or so regarding SharePoint implementations. This article along with these below points to some very interesting new ideas around collaboration…………and skype…..I mean whats the difference?

  4. Interesting article and while I am in agreement with most points. There is one I wouldn’t mind providing an alternative opinion. I would love to hear your thoughts on this.

    You mention that the exams are a bit perhaps too surface level and broad on SharePoint. – “Split up the exams – they need to break up the exams to isolate particular skill sets. Sure, have a platform framework cert, but then also have separate ones for InfoPath, BDC, Excel Services, Search for MOSS Dev for a start!”

    I actually feel that these areas don’t have enough depth for it’s own certification. If you look at the extremely deep frameworks that exist out there that have multiple levels of certification it makes sense to me. In SharePoint (this is based on professional experience) the API and depth of the development model isn’t deep enough to warrant it’s own certification on an individual component basis.

    The BDC is relatively simple once you begin working deep down inside of it, as are excel services and the other aspects of SharePoint/supporting technologies outlined here (search I might consider). I am all for more certifications but I think that too many certifications can have a detrimental impact, and to be honest if a developer passes the MOSS and WSS developer exams they should have the skills set to do almost anything in SharePoint, it’s just a matter of following best practices and .Net standards, not necessarily SharePoint ones.

    A bad developer is a bad developer not because of the structure/support of development information in my experience, they are a bad developer because they don’t search or take enough responsibility for the knowledge they agree to possess. If you say you are a SharePoint expert, then you should have considerable experience as well as the certifications. If you describe yourself as someone who can do all the development work WSS and SharePoint provides and have the certifications, then you most likely can, it’s just a matter of properly estimating time, scope, and the need to explore available sources of information.

    This is just a thought on this, I love the writing, but this one point I just felt the certification system (at this point in time) is pretty solid, considering there is an architecture and master track.

    Anyways thank you for this great post and hopefully it saves lots of organizations time, and gets them to think carefully before jumping the gun on anything. :)

    Richard Harbridge

  5. Great post
    Really touches on what both SI and customers need to think about. I think this year will really define the SharePoint market place. After spending a few weeks in the US at SPTechCon and Best Practice my head was exploding with SharePoint. The interesting part was that very little of my notes were technical. A SharePoint project needs planning. Be very wary of the consultant that comes in and on the first day wants access to the servers, CD’s and admin logins. There is so much to be done before that.
    Good work on the post, looking forward to the followups

  6. Great post.

    I would like to add that from my perspective it is difficult when you’re employed by a company in a SharePoint role (not contracted). A lot of companies tend to see you as ‘The SharePoint guy’ without really caring what your speciality (or experience) might lend itself to. A common misconception by employers is that SharePoint is a ‘product’, when as we all know it is a collection of products with a multitude of layers, capabilities and disciplines. Anyway, the point that I am making is that I personally like to be clear about what I can and can’t do before undertaking a project, but I’m commonly asked “aren’t you a SharePoint guy?”, meaning employers still don’t get what SharePoint is. In my particular case, this is an issue because I’m the only SharePoint resource in the company!!!

  7. Jeremy, this is great stuff.

    I find a lot of the time, it’s the organisation that brings you in as the SharePoint person and then starts asking you to build server farms ‘and’ develop the document management system that are at fault.

    It’s pretty difficult when just starting a new role, to tell the organisation, I dont do that area, you need a network guy etc. etc.

    Can be v frustrating. :) That’s life I guess!

Leave a Reply