Count no day lost in
which you waited your turn, took only your share and sought advantage over no one. (Robert Brault)
The different cakes
There are five separate pots of money to ringfence for ongoing portal funding:
Essential Infrastructure Investment - including the scaling up of networks, hardware & software for growth
Platform Maintenance & Support - costs of supporting, maintaining & upgrading core portal components
The Central Portal Team - who will govern the steady state portal and take care of the primary navigation
Small Change Provision - for ongoing minor enhancements
Larger Change Provision - for new functionality developments
Cost Allocation
The simplest funding method is to
treat costs as a core central (or strategic) overhead and to retain it in a single business unit, rather than sharing it out.
This treatment may well be appropriate for pot
1 (essential infrastucture), where most costs are step-fixed in nature and - were these to be shared out to businesses - there would be the 'straw that breaks the camel's back'
risk where one unlucky project has to meet the full cost of scaling up the infrastructure to the next level.
Cost Apportionment
In this model, the costs are shared between business units on an activity- based driver (e.g. usage).
This method may well be appropriate for pots 2 & 3, where the costs incurred tend to benefit business units in direct proportion to their portal usage.
For
example, one could apportion support costs to businesses, based on the number of logged faults from their areas. One could apportion Central Team costs based on the number of
unique user sessions from each business unit.
Cost Absorption
In this model, costs are shared between businesses
through inclusion in their direct cost of materials or labour; Thus the costs become a part of their cost of sales or direct overheads.
This may be appropriate for the
costs of maintaining and supporting certain applications (pot 2) and for some development costs (pots 4 & 5).
For example, if one developed a portal application to help an
area to better control the assembly of sub-components (in a manufacturing process), the costs of this application could be incorporated into the cost of sale for the finished products
concerned (in that division).
Where to budget for ongoing change
Where planned changes are to the benefit of most or all users in
the organisation (e.g. a leave request application) then this application will most probably be accessed from the primary navigation.
As such, it makes sense for the Central Portal
Team (or appropriate alternative Central Function like HR) to budget for such change (pots 4 & 5).
Where developments are to the specific benefit of a single community, then it
makes sense to budget in that function for the change.
Smaller and Larger Change
For agility, it makes sense to create a single pot for the
likely level of small change during the budgetary period. This pot could be held centrally, or in chunks at major business unit or brand level.
Words of Wisdom
At the end of the day, most internal debates about finance in an
organisation are 'wooden dollar' arguments that (ultimately) do not matter.
The important points to solve are (a) is the money I am spending adding value to the organisation? and (b)
is the way I am sharing it fair and likely to incentivise appropriate behaviours?
Wooden Dollars? Why?
The origins of 'wooden dollars', a term so often used to describe pointless wrangling over internal company recharges.
Centralise or Decentralise CMS?
The 'let a thousand flowers grow' versus 'co-ordinated development' debate - a key question and driver of your ongoing costs (article from the Intranet Journal).
