Discovering New Things at the Technology..,: Top 10 Tips for Success With SharePoint: #9

8/9/2011 9:00 AM by Lynn Warneke

Categories:Top 10 Tips for Success with SharePoint; Adoption; Governance; Project Management; MOSS; WSS; 2007; 2010; General Knowledge

Resource It Right

There are two key dimensions to resourcing of SharePoint implementations – project and operational – but the literature mostly seems to confuse or conflate the two. There’s also, still, a surprisingly enduring bias towards technically-focused resources where SharePoint is concerned, which underestimates and undervalues the critical importance of business-focused resourcing for success. (Just scan this list of posts on this topic that Jeremy Thake has been capturing and hopefully you’ll see what I mean: http://www.diigo.com/user/jthake/roles)
Admittedly, roles and responsibilities can blur, and the plethora of job titles can make it hard to identify who does what in the SharePoint space, but I’m going to strive for some clarification with this post because getting the resources right is important both for successful delivery of SharePoint and for successful operations long after go-live.

The Right Project Resourcing

When you’re deploying, upgrading, or significantly extending or enhancing SharePoint, you will probably do so within the structure of a project.
From experience I’ve found a mix of internal staff and external resources with a range of capabilities usually makes for the best project team. Unless you have a very strong in-house skill set in SharePoint, partnering with a solid implementation provider is a project Key Success Factor. With a strong understanding of the platform, there’s much greater certainty of designing a SharePoint-based solution that meets your goals and fully leverages SharePoint’s benefits, while avoiding common traps for young players.
Strong, effective and skilled Project Managers are worth their weight in gold. Personally, I’ve found good people and communication skills, an eye for detail, and vendor management expertise are more important attributes for the PM than deep SharePoint skills.
In addition to a great PM, you should carefully consider the need for the following project roles; though what roles are mandatory, and how many incumbents you should aim for per role depends on what you’re deploying SharePoint for and the scale of the project. On smaller projects, two or maybe more roles may be undertaken by one person; and on large/complex projects, some incumbents may have delegates or each role could be further broken out into sub-roles. When building a SharePoint project team, the main thing is to carefully assess your requirements to identify the scope and diversity of skill sets needed for delivery. Also, unlike the PM, I do believe that most of the following roles need excellent SharePoint skills and experience to produce the best solution.

Solution Architect – interprets business requirements to design the logical and physical solution
Business Analyst / SharePoint SME – gathers and interprets requirements and aligns to SharePoint features and functions.
This role is particularly important when SharePoint is being deployed for business process improvement, which SharePoint’s collaboration features and workflows are expected to enable (enormously useful if you have a BA who bridges the business and technical domains well)
Information Architect & Usability Specialist – designs the ‘information model’ for the SharePoint solution, including navigation, site structure, taxonomy (content types, metadata, etc.) and even page layouts
Change Manager – prepares the change strategy and user adoption plan, including communications and training (e.g. Training Needs Analysis and plan)
Infrastructure Manager – prepares the infrastructure in accordance with the solution design
System Administrator – installs and configures SharePoint and SQL, implements back-ups and system monitoring
Content / Migration Manager – prepares the plan for creation of new content or migration of existing content into the new SharePoint solution (Also: EDMS / Records Manager)
Developer – develops any customisations required, integrates third party products, etc. May also implement branding, script migration tools, build custom InfoPath forms and page layouts, etc.
Quality or Test Manager – quality controls and tests any custom developed components, integration, etc.
Branding Specialist – skilled user interface designer, who creates and ideally implements a custom brand for SharePoint. Sometimes a UI designer can do the former but not the latter, and a Developer is needed to implement custom CSS.

Internal Resources

Even if there’s a low level or complete dearth of SharePoint expertise within your organisation, I don’t advocate outsourcing the entire project to external resources. It’s very important that the people who are expected to use and manage SharePoint after it’s deployed are involved in its design and deployment – and not at arm’s length by way of Steering Committee membership or participation in the odd business or technical requirements workshop session. And I mean fully involved, with specific project responsibilities (though they don’t have to be seconded full-time). With greater skin in the game comes greater buy-in and ownership of the solution. And the quality and ‘fit’ of the solution is usually greatly enhanced by the nuanced insights of permanent staff who know the organisation in ways few external providers are likely to achieve in a limited project timeframe. For example:
Include your Communications or Training or HR Manager(s) in the project team with accountability for Change Management. If you have an internal design or marketing team, they should have involvement or at least sign-off on the visual design – even if that means your SharePoint specialist has to devote time to advising them on what should and shouldn’t be attempted regarding SharePoint branding.
Try to ensure your IT staff are responsible for key aspects of the technical implementation: if necessary, partner them up with a counterpart in the vendor team who’s not just expected to build, develop and configure, but also advise, mentor and up-skill your staff too. For example, the experienced provider or contractor might deploy and configure Development or Test environments while shadowed by the in-house IT staff, and the latter could then build the production system to acquire valuable hands-on experience.
And so it goes; I’m sure you get my drift. Yes, you might need to fund a business-focused SharePoint SME to spend time not just building the solution but building internal staff knowledge and expertise too. But the ‘teach a man to fish’ rule of thumb can pay significant dividends post launch.
In determining which permanent staff to involve in a SharePoint project, try to think ahead to life post-project. Who will have ongoing responsibilities for aspects of the solution in the future? They’re probably the people to invite into the team up front. One role I can guarantee will be necessary is a SharePoint Business Manager or Administrator or Coach or Steward or whatever you want to call him or her. Wherever possible, I advise my clients to nominate or recruit this role at the outset, involving them in the design and delivery of the SharePoint solution that they will be helping to manage and grow subsequently (see the section below on Operational Resourcing).

External Resources

Most medium to large SharePoint implementations I’ve been involved with have included external providers – i.e. a vendor company (they like to be called ‘partners’) or perhaps a small army of contractors, or both, with specialist skills in SharePoint. External providers have the benefit of exposure to many different environments and should have created a wide range of SharePoint-based solutions for many different clients in their time. Additionally, they’re usually well-connected in the SharePoint community. These characteristics can and should be leveraged to ensure your SharePoint deployment is best-of-breed.
Apart from the extreme skill and knowledge factor, a further benefit of resourcing a project team with external staff is that you pay for what you need when you need it and not beyond. Not all roles in your project team are needed on a day to day basis once in operational mode. As always, it depends on the nature of your implementation, but I don’t believe a majority of SharePoint implementations require ongoing branding or need a permanent solution architect over time (though you will often find these listed as mandatory for any organisation with SharePoint). In my view, these skills may be better procured on an as-need basis. Even enhancements that necessitate custom development can be bundled into logical packets and outsourced to avoid maintaining an in-house dev team.
At a minimum I’d suggest you look for the following in an external SharePoint implementation provider:

Hands-on experience of successful deployments, ideally similar to your SharePoint vision and project scope
Talk to referees, and ask detailed questions about delivery
Solid, demonstrable analysis expertise – both business and technical
Many projects do not recognise the importance of an experienced SharePoint Business Analyst who focuses on the business objectives as opposed to technical issues, and this is a source of project failure or compromised results rather more often than you might think.
Willingness and ability to transfer knowledge over the course of the project, to mentor and help grow your in-house skills
You do not want a partner who is precious about their intellectual capital, builds your reliance on their ‘exclusive’ knowledge of your SharePoint solution over the course of the project until it’s set like concrete, and ties you into to a long-term relationship based on dependency. If the respect and admiration is mutual and remains so that’s great, but you should be able to fly ultimately without needing your vendor to be the wind beneath your wings.
Good ‘cultural fit’ – this is vague, but nevertheless quite important: what I mean is you should match up the partner’s profile with your own as far as possible
You won’t necessarily stand to gain by engaging a high-end consultancy that specializes in enterprise-scale SharePoint services for the top end of town, no matter how glossy their brochures and how impressive their resume and client list, if you’re a relatively small business that needs to extract every iota of value from your limited budget. If you don’t have a lot of experience with vendor management, don’t engage an established and sophisticated provider who overwhelms you with legal contracts, account management and other ‘overheads’. If you have a tiny in-house IT team, ensure your vendor of choice doesn’t assume a large team will be at their disposal to direct on deployment activities. Don’t engage a random bunch of SharePoint contractors and developers if you have no-one capable of herding those cats.
Excellent design, support and maintenance documentation – comprehensive, clear and actionable
This is extremely important to me, but I’m willing to accept the opinion might be a bit niche. However, for what it’s worth … I was once burned by vendors who handed over system documentation of such extraordinarily poor quality that it was impossible for the in-house team to use it for effective management of our SharePoint environment, or meet minimum support and DR documentation requirements. We had to re-write most of it, which was no mean feat. On the bright side, we all learned a lot about SharePoint in the process. Conversely, it was a cost that hadn’t been anticipated and it left a bad taste. As a result, I have inordinate respect for partners who provide robust documentation (see also point 3).

The Right Operational Resources

SharePoint, once in place, does not just look after itself. This is abundantly apparent from even a cursory glance at the myriad advisory books and blogs available. However many organisations still seem to believe the opposite, and accordingly they seriously under-resource operational management of their expensive SharePoint solutions post-launch. Then wonder why they start to take on water and sink before their eyes.
After deployment, the SharePoint infrastructure and application environment will need to be well maintained and managed. Presumably installing and documenting an effective monitoring and maintenance regime was established as part of the deployment project. (If not, here’s a Resource Center to help with that critical task: http://technet.microsoft.com/en-us/sharepoint/hh127032.aspx)
Many SharePoint environments can grow beyond the capacity or capability of the in-house IT support resources. Consider outsourcing SharePoint support and maintenance to an external provider who specialises in this (and if you do, put a robust SLA in place). That said, do try to build in-house Help Desk knowledge, even if you outsource formal Level 2 and/or 3 Support & Maintenance, so that end users have a local, responsive first line of support.
But success over time with SharePoint is not just, not even mostly, about technical operations. If you concentrate all your operational resourcing effort and budget on IT, you’re still cruising for a bruising. Well-rounded governance is another, very important factor (see tip #8), but it’s not the full answer either.
From my experience many – dare I say most? – end user questions and operational concerns will be purely business related and have zero technical substance. In the absence of any alternative however, these are likely to hit the Help Desk and technical staff may find themselves acting, probably reluctantly and ineffectively, as de facto business analysts and advisors.

When, How and What?

At the most basic level, questions (and, if you’re not careful, frustrations) will proliferate about how and when to use the new SharePoint functionality properly. For example, even ‘simple’ things like check in and check out on document libraries confuse many people. How will you ensure that people know what features are available in SharePoint, and when and how to use the right one to meet a specific business need – how, for instance, do you prevent end users from creating a wiki if their problem would be much better resolved by a custom list?

Why?

Beyond – or perhaps it’s before – the when, what and how questions, it’s actually the why questions that require the most time and energy of operational resources, but are at the heart of SharePoint success.
Why should I use metadata instead of a folder hierarchy in my Site? Why should I bother tagging content? Why should I use a SharePoint document library instead of a file server? Why should I transfer data from Excel to a SharePoint list? Why should I use a Team Site when email appears much easier? Why should I upload a photo or write a profile statement about myself?

Who?

So who do you think will answer these what, when, how and why SharePoint questions? Not IT, in all probability. Common, frequently recurring questions are relatively easy to deal with (FAQs, short videos, cheat sheet). But who will address the unique, often highly specific issues and needs that arise department by department, team by team, group by group. Who will analyse a given functional unit’s business processes and advise them on how to improve these with online SharePoint workflows or build a process wiki?
The Change Management plan might include something about identifying and building champions or power users, distributed content stewards and publishers, or departmental owners of SharePoint Team Sites. These are all valid and important operational roles. But who supports, trains, advises, encourages, guides and wrangles these disparate groups with their disparate needs and concerns?
Enter the SharePoint Business Manager / Evangelist / User Adoption Specialist / Translator / Steward / Coach.*
Appointing a dedicated, SharePoint-savvy Business Manager for your solution is therefore strongly recommended, as I believe this is an essential ingredient of any recipe for success with SharePoint. Whether your solution is an intranet, a collaboration environment, a website, DMS, BI platform or other, this is one piece of advice I can’t stress highly enough.
Depending on the size and scale of your implementation, you may need to consider more than one person, or more than one business-facing role. For example, a dedicated Collaboration Manager who exclusively encourages and supports Site Owners and users of Team Sites for collaboration. A SharePoint Training Manager may also be advisable. Many businesses make the mistake of thinking one individual will be able to cover off everything, but while there are a few SharePoint superhumans about, often a team is necessary. Not necessarily big on numbers, but big on talent, skills and enthusiasm.
I’ll just circle back to IT to complete the list. While business-focused SharePoint Managers will know a great deal about the platform, they’re not technical. Therefore a Solution Manager with deep SharePoint technical knowledge and experience is another vital role for the long term. These two key roles need to work in partnership to ensure SharePoint is well maintained and supported, but also optimised over time in line with IT and business needs.

Other Resources on Resourcing for SharePoint

Veronique Palmer’s JDs for various roles: http://www.letscollaborate.co.za/Resource-Centre/SitePages/JobDescriptionsIndex.aspx
Veronique again, posing the question “Do you need a SharePoint Whisperer?” http://veroniquepalmer.wordpress.com/2011/05/24/do-you-need-a-sharepoint-whisperer/
And again, on “How NOT to advertise your SharePoint position”: http://veroniquepalmer.wordpress.com/2011/04/27/how-not-to-advertise-your-sharepoint-position/
And the book Essential SharePoint 2010: Overview, Governance and Planning by Scott Jamison, Susan Hanley and Mauro Cardarelli has a useful section on Roles and Responsibilities for SharePoint operations.

Summing Up

SharePoint implementation/upgrade project teams require a different mix of roles and responsibilities than teams involved in the ongoing management of SharePoint
Projects benefit from the complementary skill and experience of internal staff and external SharePoint implementation partners
Business and technical roles should be dedicated to SharePoint’s ongoing management for greatest operational effectiveness

* U P D A T E
The SharePoint Contender has a fun, and insightful, three-part musing on this rare beast that is this SharePoint-savvy Business Manager here: http://sharepointcontender.wordpress.com/2009/12/30/sharepoint-identity-crisis/

Discovering New Things at the Technology..,

Wednesday, May 2, 2012

Top 10 Tips for Success With SharePoint: #9