Resource Planning

Allocation shares each work package's hours among the people who will do them. It passes two checks or it is wrong: every package's hours add up to its estimate in the WBS, and every person's hours add up to their capacity. If either fails, the plan is promising work that nobody has time for.

Checking the load, week by week

An allocation can give everyone exactly 30 hours and still be impossible, if 20 of someone's hours fall in one week. The load check finds this:

1. Give every work package the dates of its bar in the Gantt chart.
2. Spread each person's hours on it evenly over those working days, and put each meeting on its own day.
3. Add up each person's hours, week by week.
4. Mark every week in which anyone is over the limit. That is over-allocation.

There are three ways to remove an overload:

• Move the work within its float. A task with float can start later without delaying the project (Chapter 17). Moving it into a quieter week is resource smoothing, and the end date does not change.
• Give the work to someone else who has spare hours that week, and give that person hours back in a week when the overloaded member is free, so both still total their capacity.
• Delay the work until the person is free, even beyond its float. This is resource levelling, and when the work is on the critical path the end date moves with it.

Strictly, smoothing keeps the end date and levelling may not; in everyday use many people say "levelling" for both.

Responsibility: the RACI matrix

A responsibility assignment matrix lists the work down the side, the people across the top, and in each cell what that person's part is. The best-known form uses four letters, RACI:

• R, Responsible: does the work. A row may have several.
• A, Accountable: answerable for the work being done and done well, and the one who says it is finished. Exactly one per row, and in a student project this is the owner of Chapter 16.
• C, Consulted: asked for input before or during the work. The conversation goes both ways.
• I, Informed: told of progress or of the result. One way.

The single A is the point of the matrix. A row with two A's has nobody accountable, because each can say it was the other's; a row with none has the same problem more honestly. The A is not always the person who does most of the work, as the worked project shows.

The worked project: the resource plan

Hours, Module 1

Every figure is person-hours. The first column is the WBS number from Chapter 16, whose owners are the A's in the matrix further down.

Two rows are worth a second look. Everyone has hours on the SRS although Aditi owns it: each member wrote the requirements for the part they would build, and Aditi wrote the rest and edited the whole. And Farhan owns the API specification, because the backend must honour it, but Rohan wrote half of it, because he would test against it.

Hours, Module 2

Here too the owner is not always the main hand. Rohan is accountable for the integration tests, but Aditi and Sneha run them, in a week when he is deploying. And Rohan's two hours on the server are a practice deployment in the week of 14 September; Farhan's two are the real deployment in October, done from Rohan's notes.

The load check, and what it found

The team's first version of Module 1 put all of the plan, 1.2, in the proposal's week, because the plan goes into the proposal. The check showed the result at once: 12.7 hours for Aditi in the week of 17 August, when her share of the proposal, the whole plan and her share of the SRS all fell together.

The fix used two of the three tools. The skeleton of the WBS and the schedule needs only MU's list of deliverables, known from the first day, so Aditi drafted it in the week of 3 August, while the team was observing the canteen: smoothing, since the plan has no bar of its own and the end date did not move. The estimates need the requirements, so they stayed in the proposal's week and went to Farhan and Rohan, who would build and test what they were estimating (Chapter 13). To keep everyone at 30 hours, Aditi took over Farhan's hour at the interviews and one of Rohan's hours of observation.

After the change, week by week:

Week 7 includes the design review on Friday 11 September; the build that starts the same day is counted with Module 2. Nobody passes 10 hours in any week. The heaviest is Sneha's week of 24 August, 9.65 hours, when the end of the SRS, her part of the UML set and all six hours of wireframes fall together.

A load check shows spare time as plainly as overload. Aditi's week of 31 August holds only the stand-up. If the UML set, which is on the critical path, ran late, she is the one with time to help: Chapter 17's crashing, planned in advance.

The same check on Module 2's first version found two overloads. In the week of 14 September Farhan had 11.75 hours, and more than 10 again the week after, because the backend and the database were both his, and both are on the critical path, so nothing could wait. In the week of 5 October Rohan had nearly 15 hours: deployment, the APK and the integration tests all fell on him at once.

Deployment has four days of float, and the first idea was to use them. The check showed why that fails: four days later is the week of Rohan's load and security testing, and his overload simply moved there, to more than 14 hours in the week of 12 October. Float helps only when the week it moves work into is quiet.

So the team reassigned. Aditi and Rohan took part of the backend and the database in the weeks they were built, and Farhan took hours later, in authentication and validation, load testing and the server, where knowing the backend helps anyway. Aditi and Sneha ran the integration tests. And two of the server hours moved to the week of 14 September, for the practice deployment that Chapter 6 set as the answer to its first risk: nobody on the team had deployed Node.js on a Linux server. After the changes no week in Module 2 is over 8.25 hours, the heaviest being Farhan's week of 14 September.

Responsibility, Module 1

Every row has one A, and it is the owner Chapter 16 named. A dash means not involved.

The guide is consulted on the documents MU assesses and informed of the rest. The canteen owner is consulted wherever the system's behaviour or her canteen's facts are decided, and on the wireframes, because she and the counter staff are the ones who will use the screens during the rush. The meetings, 1.3, are left out: everyone attends them.

Equipment, software, services and money

A plan in which every cost is "nothing" is still a plan: each line says where the resource comes from and when, and the two lines that depend on other people, the lab machine and the owner's phone, have been asked for.

People outside the team

The interview dates are the ones Chapter 9 recorded, and the increment reviews are Chapter 15's. The guide's dates are the guide's to set; every other date was asked for as soon as the team knew it would need it.

Do this for your project

1. List your resources under the six kinds. For each, write where it comes from and the week it is first needed.
2. Write each person's capacity: MU's 30 hours a module, and your team's own weekly limit.
3. Share every work package's hours among people. Check both sums: each package equals its WBS estimate, and each person equals their capacity.
4. Do the load check: spread the hours over the Gantt bars, add them up by week, and mark every overload.
5. Remove each overload by moving work within its float, reassigning it, or delaying it, and check again. A move can shift an overload rather than remove it.
6. Give every skill the demonstration depends on a second person.
7. Write the RACI matrix with exactly one A in each row.
8. Book other people's time now: the guide's review dates, the client's reviews, the machine.
9. Put the resource plan in your proposal (Chapter 33), and repeat the load check whenever the schedule changes.

Mistakes that cost marks

Hours that add up but do not fit. Thirty hours each is not enough; the weeks have to fit as well.

"All" in every row. An allocation in which everybody does everything hides who is short of time and who is accountable.

One person for a critical skill. If only one member can deploy, a fever in the deployment week ends the demonstration.

Other people's time assumed. The guide's calendar and the client's lunch break are resources. Ask for them early.

Meetings left out. Fifteen minutes a week comes to between an hour and a half and two hours a module for each member, and that time has to come from somewhere.

Float used without looking. Moving a task can move an overload instead of removing it.

Quick revision

• Resources: people (hours and skills), equipment, software and services, money, other people's time, information.
• Capacity for this paper: 60 hours each, 30 per module, about 4 a week on average; agree a weekly limit as well.
• Allocation passes two checks: each package equals its estimate, and each person equals their capacity.
• Load check: spread the hours over the Gantt bars and add them by week; over-allocation is any week over the limit.
• Fixes: smoothing (within float, end date kept), reassignment, levelling (may move the end date).
• RACI: Responsible does it; Accountable, exactly one per row, answers for it; Consulted gives input; Informed is told.
• Bus factor: every critical skill should live in at least two heads.

Questions you must be able to answer

1. What does resource planning cover in a mini project? The people's hours and skills, the equipment, software and services, any money, other people's time and the information the system needs; when each is needed and who provides it; an allocation of the work that overloads nobody; and a record of who is responsible for what, usually a RACI matrix.

2. What is the difference between resource smoothing and resource levelling? Smoothing moves work only within its float, so resource peaks are reduced and the end date does not change. Levelling moves work until the resource is available, even beyond its float, so if the work is on the critical path the end date moves too.

3. What do R, A, C and I stand for, and why must each row have exactly one A? Responsible, who does the work; Accountable, who answers for it and says when it is finished; Consulted, who is asked for input; and Informed, who is told of the result. With two A's each can blame the other, and with none nobody answers for the work, so exactly one is needed.

4. The worked team's first allocation gave every member 30 hours in Module 1. What was still wrong with it? The hours were in the wrong weeks. With the whole plan placed in the proposal's week, Aditi had 12.7 hours in the week of 17 August, over the team's limit of 10. Drafting the plan's skeleton in the week of 3 August and giving the estimates to Farhan and Rohan brought her heaviest week down to 8.7 hours.

5. Why did using the deployment's float not remove Rohan's overload? Because the four days of float moved the deployment into the week of his load and security testing, where his total came to more than 14 hours instead. Float removes an overload only when the week the work moves into has room for it; otherwise the work must go to someone else.

6. What is a bus factor, and how did the worked team deal with its weakest skill? The number of people who would have to be unavailable before a piece of work stops. Nobody on the team had deployed Node.js on a Linux server, so Rohan made a practice deployment in the week of 14 September and Farhan made the real one in October from Rohan's notes, leaving two members who had done it.