Monday, August 27, 2007

Don't get the staff you deserve, get the staff you need

I am working on a resourcing plan for my branch. The move from legacy mainframe applications to SOA requires new skills and specializations, but we need to maintain some fairly rare legacy skills as well. Here I explore a couple of rational models and tear them down again in order to justify my own approach which I plan to provide in a later posting.

If you are managing a group responsible for software development there are a number of options to accessing personnel to get your software developed. These include:
  • Permanent Employment (A salaried employee with can be Full-time and Part-time)
  • Term Appointment (Contract to the organisation for a fixed term)
  • Personnel Contract (Usually contracted through an agent rather than directly to the organisation)
  • Service Level Contract (This is for a particular service such as "keep the database server running within service levels" rather than a chunk of work)
  • Work Contract (Contract to deliver a piece of work. This contract might be on a 'fixed price' or 'time and materials' basis)
  • Product Purchase (A vendor produces a product, often to specification which is then purchased)
This list is ordered from most tightly bound to the least tightly bound to the organisation. The expectation is that the salaried employee will stay for a number of years, stay after the current project is complete and usually paid for by recurrent funds. A contractor on the other hand is not tightly bond to the organisation. The contractor is expected to be employed for the length of the project and funded capital allocations.

Of course these are expectations. In practice we may have employees who leave after a few weeks and we may have contractors who are essential to the organisation and we keep extending as new projects become available. What is important is that we have the roles in our organisation that will allow it to continue for the long term but we also have sufficient staff to get our current projects done.

How do we decide which are the permanent roles, tightly bound to the organisation and which are the contract roles?

First I will look at some rational ways of doing human resource planning. Imagine we are able to predict our resources requirements for, say the next 10 years. That is stretching the imagination a long way but let us do it for the sake of argument. We would come up with a nice chart with peaks and troughs in our demand for people. There are a number of models we could use for our human resources:
  • Staff to meet peak demand. This is more a model for a call centre than a software development shop.
  • Use permanent staff to meet the trough of demand (ie steady-state demand) and contractors to meet the peaks.
  • Minimize the cost of staffing based on the human resource demand (see footnote).

To minimize the cost of staff we must assume contractors cost more than permanent employees. The contractor should have compensation for not having the benefits of permanent employment. To minimize the cost we must fund a permanent staff level somewhere above the demand trough level. The implication is that it is economical to pay permanent staff to be idle in times of low demand rather than pay a premium to bring in a contractor in more busy times.

This is of course, never the way it works in practice. We can't predict our IT projects very far into the future. The concept of an idle IT professional is foreign to me. There is always maintenance work to do, more enterprise documentation or more skill development to be done. We do not count human resources as simple numbers. There are skills and specialties we need. The costs of our staff and contractors are not uniform and the formula for getting value for what you pay for can be very muddied when you are talking about people and what they can deliver to the organisation.

The big killer for getting in the way of a rational approach is that I have very little discretion over the number of my staff anyway. Governments and many large organisations have fixed FTE limits. Especially for Government it tends to a be vote-winner to promise reduction in the number of public servants and the folks sitting in the back office, like IT staff, not delivering anything directly to the public are often on the agenda for cuts and freezes. The outcome is that we may end up with less staff and more contractors than is rationally based on models like the ones above.

I have to ensure that I have the right permanent roles moving forward. By 'roles' I mean positions. Max Weber has the dubious distinction of inventing the bureaucracy where every person is employed to fill a position. The position has certain duties and requirements. It is these duties and requirements that we described in position document and we try to fit people into these roles. As much as I would just like to get a bunch of talented people together in the expectation they could come up with something wonderful, each position has to be described in detail so that we have all bases covered and this is what has to drive my planning.

Footnote:
I did maths a long time ago but occasionally I like using the formula editor. The total cost of staff for a period of time T is

We minimise TotalCost with respect to the permanent staff level P.

No comments: