Thursday 2 June 2011

Budgeting for SharePoint

At Salem we fret about why so many clients have no idea how to budget for SharePoint and in particular why so many aspects of a SharePoint programme budget are missed or left on the table. Clearly there is a very basic view that all a client needs to do is budget for the platform and architecture and everything else will fall into place. At Salem we witness a number of projects (fewer programmes) where the budget really isn't satisfactory and money runs out due to bad planning too early in the cycle. That is not to say a great deal of budget is required, but more about correct forecasting of potential costs from the start.

Of course there are many variables such as whether a solution is on-premise or off-premise, whether the client is looking for a simple single solution or whether there is a long term programme strategy, whether there are sufficient skilled resources in house and the level of licensing. If a client can anticipate potential costs and expenditure up-front and plan accordingly then the process becomes a great deal easier.

There are other issues worth considering. The first is that some partners do not like committing to 'cost guides' and refer purely to T&M (Time and Materials) which means a typical CIO has no idea how much a solution will actually cost until once all the requirements have become clear. This is extremely difficult to budget for, particularly in public sector organisations who typically work on annual fixed budgets, set well in advance. The second is that a business solution is very often offered to the client as a bespoke, custom or developed solution when there are increasing numbers of commoditized SharePoint business solutions on the market that often fulfill 80% of what a client requires without any real development at all. Also bear in mind that for some more traditional engineering-focused partners, offering cloud solutions doesn't (in their mind) perpetuate their established income route.

What is important to recognise for all clients is a value proposition in line with budgeting.  For example a typical corporate intranet (forget the term 'digital workplace' as it lacks focus and definition) has certain core elements that are pretty standard. Therefore it is feasible to offer ball-park prfojections for the cost of an intranet based purely on experience. However for the client, it is very important to recognise that most partners will add in a margin to ensure they are covered against scope creep (which often happens) and unknown requirements early in the cycle, and this should be factored into a budget proposal. Ultimately, however, one cannot compare, say, the cost of a traditional html-driven website and a SharePoint intranet as one is not comparing like with like.

Finally we are yet to see any organisation truly budget for SharePoint adoption or training and frequently costs of this are dramatically under-estimated both in terms of expenditure and in applied costs via impact on business-time. It is essential to plan training costs up front and ensure they are budgeted for.

The following is a quick tick-list of elements of any SharePoint solution that should be considered in the budget planning cycle:

  • Strategy  - without a business aligned strategy for SharePoint, the plan may fail. Budget to put an effective SharePoint strategy in place with consultation costs for the required parties
  • Infrastructure - the actual cost of hardware as well as installation, configuration, maintenance and support. In situ support vendors may increase their support fees due to the introduction of a new platform
  • Cloud - the cost of cloud license services and administration and support costs as well as configuration
  • Licensing - Don't forget to cosndier your current Microsoft license agreement, how many server cals and end user cals you need, whether you will need enterprise licensing and how many e-cals, and licensing for internet services
  • User interface design - depending on the level of branding, there may be a requirement to budget specifically for detailed user design using a specialist desigh agency via a partner. Few partners have large in-house design teams. Also add in the cost of user experience analysis
  • Cost of data migration - whether it is bespoke or migration tools that are required, or partner migration services and consultation data migration and current data analysis and cleansing costs should be considered and factored in
  • Reduction through integration - if you aim to integrate into SharePoint, the cost of closing down other services can sometimes be substantial so take this into account. You may also have to support parallel environments for some time
  • Partner consultation - SharePoint requires expertise and is not something that should be treated lightly. You may require the services of one or more expert SharePoint partners as well as sklills in supporting technologies. If you do not have this expertise in-house you may need temporary contractors and consultants as well as partner skills
  • Delivery - you must factor for in-house cross skilling during the delivery phases and a range of internal support costs. You will also need to budget for partner services during delivery, cost the impact on business time and any cosst for UAT and testing as well as quality assurance.
  • Role recruitment - if you need to recruit skills then there are higher costs for contractors or new fulltime staff and you may need to budget for agency fees and commission.
  • Adoption - business and IT adoption of any new technology impacts business time and requires an overarching strategy. You should factor in these costs and do not ignore them or down play them.
  • Training - training is often a mix of blended media that all costs money and time to prepare and deliver. Training requires expertise to deliver effectively using a range of media and these elements should be budgeted for.
  • Communication - without a communication plan, your business audiences will be in the dark. You need to cost out the elements that will produce and deliver and effective communication plan.
  • Content creation - almost always missed but when delivering a new SharePoint business services it is very plausible that fresh new content will need to be prepared and written. Who will be doing this, how long will it take and how much needs to be created - at what cost?
  • Support - how much will you budget to cross-skill and retrain internal staff or even recruit new support skills. Perhaps your maintenance contracts will need to be re-scoped and you may potentially need to budget for a new support contract with your specialist SharePoint partner(s)
  • Administration - consider the day to day costs of running your SharePoint server farms at both the front and back ends. Do you need administration software such as Axceler Control-Point too. Consider whether Cloud services make more sense to cut down on administration costs.
  • Development - development is cheaper than enterprise licensing? No we suggest this is false economy! There are a wide range of enterprise services for SharePoint, which, out of the box, may provide fast feature rich business services that are far mor cost effective than individual developed bespoke solutions. Commoditised SharePoint services can bring the cost down from many excellent 3rd parties but you must remember that any developed solution must be maintained, supported, documented and amended, particualrly for platform upgrades. In other words there is a hidden cost of development that is frequently not budgeted for. Developers will need to be paid and what happens when they leave?
  • Maintenance contracts - as suggested elsewhere in this list, maintenance costs should be considered from the outset at the strategy and planning stage
  • Business impact - typically an IT department will forget or avoid placing a cost on the impact to business time in terms of UAT, going-live, a temporary drop in performance, training and adoption activities, new support processes etc. It is far better to forecast this up front. 
  • Process redevelopment - changing processes costs time and money irrespective of whether technology is easy to use. Business change should have a notional cost set against it per process change.
  • Removal of other services - decommissioning costs money and you may be tied into legacy support contracts for longer than you had planned where co-existence remains a requirement
  • Agile business services - consider how are you budgeting for the growth of ad hoc SharePoint services and the personnel who will be delivering them.
  • Annual cycle - take on a programmatic plan for SharePoint, forecast the business service release-cycle annually and budget in advance. Even better look at a multiple year model and budget up front for multiple years
  • Scaling - budget for growth and success. How much will you need to set aside for SAN storage growth and server capacity, and what tools are you going to use to measure the growth and how will you facilitate more space as it becomes required ? Also consider that you may move from one server farm to multiple server farms in international and large organisations as services bed in. This should be planned for early in the budgeting cycle.
  • Integration with other technologies - you should consider how much it may cost to interface co-existing systems such as SAP or PeopleSoft and the ongoing costs of this process.
Again this is not supposed to be a complete list but an effective start list which may be appended to. If you have started by simply budgeting for some servers, then your SharePoint budget will quickly be eaten up and robbing Peter to pay Paul may simply not be an option. SharePoint is an extremely cost effective solution, and the more a budget is planned correctly and aligned with an overarching business strategy from the outset, the easier it is to prepare the business case and plan the costs appropriately.