A Scheduling Technique for Small Software Projects and Teams

With all of the scheduling programs on the market today one might wonder why software project deadlines are still missed and over budget. These programs look at the tasks and schedule employees accordingly. What these programs don’t take into account is the human factor: software professionals need food, drink and rest, and don’t always operate according to plan. The irony is that a scheduling program developed by software professionals may not completely meet the needs of software professionals teamed to complete a programming project.

This article introduces tips and techniques for creating and maintaining a more accurate and easy-to-use schedule, in the context of small software teams.

The systems and practices you are about to see occurred at a real company. The names have been changed to protect, well, everyone but me.

The scenario

Your company has been contracted to develop a real-time process control system with a combination of software and hardware deliverables and a pre-determined schedule with a completion date fixed by contract.

These contracts are bid by marketing and sales with assistance from project managers, using minimal input from people who will do the actual work. The bids contain salary and overhead for X software bodies of differing levels. These are ‘virtual’ bodies; in most cases actual personnel aren’t assigned to the project until after contract award and notice to proceed. Too often a large number of the bodies belong to people who are coming free from a prior job, rather than people whose skill sets match the job’s requirements.

The project team consists of a project manager (who is responsible for more than one project); a system engineer responsible for the day-to-day running of the project, primarily on the hardware side; one or more hardware specialists who report to the system engineer; a lead analyst responsible for the software side of the project, who reports to the project manager but coordinates through the system engineer; and one or more software specialists who report to the lead analyst.

The problem

The system engineer is given the task of scheduling the project, usually before all of the other individuals have been assigned to the project. The result of this work is a detailed critical path chart, with finish-to-start dependencies neatly laid out in detail: purchase hardware items A and B; receive hardware items A and B; assemble hardware items A and B; test assembly; etc. Buried somewhere in the midst of all of this hardware mumbo jumbo is one item – Software – which starts with the project’s notice to proceed and ends at the factory acceptance test.

The system engineer, who is usually a hardware person, concerns himself very little with the software end of things. He’s been given the project’s start and end dates, and hardware to deal with, and, well, the rest is SMOP – a Simple Matter of Programming – and left up to the software team.

The software team is faced with producing the software, in a finite period of time, with a fixed set of requirements, without knowing the true scope of the software development effort. Nothing the team says or does will change management’s attitude toward the deadlines imposed by the project schedule, especially because it is common for the contracts for projects of this type to include provisions for liquidated damages.

Liquidated damages – two words guaranteed to keep a C-level executive up at night. Liquidated damages are monetary penalties imposed on the contractor for missed deadlines. Keep in mind that these types of projects are often all-or-nothing affairs. Partial solutions that do not fulfill the entire specification just aren’t good enough. A control system for a water treatment plant that does not implement the dual-media-filter backwash process is not going to be of any use.

The solution is for someone on your team, who best knows the strengths and weakness and dependencies of your team, to take control of the software schedule. Ideally, the lead analyst should be the one to do this; however, any of the more experienced analysts can do the job as long as the support is there.

The road to schedule happiness

The first step on the road to schedule nirvana is to get a grasp of what needs to be done. I recommend developing a short description of each task to be performed (which may map to a program or programs to be written or modified on the coarse-grained end of the detail spectrum, to more specific functionality on the fine-grained end). Record pertinent information about the task, including the task name, a short description of the task, references to the purchase specification (the customer’s document) and the system functional specification or high-level design document (your response to the purchase spec), any items or other tasks the task depends on, and an estimated time to perform the task. (See the ‘Time estimates’ and ‘High vs. low tech’ boxes.) There should also be a space for the person assigned to the task, a starting date and a completion date.

Your first pass at filling in this data is just that – a first pass. You may not be able to fill in the details of all tasks right away; create a placeholder for it, and fill in the details when you know them. (You most likely will add tasks during the course of the project, as those inevitable gotchas spring up.) Where appropriate, scribble in the name or names of the people on the team who have to do the task (because of their familiarity with the existing code, or areas of expertise, for example) or who are able do the task (based on what you already know about the rest of the project team members).

I usually defined these tasks at a fairly high level of abstraction. Typically, a task for a multitasking process control system correlated to a task running in that system. In some cases a task was broken down further; the need to integrate a new piece of process I/O gear might have been broken into a communications section, an input section (for analog and discrete inputs, pulse accumulators, etc.), and an output section (for analog and discrete outputs).

At this point you should be ready to discuss your results with the rest of the project team. You should encourage them to inspect your results, and comment on them. What you want is to receive feedback on your time estimates from the people who are going to be doing the work. You also will learn of additional tasks; you may also find out that two or more tasks can be better stated as one.

Dependencies vs. resource allocation

Scheduling packages allow tasks to be allocated to resources (people), and they allow dependencies between tasks to be defined. A task dependency simply states that one task needs to be completed before another can be started. If tasks are entered into the scheduling software without resource allocation or explicit dependencies, you wind up with a schedule that looks like this: All tasks start at the same time; this is not very useful. By adding resource definitions to the tasks, the scheduler can spread the tasks out in time. This shows what this might look like: This figure looks an awful lot like Figure 2, but is even less readable. It is not immediately obvious which tasks are in whose timeline. I like to use explicit dependencies on tasks assigned to a person. My experience is that it is easier to use the scheduler this way than assigning resources and letting the scheduler make its own decisions about which tasks should be done first. Plus, there are always real dependencies between tasks, both within the timeline of a single person and between the timelines of different persons. Sticking with one method of defining the ‘end-to-start’ relationships between tasks simplifies my job, by eliminating the modification of the additional resource data within the scheduler.

The schedule

Now that you have a grasp on the ‘what’, it is time to worry about the ‘how long’. For this you need a software package that creates schedules, such as Microsoft Project or Primavera. These typically create a schedule with a calendar along the top, tasks down the left hand side, and which shows when a task is to be performed by printing a bar to the right of the task aligned with the actual dates across the top. The package you choose should allow you to enter dependencies, milestones, etc. and should also calculate slack time and critical paths.

Most scheduling packages are highly configurable, so this is where you should start. I recommend the following initial assumptions:

• Configure the package to plot tasks on a daily basis,
• Configure the package to reflect all of the standard holidays your company schedules, and
• Configure the package to not count (or plot) weekends and holidays when scheduling.

If you follow the first suggestion you will wind up with a much larger chart, but it will contain more detail; you will be thankful for that detail later. The last two items are very important for a very simple reason: there is nothing that will deflate morale quicker than to see that work has been scheduled for every weekend and every holiday, even if the package automatically adds days to a task which spans weekends and holidays. I believe the chart in Figure 1b is much more desirable than the chart in Figure 1a, because there is a more visible one-to-one relationship between your time estimates (in days) and the number of days shown on the chart. If your package does not allow you to filter out weekends and holidays, then you should go out of your way to show your fellow team members that the duration of the task is based on a five-day work-week.

Figure 1

Creating the first pass of the schedule requires time and patience. The first step is to take all of the task assignments and sort them by the people who are able to perform the tasks. If a task can be accomplished by more than one team member, take a guess and assign it to one member. (The guess can be based on who you think is best for the job; or, if team members are equally talented, whom you think is the more lightly loaded.)

The next step is to sort each team member’s initial assignments by priority and by any dependencies. Once you have performed this initial sort it is time to plug all of the data into the scheduler.

If your previous schedules have been like the ones I have received from ‘on high’, the tasks all are entered into the package, without regard to any previously known dependencies, or the person or persons who are going to do the work. This results in a schedule that is very difficult to follow, requiring the use of mental calisthenics to follow a dependency path from start to finish as you bounce up and down the chart. Look at the sample schedule in Figure 2, and imagine what it would take to follow if there were 100 tasks scheduled over 12 months or more.

Figure 2

I believe in creating a schedule that can be followed by mere mortals, so I base my chart on people. Although this is a more difficult way to use these types of scheduling programs, the results are worth the effort.

Start with the assignments for one team member only. Enter this team member’s assignments into the scheduler, in an order that makes sense. Make each task’s start date dependent on the prior task’s end date, as well as any other dependencies you have noted. (See the ‘Dependencies vs. resource allocation’ box.) If a task has a hard start date (which might be caused by the known arrival date of a prerequisite for the task) or a hard end date, enter these dates into the scheduler, too. Repeat this task for each team member’s assignments. What you want to end up with is an initial schedule that looks like the one in Figure 3.

Figure 3

The format of the schedule in Figure 3, which is people-based, is much easier to follow than the one in Figure 2 (which contains the same data). It is also easier to detect an imbalance between the loadings of each of the team members, places where dependencies between team members cause slack time in one member’s schedule, and where the critical path lies.

The last step (and perhaps the most lengthy) is to minimize the slack time in each team member’s schedule, and to attempt to equalize the end date of each member’s schedule, by switching tasks between members (where possible) and rearranging the order of arbitrarily ordered tasks. (Don’t kill yourself trying to get all of the slack time out of your schedule; a little slack time scattered throughout each team member’s schedule can help absorb some of the inevitable delays.) For the simple example in Figure 3, if Task 4 can be performed by either of the team members (and assuming there are no dependencies which would prevent the reassignment), it can be reassigned to the first team member to achieve the schedule shown in Figure 4. The result is a schedule that beats the completion milestone.

Figure 4

Now that you have fiddled, tweaked, moved, rearranged, reordered and otherwise completely redone your schedule multiple times, and have finally come up with a schedule that optimizes your resources, what do you do with it? If you are one of the fortunate few, your schedule has ample slack time in it, there are no missed milestones, and most – or all – of the critical path is assigned to your most productive team member, then – get to work! However, if you are like the rest of us, your carefully crafted schedule shows what you expected all along: there just aren’t enough days in the week to get your project done on time.

This is the point where doing all of this upfront work really pays off. You could have taken your task sheets, added up all of the time estimates, divided the sum by the number of people allocated to the team, and come to a similar conclusion without having expended nearly the same amount of effort. But your carefully crafted schedule is more apt to convince a manager that one of three things needs to be done: the completion date must be pushed out, features need to be cut from the specification, or you need one or more additional people. (A rational manager might ask you if you have cut out all of the fat from the schedule before recognizing the obvious; an irrational manager will just tell you to shorten the schedule, dammit, and don’t bother me with your problems.)

On projects such as these, the completion date and specifications are contractual, and not likely to be open to discussion (remember – liquidated damages). So you are most likely going to be faced with adding one or more team members. Unfortunately, what will probably happen is that your manager will tell you to rework the schedule assuming that there are X additional players to be named later. Once again you will be faced with the problem of assigning tasks to unknown individuals, and reworking the schedule to meet the projects requirements.

Plan the dive, and dive the plan?

SCUBA divers are taught to plan a dive carefully before getting into the water, and then to ‘dive the plan’ and not to change the characteristics (maximum depth and time underwater) of the dive while in the water (with the exception of an emergency, of course). Well, the same can be said of your schedule. You have put a lot of time and effort into your schedule; the project team members should be required to stick to it, right? Penalties for missing a deadline should be stiff, tasks should never be performed out of order, heads will roll if major changes are necessary – you get the point.

What a bunch of hooey. In order for your schedule to be effective over time, it has to be flexible. This is simple reality – no project ever goes completely according to plan. Your schedule has to be a work-in-progress at all times.

A scheduler’s work is never done

The easiest way to get the maximum results from your schedule is to follow these guidelines:

Print out your schedule using the finest grain you can handle. (I like a printed schedule that goes right down to days.) If your scheduling package doesn’t do it, print the name of each team member next to the line of tasks to which he or she is assigned.

Hang a copy of your completed schedule in a place that is easily accessible to the project team. (See the ‘Schedule Location’ box.) Try to display the schedule on one plane, without having to resort to multiple levels. Show your team the relationship between the tasks on the schedule and the tasks definitions. Encourage them to do the following: record the actual start and end dates of a task; mark the actual start and end dates of a task on the schedule; and record any problems they had.

Update the schedule once a month. Start by interviewing all of the project team members and asking them how their current task is going. Ask them how far they have progressed, and how much longer they think it will take to finish. You should also inquire about any other tasks on which they have worked since the previous month’s update. Make it clear that you are not asking these questions to nail them on missed deadlines, but rather to make it easier for you to better estimate the rest of the job.

Insofar as the schedule is concerned, you have two goals to accomplish: 1) update the schedule so that it realistically reflects the activities of the team members over the past month; and 2) modify the schedule as necessary for future work. The first step is important because it accurately records the past. This is why you want the team members to mark down real start and end dates for tasks.

The second step is even more important, because it is here that you use the historical data to better predict the future. (If this seems dangerously close to collecting metrics, all the better. I won’t presume to call any of this data a metric because the process is too subjective.) The goal is to continuously narrow the ‘cone of uncertainty’. [ McConnell97 ]

Use the results of your discussions with team members to estimate the completion of their current tasks. For example, if they say they are 50% done, and they have spent nine days on the task already, then adjust the schedule for the item to read 18 days (regardless of what it started out to be). You may need to adjust this up or down, depending on whether the team member is a strong starter or a strong finisher; use what you have learned of each team member from all of the prior schedules.

You may find that the schedule undergoes drastic changes during some or all of your updates. You may find that a team member is not suited for certain work you have assigned to him or her, requiring a complete shuffling of tasks for the rest of the project.

A schedule update is also the time to add tasks associated with those ‘gotchas’ I talked about earlier.

Another very good reason to update the schedule every month to accurately reflect past work is that it hides the evidence of missed schedules. This in turn makes it more likely that each team member will annotate the schedule accurately, which will make it a better forecasting tool. I advocate burning, shredding or, at the very least, hiding all previous schedules; you really don’t want indicators of past performance lying around. It is also a good idea to keep any type of relative performance data out of the hands of management. If you are perceived as a performance information pipeline to management, the other team members may stop cooperating with your efforts. After all, when updating the schedule it is more important to know a person’s total performance on a similar task than whether the person finished the job early or late.

What about Agile? Isn’t this just big <something> up front?

What about it? I have heard great things about agile methodologies – Scrum, XP, and the like – and if I ever get to work on an agile project I’ll let you know how it worked out. Agile methodologies seem to be short-term oriented – two to four week intervals of planning and execution. I can see how this works for internal development projects, or projects where partial, functional solutions are possible and even desirable. I have never been able to figure out how you would know if your resources are allocated correctly for a long term project if you don’t take time to plan for the long term. (I am willing to be corrected on this.)

Although I haven’t used it this way, these techniques could be adapted to a quasi-agile form. The schedule you create could be broken up into the agile increments in use by your team. In this case there would be a project milestone at the end of each interval, and the tasks assigned to team members would need to fit not only into the overall, long-term schedule, but each of the intervals as well.

Costs versus benefits

It took me about one full week to create an initial schedule for four or five team members and approximately 100 tasks. I spent one full day a month updating the schedule. I set aside the last work day of the month for this purpose. By keeping to a schedule for updating the schedule I was sure to get the updates done, and the other team members got used to thinking about the questions I would inevitably ask them.

I developed and refined this technique over the course of two projects, a nuclear power plant security system and a retrofit of a waste water treatment plant process control system. The security system project lasted twelve months and was staffed by four programmer/ analysts, including myself. The waste water treatment plant control system project lasted fourteen months and was staffed by four to six programmer/analysts at any given time. Both of these projects were completed and successfully passed their factory acceptance tests on time, a rare occurrence for those types of systems at that company.

I was not the lead analyst on either job, but I had the support of the lead analyst and project manager in both cases. The second project was one third of the way into its overall schedule when I joined the team. After I was given my assignments, I sat down to schedule them out using the techniques developed on the first project. The lead analyst asked what I was doing, and when I told him I was scheduling my own work he directed me to schedule everyone else on the team, too. We discovered there was no way to meet the schedule given the currently allocated resources, and were able to add a person early enough to finish on time.

There were some other benefits to this approach. Team members from the project supported the scheduling process, since they had a say in the time estimates used. We had a small level of process feedback, since I was able to use historical data to better estimate work yet to be done. And, best of all, we were able to complete both jobs with less overtime overall than other projects of their type.

Acknowledgements

My thanks to Nicole Wascoe Bauman for her input on the article, and to Don Perkins for supporting my efforts on these projects.

References

[McConnell97] Software Project Survival Guide , Steve McConnell