Some time ago I wrote a blog post on how to do resource planning when you’re dealing with multiple small projects. It seems to be a tough problem, as I noticed many people are struggling with it.
To cope with such a situation, some experts will tell you that you should try and prevent working on multiple projects. Unfortunately, for people working on small projects, such advice is both true and useless at the same time, as many of us are not in a position to tell customer A that he should stop bothering you until you’ve finished the work for customer B. Optimizing just one customer’s happiness will get you out of business in no-time!
The solution is to make all customers just a little bit happier.
The only way to deal with this multi-tasking problem is to applying rigorous discipline to your weekly schedule. You must make it clear (to yourself and to your customers) how much time you can make available for which projects. Not doing so results in overcommitment to one (spoiled) customer, while the other customers suffer from neglect.
Here I give you an example, showing you how to handle scheduling with multiple customers. It might be a bit extreme, but it reflects the most common situations I have encountered in our own organization:
<ExtremeExample>
Suppose you are working on some big project (A) that requires as much attention as you can afford. How much time do you think you will have available in a period of four weeks? 160 hours? 120 hours? 100 hours? What will you say when the ScrumMaster asks you how much work you can do in the next sprint? If you do not carefully schedule all your other responsibilities, you could think that you have 160 hours available in four weeks.
Figure 1: four full weeks allocated to one big project
However, you might recently have worked on another big project (B). If you’re a bit like me, the product you delivered will still have a (small) number of bugs, flaws and other problems that need to be resolved right after the first release. In our organization we call this the “aftercare” phase, which is like a warranty on our products. The customer is entitled to have all problems fixed that are discovered within a few weeks after a product’s first release. You have to reserve some time in your schedule to take care of the aftercare phase.
Figure 2: warranty period for B takes some hours away from A
You may also have contributed to some older projects. It is said that good products require more maintenance, because users often request more improvements in products that they really like. Those earlier customers, the ones you helped by giving them some really stunning products, will keep asking you to add and change features. Provided these customers have some sort of maintenance contract, the time required for maintenance has to be schedule separately. In our organization we call these days “issue days”.
Figure 3: maintenance work takes some more hours away
If you’re lucky (given the current financial crisis) you will have customers asking you to do some new work that doesn’t fit into regular maintenance work. Of course, you already know you should try and do only one project at a time. So you tell those customers to wait until project A is finished. However, if the amount of work is small, your customer will find it very hard to swallow that he has to wait another three months for project A to finish. “It’s only 3 days of work! Why do I have to wait for 3 months? Surely you can squeeze this in between?” That’s why we decided to introduce “RfC weeks”, where an RfC stands for a Request for Change. It is one week per month reserved for relatively small jobs on existing products, whatever work that turns out to be. (And if no small jobs turn up, we just continue working on project A.)
Figure 4: one week reserved for tiny projects
Is that everything that you need to think of? Hell, no! What about your own personal development? When will you have time to experiment with new technologies? When will you have time to read a book, or the complete archive of your favorite blog (NOOP.NL)? If your organization is serious about your personal development, you will be allowed some time to read, experiment, and learn. In our organization we call these our “academy days”, and they need to be scheduled separately.
Figure 5: one day of personal development per month
That was all, right? Well, maybe. Maybe not. It depends on any other responsibilities still left unattended. Are you required to coach some junior software developers? Are you expected to attend several meetings per week? Are you involved in job interviews, or fixed price estimations? Do you do consultancy work for new customers? Do you prepare technical architectures for new projects? You will have to account for those activities as well.
Figure 6: various activities of one hour per day on average
As you can see in the last picture, the actual time you have available to work on project A has shrunk to almost one third of the month. Sure, your own situation may not be as extreme as in this example, and the exact numbers of hours will vary per person, but I would advise you to do the sums yourself. And don’t do this scheduling in your head! At the start of the month, when you plan your work for project A, you have to know how much time you have available. If you’re only doing a quick mental assessment of your responsibilities, you will always end up overpromising what you can do for project A.
</ExtremeExample>
(If you’re lucky, and your organization understands the importance of resource scheduling, you will have a resource manager or project manager doing all this work for you. Still, you might want to check if she has thought of everything. In dynamic organizations (like mine), where hundreds of customers and projects are battling over the availability of human resources, keeping track of people’s multiple responsibilities can be very hard. But if you apply some discipline to your schedule, you should be able to handle the most common resource allocation problems.)
Balancing work for multiple customers is a tough problem. You will have optimal results by optimizing resource allocation in such a way that all customers are just a little bit happy. And it is true that you should minimize the amount of task-switching between projects. If you can consolidate all maintenance work in one week per month, instead of one day per week, then do it! Likewise, aftercare in 2,5 days of 8 hours would be much better than 10 days of 2 hours. I’m sure you get the picture.
But whatever you do, it doesn’t change the amount of time that remains for customer A, which could be a lot less than you thought. It’s best the customer knows that before you start, don’t you think?
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
How to Do Many Projects (Part 3): Maintenance
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)
