Time Management in a Multi-project Environment

Time and task management in a multiple concurrent project environment.

It’s a major concern that some people believe there is a perfect time management software out there that will fix all their scheduling woes. This challenge can’t be surmounted with technology alone, there are aspects of habit at play here, not to mention the inherently unpredictable nature of software development (e.g. do you know how many bugs your software will have after launch?).

The PRINCE2 manual says that a staff member can only do 3.5 days of productive work in a week (out of 5 days). Other tasks like meetings, answering the phone, attending Janice’s farewell party, and so on take up the remaining time. I have been at a company where management believed staff were capable of 4.5 days of productive work per week; this was pure fantasy, wishing something were true doesn’t make it so. Perhaps this was a misapplication of Parkinson’s Law.

In simple terms, Parkinson’s Law states that people will use up all the time they are given to undertake a task (e.g. it may take 2 hours to stack 1000 magazines, but if you give someone 4 hours to do it, they will take 4 hours). This notion is commonly misinterpreted to mean you get more out of people if you squeeze them, put them ‘under the pump’, give them impossible dead-lines to meet. Sure, this mentality may produce some short term gains, but it is also likely to result in despondency in staff and increased turn-over.

If increased productivity is desired, there are more positive ways this can be achieved (e.g. hiring a casual system administrator instead of using your programmers to do tech support work). I believe Parkinson’s Law can be a useful tool, but only for yourself - it shouldn’t be projected onto other people.



You can schedule programmer time quite nicely using Joel Spolsky’s Painless Software Schedules technique, it’s dragging them off work unexpectedly that’s the killer (see Project Schedules with Google Spreadsheets for an enhanced version of Joel’s approach). I’ve worked at a company where this was common practice (i.e. pulling programmers off work to do other work). The result was a scheduled which had unreliable delivery dates, the schedule still served its purpose as far as task tracking went though.

In an effort to alleviate this problem, I came up with a system loosely based on critical path theory which I called ‘primary/secondary programmer’. An example of how this works would be; you have two programmers on a project. One is known as the primary and has 20 hours of allocated work, the other is called the secondary, he has 10 hours of work. If 5 hours of new work pops up, it’s given to the secondary. The secondary would now be lagging 5 hours behind the primary, but he can still complete his work before the primary does. The project can’t be considered complete until the primary finishes all his work, so you would intentionally give the primary programmer more work then his comrade (e.g. a 65:35 ratio).

There is a company tackling time management with low-tech solutions quite effectively for their particular environment. One thing which they do is have a central ‘time wrangler’, if you wanted a programmer to work on something, you would have to go through the time wrangler to book him. This was done by submitting a resource request via email; just a simple work summary which looked like this:

Client name:           Blue Widgets Inc.
Job name:              Bug fix, ID: 59
Preferred person:      Michael Smith
When it will be ready: 11:00am Tues (26th July)
Due by:                5:00pm Tues (26th July)
Estimated Hours:       1-2 hrs
Priority:              normal

The time wrangler would use this information to insert a new entry into the programmer’s Microsoft Outlook calendar. When the programmer came in to work, they would see they had a few hours of bug fixing to do. Was this a perfect system? Not really, but it was much better then the ‘running around putting out fires’ approach I have seen elsewhere.

Also notice that ‘Job name’ refers to a bug ID, an issue management system is an absolute must for any software development house. The project manager needs to allocate time for bug fixes in smooth spots through-out the week and at appropriate break points (e.g. between milestones). Bugs should initially be assigned directly to the project manager, not to programmers. From there, the project manager decides priorities and re-assigns bugs or minor feature additions, these should be released to programmers in logical batches rather then just opening the flood gates.

The other impressive idea this company came up with was the creation of a position called ‘maintenance programmer’. It was this programmer’s job to undertake bug fixes and changes on old projects.

This was great news for the other programmers because it meant they could start on new projects without worrying about being dragged away at any moment to fix bugs on a project they worked on last year.

Normally, the best person to fix a bug is whoever originally coded it, but after a year, the benefit of this begins to diminish. Realistically, a maintenance programmer is going to have a hard time understanding the business rules of complex software system they weren't involved with, they are more suited to simpler website upkeep.

You will know your project schedule is working well when programmers only come ask you questions every few days, they know what they have to do next and don’t lose momentum. Another indicator will be that your project post-mortems will show very few logged issues relating to missed functionality (i.e. programmers won’t forget to code things).

Often, poor time management isn’t the result of bad scheduling, it’s usually a project management issue. The project manager is responsible for deciding priorities, not the programmers or the operational manager. This is where I have seen real trouble, when upper management assigns priority without understanding the knock on affect on other projects. I believe people worry far too much about delivery dates when they should be more concerned with time wasting resulting from sub-optimal planning practices.

Notes
Be realistic about the availability of resources. Allowance should be made for holidays and time that people will spend on non-project activities. The average working week is only 4 days after allowing for holidays, training, sickness, etc. Of those 4 days, at least another half-day will be spent on other duties, even by dedicated staff − for example, quality reviewing for other projects, line management and meetings.

- Page 181. Managing Successful Projects with PRINCE2 (3rd Ed.)

Project Schedules with Google Spreadsheets

Task tracking, estimation and distribution with Google spreadsheets.

Creating software without a project schedule is like driving a car without a seatbelt; it can be done, but that doesn’t mean it’s a good idea. Before we go any further, I should say that this article isn’t about why you should have a project schedule. If you need that kind of convincing, may I suggest a great article by Joel Spolsky called Painless Project Schedules. In fact, the style of project schedule I use is derived from his method.

What I would like to talk about is how Google spreadsheets can be a real treasure when it comes to making your project schedules. Like many tales, this one begins with a cause to be championed. Not so long ago, I worked at a company with three programmers. It was my job to make sure projects were delivered on time and to spec. Resources at this company were very tight. This meant that any time savings I could get by streamlining a process, I would go for.

In the past I had used either Microsoft Project or Microsoft Excel for scheduling. Putting my project schedules in Google spreadsheets offered a number of perks. For one, the schedule was accessible from anywhere anytime (home, office, mobile, etc). Another bonus was that multiple programmers could edit their relevant areas without any sharing issues. Also gone were concerns about backups and where on the company server the file should reside.



If you look at the structure of the project schedule I use, you may think to yourself “it’s so simplistic, surely that isn’t enough to cover a complex project?” But really, what more do you need? You write down what the task is, an estimate for how long it will take, who’s meant to be doing it, and how much of it has been done.

OK, you got me – this style of project schedule does have two major flaws. For starters, it’s hard to figure out delivery dates, another problem is that its tough carving out distinct milestone. But where this style or project schedule shines is in task management, you won’t miss things, and as the saying goes “the devil is in the detail”. It’s an excellent way for distributing tasks to team members. It also provides a very good overview of where you are at any given time within a project.

Personally, I tend to create my project schedules with only five phases (you can have more if you like). I’ve found all tasks will fit into one of these categories: wireframes/mockups, coding, project management, quality assurance, auxiliary tasks. Auxiliary tasks being the ‘catch-all’ for tasks which don’t neatly fit into any of the other categories.



I also like to create a ‘summary and charts’ page, but this is gilding the lily. I find that it's handy when my boss asks me “how is the Widgets project going?” I can answer “overall, its 92% done – we are on track”. Its also helpful knowing how many hours have been allocated to different team members. One reason I do this is because I have a bad habit of taking on too many technical tasks which really should be going to the production team (what can I say, I used to be a programmer).

Having a project schedule is great, but the unfortunate reality is that most people could care less about it. From my experience, upper management generally aren’t that interested in the detail of the schedule, but they do appreciate its existence. They will more often be interested in milestones and delivery dates.

The other hurdle is getting programmers to use the schedule. Most of the time I’ve found programmers aren’t too keen on directly participating in the maintenance of the schedule, but you must bring them into the fold. Programmers are far more interested in cutting code, which is good – it’s what they love to do and what they are there for. So how do you get your technical people involved in the project schedule? Basic people management skills really. People will be far more inclined to do something if you ask them to do it rather then order them to do it, and people are more inclined to do something if they are given some choice in the matter. To a lesser extend, that often vague concept of ‘ownership’ comes into play here.

What I often say to the programmers I am working with is something along these lines; “Tony, when you have time, can you please go into the project schedule and update your areas. Also, for the life of this project, I need you to go in at least once a week to update your areas”.



Over the years, I’ve found this approach works very well for a number of reasons; there is ‘choice’ in there; saying “when you have time” and “at least once a week” leaves some breathing room for people to manage themselves. People are always happier when they have options. The subtle wording; “your areas” connects to ownership. It means the project schedule belongs to them as well. Of course, never underestimate the power of manors - “thank you” and “please” always go a long way. There is a caveat with this approach however, it requires sincerity. People will spot it if you are saying something you don’t believe in.

Before I go, I would like to offer a few tips on how to construct your project schedule. When writing out the name of a task, be distinct, it should be some kind of action (e.g. “re-delegate domain name” is good, where as “undertake hosting tasks” is a little vague). Estimates for tasks should never be more then 16 hours (if they are, break it down into more tasks), but also avoid too many 0.25 hr blocks - that’s just going overboard. Do your best to fill in the ‘current estimates’ column, this can be used in future to highlight tasks you’ve underestimated.

Article reviewed by Sarah Hunt.