« Introduction to Project Management Processes - Benefits Management
What Is Project Management - Characteristics of a Project »

Time Management in a Multi-Project Environment

May 18, 2009 | Author: PM Hut | Filed under: Time Management

Time Management in a Multi-Project Environment
By Louis Marshall

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 develop (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. 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).

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.

Another idea is the creation of a position called ‘maintenance programmer’. It’s this programmer’s job to undertake bug fixes and changes on old projects.

This is 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.

Louis Marshall, Project Manager - My tech blog: pm4web.blogspot.com

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Monday, May 18th, 2009 and is filed under Time Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Your primary/secondary programmer approach makes sense and one that should be adopted more widely. It is very disruptive to have software development tasks interrupted. Developers often have to switch IDE, archive and restore code on top of taking the time to study the code they will be working on. The secondary programmer is also an ideal peer-reviewer.

I have known developers who want to do nothing but maintenance which is great for the rest of the team, who can stay motivated as they are working on new functionality. This is also a win for users as the maintenance programmer usually has better availability than the original programmer.

One really mature software company I worked for managed to delegate maintenance coding to the support organisation that had a highly trained set of individuals who rotated through development to learn and build trust with the development team. This model allowed them to write emergency fixes, workarounds and the official patch.

Pradeep Bhanot wrote on May 19, 2009 - 12:01 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories