Why You Should Use a Consultancy for Your SharePoint Project

Recently we completed a detailed analysis of our blog traffic. We were surprised at the amount of traffic we receive from around the world. That in mind, I decided to post this blog and a related few which have been on the back burner for some time now. Since PointBridge is located in a different country than many of you are, I hope that you will see this series of blogs for what I intend it to be rather than considering it self-serving. Nonetheless, in the interest of full disclosure, you should be aware that I am a huge SharePoint fan.

Assuming that the decision to implement SharePoint, either Windows SharePoint Services (WSS) or Microsoft Office SharePoint Server (MOSS), has already been made, one of the most important decisions you are going to make as you begin your planning is deciding who will do all the work. Basically you have two sources from which to build your team: internal staff and outside consultants. Making the best decision possible is critical to the success of your implementation. If you are going to use a consultancy, you should not completely outsource the entire project but rather should plan on building a strong blended team. Essentially then, as I see it, you have two options: use internal resources or build a blended team. (Read more about creating blended teams.) Here I want to address the question, Should your SharePoint implementation team be composed of internal resources only? It’s a topic that hasn’t received much attention, at least not that I have seen. If you are interested in other SharePoint success factors and how to address them, you can read these: If You Build It, and Getting the White Out.

As you start to consider the plusses and minuses of your options, there are a number of factors you will likely consider. Not all of them will or should be directly related to SharePoint. As an example, availability of internal staff might be a determining factor in your decision.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

That said, SharePoint-related factors, in particular the breadth and depth of SharePoint knowledge and experience that your project team can bring to your project, should be considered carefully and weighted heavily. Additionally, there is a long list of technologies that SharePoint is built upon including Active Directory (AD), SQL Server and Internet Information Services (IIS). Knowledge of these is important. Finally, experience with other products that extend the usefulness of SharePoint, for example Microsoft Office Communications Server (OCS), Rights Management Services (RMS) and Systems Center Operations Manager (SCOM) are important considerations.

Nevertheless, some organizations decide that all that’s really necessary to implement SharePoint is to get it running in a lab environment, ask a .NET developer to create a few web parts, procure a production-level server or two and deploy SharePoint – Fait accompli! The thinking goes something like this: “WSS is free, how much can there be to it? MOSS just adds Search and a few other features”. I have seen organizations take this approach only to discover a few months later one or both of these:

• they have too few or under-provisioned servers, poor performance, insufficient guidelines and governance and, yes, an urgent need to “reign it back in”, or even worse,
• nobody is using SharePoint anymore.

Consider this for a moment; Microsoft invested hundreds of millions of dollars in the research and development of SharePoint 2007 – WSS and MOSS. The SharePoint product group numbers hundreds of employees. WSS, and MOSS to a much greater degree, both encompass knowledge bases of substantial size, for example:

• Microsoft’s planning, deployment and configuration documentation available on TechNet totals roughly 2400 pages for MOSS alone. If only 25% of that applies to your project, your systems or network resources will need to be conversant with about 600 pages of documentation.
• The two main SharePoint assemblies, Microsoft.SharePoint.dll and Microsoft Office Server.dll contain approximately 2300 public classes (not including interfaces and enumerations). It is not unreasonable to assume that your developers will ultimately need to use as many as 150 to 200 classes. Knowing which member of which class is of course the Golden Fleece for developers new to SharePoint.

You need resources that can hit the ground running (unless you are one of the fortunate few who do not have a production date facing you). Your implementation team, likely 2 to 5 developers, a system or network administrator and possibly a graphics designer, must possess a shared knowledge of SharePoint’s workings and a common understanding of how work will be deployed to production. Just as importantly they need to be able to fill in the holes in their knowledge – and there will be holes – quickly and accurately.

So back to the main question, do you source internally or build a blended team, and by extension, if blended, with whom? Here are a few points that you should be aware of:

• SharePoint 2003 (even WSS) is very different from SharePoint 2007. Experience, even extensive experience, with SharePoint 2003 though somewhat helpful is not a substitute for solid SharePoint 2007 experience.
• The lower cost sometimes attributed to internal teams can be misleading if the project team’s costs are melded into normal SG&A costs and not called out as project costs. This is particularly true if there is a substantial learning curve associated with the technology, which is the case with SharePoint 2007.
• External resources are generally more realistic than internal ones about whether a particular business problem can be effectively solved by SharePoint and conversely whether applying SharePoint to a specific problem is appropriate. Internal teams, in their exuberance, often try to use SharePoint to address every business or technical issue associated with the project.
• A team that includes external resources experienced with SharePoint will possess the necessary knowledge when it’s needed as well as being able to direct the team to avoid pitfalls that make future maintenance difficult and costly.

It should be clear by now that my view is that external consultants ought to be included on most SharePoint implementation teams. A good SharePoint consultancy, one that is professional, will work hard not only to meet and exceed expectations but to ensure that when their work is finished the client organization is fully prepared to carry on. Not every organization that does SharePoint work is a good SharePoint consultancy however. There are a few characteristics that you should look for in the consultancy you use for your SharePoint implementation. If the consultancy you select meets each of the items listed below, your SharePoint implementation is one very large step closer to success.

1. Your consultants ought to use MOSS extensively in their company: each of the six pillars or workloads – collaboration, portal, search, content management, business intelligence and business processes. Furthermore they ought to be willing to give you an online tour of their MOSS implementation. During that tour if you don’t see at least three ways of using MOSS that you’ve never considered, be wary. You want someone with vision.
2. Your consultants ought to be sharing their knowledge with the larger SharePoint community. That doesn’t mean that all their IP is available for download, but they ought to have substantial and fresh blog and other SharePoint-related content posted on their web site.
3. If the consulting organization you are considering doesn’t have at least 10 consultants dedicated to SharePoint you should be cautious. Additionally some of those consultants should be dedicated to infrastructure and others to development activities.
4. If those 10 consultants don’t average 1.5 to 2.0 years experience with SharePoint 2007, look closely. SharePoint skills are in demand and there are a number of “consultants” popping up with 3 to 6 months of experience. Given the points made earlier, you’d be better off with an internal-only team than a consultancy comprised of many new SharePoint “consultants”. (SharePoint 2007 Release to Manufacturing occurred in November of 2006 and β-1 code was available the previous May so be careful of unrealistically large numbers and adjust the 1.5 year metric upward relative to this blog’s posting date.)
5. You consultancy should have completed from 15 to 20 SharePoint 2007 projects, assuming 10 consultants. Much more above or below that and the breadth and depth of SharePoint experience is likely pretty limited. (Again, adjust the metric upward relative to the date of this blog and as the number of SharePoint consultants moves upward from 10.)
6. If you are upgrading from an earlier version of SharePoint, make sure the consultants you are considering have performed at least 5 upgrades. No two are the same and they are all very involved. Planning is paramount and the final production upgrade can be very difficult. You don’t want someone cutting their teeth on this. More importantly, you can’t execute an upgrade well if you don’t have substantial experience with both SharePoint 2003 and SharePoint 2007.
7. Your consulting partner ought to have an arm that is also very experienced with Microsoft’s Unified Communications products. Adding the integration capabilities of the products in this group makes SharePoint even more useful. The same is true for products mentioned earlier like RMS, SCOM, Identity Lifecycle Manager (ILM) and others. Even if you are not planning on implementing these products and technologies initially, you should be able to leverage your consulting organization to help you plan appropriately. There should be no need to find a second organization if you select the right one from the beginning.

As the SharePoint Solutions Architect for a consulting firm located in Chicago, Illinois, am I biased in my view? Certainly. Nothing I have discussed here is fabricated though. I have seen many large, medium and small organizations seriously underestimate the skills and experience necessary for a successful SharePoint implementation and as a result deliver a poor implementation.

Personally, I would rather see an organization not implement SharePoint than to implement it poorly. A poor implementation creates the erroneous impression that SharePoint is a poor product, and as I said at the outset, I’m a huge SharePoint fan.