Skip to content

Ability Points

It’s been bothering me lately that inappropriate resourcing seems too often to be a short path to crippling a project.

Imagine …

Let’s imagine we can do two things. The first is to quantify the amount of ability someone has at a particular job.  I don’t mean the number of days or hours they’ve been doing the job.  I mean a simple number that represents how good they are at it.  Let’s call it APAbility Points ((Because we all know people with plenty of experience but precious little ability.)).

The other is the amount of ability required to perform an instance of that job to a particular standard.  For instance, to plaster a room ten feet by sixteen feet by eight feet high to a standard acceptable to a guy who’s thinking of buying the house requires X AP.

With that in place, let’s imagine a project that needs to deliver a particular product to a particular standard (and, no doubt, within a set budget and timescale).  Further, let’s imagine that we’ve determined that to do all that requires X1 ability points of skill 1, X2 ability points of skill 2 and X3 ability points of skill 3.

In order to get the job done the way we want it, we need to acquire those AP quantities through staffing.  And this is where it all falls apart.  Traditionally, estimates for projects have revolved around how many people rather than how much ability is required to do a job.  And, as we have noted, the temptation to recruit the cheapest people you can find who look as though they might be able to do the job is overwhelming.  So the project ends up with fifteen inexperienced programmers when it really needed two senior developers, five junior developers and a couple of graduate trainees.

Of Course, It’s Not That Simple

The Staffing Profile

The staff profile outlined above provides a hint at an added complexity – the need for an appropriate mix of staff.  It may be possible to do the same work with, say, five senior developers – and the total cost may actually be lower than for either of the other two profiles given.  However, at this point there is a genuine risk that these highly valuable developers will find themselves having to perform low-level programming tasks that would be better given to the junior developers – were they available.  With a more varied mix, the juniors get valuable experience and exercise in coding solutions, while the seniors are free to apply their planet-sized brains to higher-level design and development problems.  Everyone wins.

Learning Curves and X-AP

Now consider the learning curve of the average staffer.  At first, he knows nothing, or pretty close to it.  But he quickly learns, so his AP value increases rapidly.  Eventually, however, it starts to level off (there’s probably empirical proof for this somewhere, which I’ll allow the curious among you to find for yourself), with the rate of learning reaching a much more gradual slope.  At this point, our hypothetical staffer is an Expert, with a very high AP level and a capital E.

How is this of use to us?  Simple:  any project will take time to run, and that time can be used to increase the AB of staff recruited to it.  This is already commonly practised:  the internal details of any project – the knowledge that anyone working on it needs to have in order to contribute effectively – is acquired over time, so the project-detail AP of new joiners is very low.  However, a fairly high general-project AP – i.e. an ability to learn how this, or any, project works – will reduce the time for the staffer to become effective.  We do this all the time – new joiners to projects rarely have much of a clue as to what’s going on but soon become useful team members as their project AP grows.  Similarly, a developer with a comparatively low coding AP, placed in an appropriate environment – one with some experienced senior developers around – will quickly increase his coding AP as well as his project AP.  Place this alongside the point above regarding staffing profiles and you begin to see how complex it all is.

My Point

So I’ll stop there before this turns into a Ph.D. thesis.  What I want to say is that, by staffing a project with the cheapest staff you can get away with, you’re presenting a risk that the necessary ability to do the work just won’t be there.  By keeping an eye on the need for an appropriate level of total ability, and the staffing mix that produces it, you stand a far greater chance of success.

Published inMiscellanyProject ManagementSoftware Development

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *