Since I started in the project management software industry in the early 1980s there has always been an interest in managing skill scheduling. It’s easy to see why. When you need to build something whether it is a house, a pipeline, an aircraft, a new drug or a piece of software, you are going to require resources who have specific skills. Skill scheduling has been designed and even delivered in different project management tools for years. The idea is that instead of allocating tasks to a generic resource category which contains individuals within that category (e.g. programmer) or an individual, you would define a skill and allocate that skill to individuals and then allocate a task to the skill required to complete it.
Sounds pretty good so far and, with all the decades of time dedicated to creating great skill scheduling you’d think that we would all be using awesome skill scheduling tools, right?
Not so much.
The problem isn’t a lack of interest or a lack of smart programmers. The challenge is that skill scheduling is a highly complex problem. There are certainly tools that purport to solve the skill scheduling problem and it’s unfortunately one of those concepts that is easy to demonstrate at a superficial level. That can make it easy to sell software but skill hard to solve the problem.
Let’s first take a look at some of the difficulties involved.
Skill definition
The first of several difficulties in creating a skill-scheduling process is getting agreement on what constitutes a skill. If you work in the construction industry for example, this is already well defined. The trade organizations have already created these skill categories for you and have levels of effectiveness for what certification is required for each one. An apprentice carpenter is not a journeyman plumber, and so on.
That’s great if you’re in an industry as well defined as the construction industry but not as much if you are in another industry. In IT, for example, certifications are only relevant to a small percentage of jobs. On everything else, we are stuck saying things like “That task will take one of our more experienced programmers”. Not nearly as helpful.
But, if you’re committed to a skill-scheduling paradigm, getting agreed-upon definitions is essential.
Multiple skills
In the construction example, I just spoke of, one of the things that makes skill scheduling understandable is that an individual typically lives inside only one category but in many other industries, that isn’t necessarily the case. In IT someone might be a programmer, a database designer, a designer, a business analyst and, a documentation specialist all at the same time.
This one challenge makes skill scheduling an algorithmic nightmare. Let’s say we create a process and some analytic project management software to go with it to schedule by skill. I have a task that requires a programmer. Great. I assign a programmer who is also a business analyst. Now a task comes up for which I need a business analyst. Hmmm, I should really take the person I tried to put on that other task as a programmer and reset him or her here as a business analyst and put someone else back on the other task as a programmer. But wait, the person I’m now selecting as a programmer for that first task is also a documentation specialist and they’ll be needed on yet a third task to write documentation. Hmmm, let’s go back and start over.
This problem is compounded by the likelihood that multiple skills are often grouped into smaller numbers of people. Once someone becomes multi-functional, it is more likely that they will add more skills to their repertoire than it is for someone who has one skill to add only one more skill to their name.
Software systems that have tried to create tools to do this work use reiterative heuristics (ironic because that word is in the very name of my own firm Heuristic Management Systems) to go through the analysis over and over, trying to rework alternatives into the different assignments to get the best possible picture.
If your mind is reeling like it might looking at fractal graphics with the infinite permutations of how we get the right skills onto the right tasks, you’re not alone. It’s a complex challenge that computing horsepower alone doesn’t solve.
Double and triple counting
If I have Bob and Sally as my only two resources, it’s not complicated to figure out how much work I can get accomplished. If Bob and Sally each work an 8 hour day, then before I look at the first task to schedule I know there are 16 person-hours available to accomplish my tasks each day.
But let’s say that Bob can do programming, documentation, design and project management and Sally can do project management, programming and, quality assurance, the availability becomes more complex. If Bob and Sally each work an 8 hour day and we look at the skill capacity available before we start the first task, we have to come up with a list like this:
- Design: 8 hours
- Programming: 16 hours
- Project Management: 16 hours
- Documentation: 8 hours
- Quality Assurance: 8 hours
- Total: 56 hours per day
Now that’s nonsense of course. It’s just poor old Bob and Sally but it’s a fact that we could possible do 16 hours of programming today *or* 16 hours of project management. The difference is that if I use Bob or Sally for one of their skills, all the other skills become less available. That is a difficult concept to wrap your head around and for people trying to write a skill scheduling tool, it’s also challenging. For management, it makes it difficult to think about how much capacity you have to get work in a category done and even more difficult to think about the impact on other categories of work.
Skill Effectiveness
Years ago I was in design meetings with the publisher of a project management software system who had come up with an obvious idea. We should be able to tag each person with how effective they would be doing a particular skill. I might say that Sally is a pretty good programmer so we’ll tag her at 100% meaning that if we give Sally a 40 hour task, we have a reasonable expectation that she will be able to accomplish it in 40 hours. I might also say that Bob, being a bit newer is less effective than Sally. We’ll tag him as a programmer at 50% meaning that if we give him the same 40 hour task, we’d expect him to accomplish it in 80 hours.
Sounds awesome, yes?
No.
We couldn’t see it at the time but the human resources implications of what we’d designed were enormous. As soon as we started trying to get people to self-assess their skills, they all assessed themselves at 150%. That obviously was a problem. Then if we asked supervisors to assess their skills, the backlash once people found out that they were assessed at less than the person at the next desk was horrific. Yet managers and team leaders do this kind of assessment all the time. It’s natural to do.
We abandoned the idea and tried not to talk about it ever again.
Trying to mix tactical and strategic management
The core problem with all of these issues stems from trying to do different kinds of analysis simultaneously. When we attempt to get a handle on how much capacity we have for certain kinds of work with trying to determine which individuals should do what tomorrow, we end up in a mess.
But all of those challenges doesn’t mean that skill scheduling is a useless goal or an unattainable pipe dream. After all, managers and supervisors naturally do skill scheduling every day just by looking at a project and using common sense. So, if you are in a project situation where skill scheduling makes sense, here are a couple of things to keep in mind:
Separate tactical analysis from strategic
The first and most productive thing you can do is to separate out your strategic analysis of what capacity you have for different projects from your day-to-day management of individuals. If you give up on the idea that you’ll be able to drill down from the very top strategic view of the organization’s skills into each person’s daily assignment, you will save yourself a world of upset.
You can use skill scheduling in one top-down exercise to determine in rough terms whether you have the skills to accomplish a project and roughly whether you have enough people. Then, in a completely separate exercise, turn the individual level of scheduling over to your in-the-field supervisory people who can keep a list of skills for each person and group them or search them that way but who will use common sense to get the right people on the right tasks.
Use top-down planning at first, then shift to bottom-up planning
If you are using top down planning to get the project started, make sure at some point early after the project’s activation that you put that aside in favor of what is likely to be a much more accurate bottom-up plan that comes from the people actually expected to do the work. Your team leaders and individuals may come up with a plan that is quite different from the strategic view and it’s natural to go back and forth trying to reconcile those early in the project but at some point it is no longer effective to use your strategic plan for day-to-day management. It’s always more effective to manage people against a promise they made to you than it is to manage them against a promise you made for them.
Squint your eyes out of focus
When someone says, “We’re going to finish this project in 2 years, 3 months, 4 days and 6 hours.” I have very little confidence. Managing something like skill scheduling down to the last second is an entertaining goal but isn’t productive. Better to have a fuzzy end and have a chance of making it. Someone saying that “We’ll finish between January 15 and February 8,” is more likely to sound reasonable to me.
The desire to locate the skill scheduling Holy Grail of resource analysis may never go away and I have no doubt that there will be many tools that arrive on the market in the years to come with promises to solve all your skill scheduling woes. If skill scheduling is something that you have to wrestle with, take your time to define how you will resolve some of the challenges we’ve talked about here conceptually before you pick a tool that promises to solve it for you.
