Sitting on the train today heading home, I’m thinking about the days’ events and I can’t help being reminded of clients I’ve worked with especially over the past four years. Until recently, SharePoint hasn’t been viewed as mission critical and was designed, deployed and managed with that in mind.  Clients would often tell me about their pain and provide examples that really made me think about what I must do to help them.

I often wonder if companies knew what they were getting into. Based on observations made while working with clients, I believe organizations designed, deployed and managed SharePoint like they would an infrastructure component (as opposed to a client facing business tool that reaches deep and wide into an organization) – assigned it the importance of a nice-to-have service and didnt establish a comprehensive governance program.  What clients end up with is a SharePoint environment plagued with problems and out of control.

These sorts of problems manifest themselves as:

  • Erratic performance
  • Capacity is unknown
  • Data contained in sites is unknown – compliance risk
  • Customizations wreak havoc on the platform
  • Lots of finger pointing and blame directed at all
  • Not many solutions to the problem or answers to questions
  • No focal point for accountability
  • No focal point for consistent decision making
  • Costly support bills
  • User perception of service very negative

What is the solution? It’s sort of like a “piece of string”, the solution is comprised of many initiatives tailored to the reality of your organization. It could be a 12 month program or 3 year program – really depends on priority, executive leadership, resources and time.

Having worked in several industries I believe companies could learn from regulated industries because they are accountable to regulatory bodies. From an IT perspective the following is on their minds:

  • Audits – what will they find? Where are my risks? Planning for them?
  • Safe Harbor – do I have any risks? Whats my plan to communicate risks?
  • IQ/OQs – ensuring installation and operational quality

There are many other compliance bodies depending on your location (country) and industry but the net of it is that big brother is watching. As a result IT must establish quality check points and be aware and prepared for audits – this generally increases the level of quality. So what should you focus on? Here are some areas:

  • Governing body and framework – a team of stakeholders (but not a parade) and a senior executive that can deal with grievances and escalations. Generally the stakeholders include business area leads, PMO lead, IT architecture lead and purchasing lead. Beware governance teams that consist of IT only, this isn’t governance and is definitely not going to be effective in driving results.
  • User requirements – a tough subject because the business is generally changing faster than IT wants to move. IT is all about steady state, minimizing change and outages. No simple changes here other than developing relationships, establish a two way learning relationship – entrench yourself in the business so that you know more about your clients’ needs than they do.
  • Architecture – you’ll require deep product expertise an architect with broad experience with your organization and consultants that have done this sort of work before. If you are a large complex global organization it will be tough to find the right skill sets since demand is high. Be ware of architecture documents that are fluffy and don’t speak directly to the products. Broad generalized documents filled with boilerplate content wont suffice. As one of my clients in Manhattan said “ I have a lot of architecture documents on my shelf collecting dust.”
  • Quality Assurance – an effective quality assurance area will have a close approximation of the production environment including the servers, network (and latency generating device), storage and data. They will have detailed test plans the include:
    • Functional testing – do all the click through scenarios work? Use cases addressed?
    • Performance testing – if I load up the platform to its limits where does it break? Will I expose bad code? Memory leaks? Run away cache?
    • Baselining – load platform to set guidelines for performance and thresholds for counters – will feed your monitoring plan. Ultimately you want to be able to support discussions surrounding problems with facts about the platform – how it behaves normally and how it behaves when its approaching a bottleneck.
    • Pre-Production testing – here you build the actual environment in production and then run your tests to make sure the platform performs as it should. Here you can expect to fine tune your farm to get the performance out of it. Here you want proof that the platform has been installed exactly as outlined in the design document and installation guide. Screen shots, signoffs to name a few are required (Installation Quality form).
    • Productionizing – at this point your making sure Operational Quality can be delivered. Have all the guides been delivered? Training to helpdesk/support staff? Known bugs documented? Virus plan implemented?  Capacity plan implemented? Monitoring plan implemented, backup plan implemented (Operational Quality form).

So there isn’t a simple answer, I would say that the quick wins are gone if your reading this, its time for a top down review or your environment to identify gaps and used as a basis for a program roadmap to address your situation. I imagine you will have several stakeholders involved that disagree with each other (might even be adversarial) and in this case your facilitation skills and network will be key to success. On a final note, watch your back, there will be people trying to bring you down.