Generally, it really worries us when our approach to solving a common problem is radically different to the majority of other solutions on the market.
But not this time, because this time all the other systems are wrong.
Every professional service company we talk to is looking for resource management, even small ones who should be able to hold the data in their head.
But, actually, what they are really looking for is a combination of functionality centred on the answer to (potentially) three questions:
- What’s my revenue forecast from pure services time, by period, for work in hand (i.e. contracted work) and how will that change given an understanding of the various jobs we may win in the near term;
- How busy are the staff, in particular when are they running out of work, what capacity do I have; and possibly
- When can Joe start on something new
You will note, the one question they are not looking to answer is
“Which task will Joe be working on in 10 weeks’ time on a Tuesday?”
Yet this is the required granularity most systems demand. Data needing entry, by name, day and project task. Now, normally, having extra data in a system would not be a problem, unless you are the person who has to enter and maintain it of course. Yet here, the problem is compounded by various uncertainties (aka data fade) the further into the future you are attempting to model.
Remember, this view is variously intended to look anything between 3 months and 12 months ahead. Even if you had the time to enter all those data points, just think of the level of uncertainty over the data you are keying in.
These uncertainties include;
- the varying quality and/or consistency of the project plans;
- a lack of knowledge centrally over who exactly will work on each task, for how long, even this week, let alone in many weeks’ time; and
- whether the work will complete on time, or be subject to funded change orders, delays due to resource supply, vacations, sickness etc.
This is the future we are talking about, full of the potential to surprise. The level of granularity is just wrong.
It takes immense effort to maintain a data set that it is likely to grow stale or simply be inaccurate around the point you complete data entry. Certainly when you need it, it is probably going to be so inaccurate, it can’t be relied upon to answer the key questions. A lot of effort to produce a bad answer is a process that will quickly fall into disuse. Our guess is that this is the reason everyone wants this functionality, because they’ve tried it already in more than one system and it didn’t work…
Is there an answer?
Well, first remember that resource management is hard, however you do it. It takes consistent maintenance to produce a result that is good enough for reporting and decision making. But if we go back to the key purpose, we can derive those answers with far fewer keystrokes if we use teams as a grouping node between work and people.
People in professional service organisations are naturally in teams, sometimes grouped by job role, sometimes just for management convenience sake. If they form part of a large resource pool, they are often just grouped into project teams. Sometimes people split their time across more than one team, sometimes a specialist may be in a team of one. Either way, look at your organisation and you will see a team dimension.
Allocating work to teams takes far less time than allocating it to individuals. It’s softer and more malleable so the impact of demand-side changes are simpler to maintain. This means allocations are more likely to be updated and so the resource profile will be closer to right.
But the key difference in team-based allocations to either projects or tasks is the resource balance view that allows (at an organisation level) reporting of over and under capacity quickly and easily, a view that is suitable for a small organisation up to one with many 100s of staff.
How do I allocate teams?
Well, the crudest and simplest way is just to allocate the project to a standing team. Let’s say you have a Development team of Y people. The demand from the project is expressed as the sum over the task estimates, plotted per week. When you say, the dev team will do that work, you supply the project with that resource pool in general and the team resource balance (over/under utilised per week) is plotted.
Let’s say, each week they have X hours availability (obviously less vacation etc) and the project plans (they can cover more than one project) will show how long/short they are of resource per week. This very simple high-level mapping will answer question 1 and 2 and so deliver a really useful view for almost no work.
But, what if I want more detail? What if I want the system to answer question 3 as well…
In that case you need to build project teams. These are people (or percentages of people per week) grouped together and allocated at the task level of a project. The demand vs supply (long/short per week view) is plotted based on the resource profile of the tasks vs the resource profile of the team covering that activity. Then you can look at Joe and see what percentage allocation he has against all the project teams he is part of and that will tell you when he is available and by how much. All without caring what he is actually doing.
Project plans are built by drawing down from order-level resource profiles and team plans are built to supply project plans. However, the department (standing team) view is still needed. In this model, project teams can be plotted in a standing team window and quotes applied to perform what-if analyses on when, in general, work can start.
And that’s the way to make resource management a consistent and valuable reality without spending your entire life editing data.
About the Author: Harmony Business Systems Ltd (HBS) is the company behind HarmonyPSA, the most complete cloud PSA software on the market. Developed with functionality to cater for even the most complex needs of MSPs, VARs, ISVs and Professional Services organisations, HarmonyPSA truly is the next generation of PSA systems. Follow HarmonyPSA on Twitter, LinkedIn or Website