Ideas in Wiring

Personal or Project Scheduling

I spent 8 years somehow managing software projects and it took years to discover a few secrets that made life easier. When it comes down to it, the job of a project manager is:

• Insure that the (task/product/thing) is delivered on time with the proper level of features and quality
  
• Insure that there is appropriate and correct communication between the team and others

That's it. The rest is just details. My best advice for a project manager is...

Do as little work as possible to accomplish those goals

After all, no one ships a project plan or a schedule. If the product ships correctly, you've accomplished your goal. Never get carried away with your own importance.

Some projects actually run themselves. You can do zero work and the project will meet the goals. But, there are cases when you need to do more than nothing.

1. You have inexperienced or new employees on your team
   
2. Your product depends on other products/components in development
   
3. Your schedule is dictated by other products (i.e. something else is shipping at the same time and they won't wait for you)
   
4. Other products depend upon your product and so a slip in your project will slip them also
   
5. You have remote developers
   
6. Features get inserted into your schedule midstream
   
7. Each time your team crosses a size threshold (10, 50, and 100 developers) you need to change the way your team operates.
   
8. The release date of your project has a large monetary affect
   
9. Your developers are working on multiple projects at once
   
10. Your product must be high quality (high expectations, life critical, is infrastructure other people depend on, etc..)

Many projects have these risk factors. So, you think "I need a tool to help me do this". You look up "Project Management Software" in Google and you get.... Microsoft Project. Let's talk a little about tools for second.

Project management tools are never the magic bullet they are advertised to be. They won't pull in a late project. They don't give you "the answer". They lie to you. They only work in conjunction with your brain.

They will, however, help you make sense of chaos and they will give you something to blame if you screw up. But I think the first is the only one that is valid.

So, what is the role of your brain here?

Rule #1 - Never trust a precise date.

If someone tells me a product will ship "March 25, 2004". I call BS immediately. No one can pinpoint a ship date down to the day unless that day happens to be tomorrow, and then I'm still suspicious. If you said "March", "First Quarter", or "Sometime in 2004" you would not only be more accurate but you also tell me something important: your level of certainty in the date and that tells me a lot.

So, the number one reason I dislike MS Project is that it only gives you dates with daily (or hourly) precision. It won't tell you "sometime in March" and thus it is lying to you. It's the lie of omission. The lie that makes you overconfident. I'd much prefer MS Project to tell me "I have no idea when your project will ship". That's really good information because it forces you to use your brain and go find out.

Rule #2 - Greater detail does not give you greater accuracy.

I learned this one the hard way. The schedules I created (in MS Project) for the first two years of my career constantly slipped. I went to training classes looking for the answer. I used to think they were off because I wasn't including enough details. After all, the schedule kept slipping because new tasks kept getting inserted. If I got more detailed, I'd know all of the tasks and my schedules would be more accurate. This happens to be 100% wrong because, at least with software development, you can never know ALL of the tasks. The best you can do is sketch it out and fill in the details later.

Instead, use the law of large numbers to help your accuracy. (The more things you aggregate, the greater your accuracy). I have no idea how long it will take to fix a particular bug. Could be a day, could be a week. However, you may learn from the past patterns of the team that each developer can fix, on average 2 bugs per day. So, if you have 60 bugs and 3 developers, it will probably take 10 work days to fix all of the remaining bugs. You are making an estimate but it will, in my experience, be very accurate. It also saves 60 entries in your project management software.

Rule #3 - Know the difference between unknown duration of known work and unknown work

Most software development projects are late because there's more work to actually be done or more stumbling blocks than you realize at the start. It's not that a particular task took longer to complete than you thought. It's because there was a bunch of other tasks that you never thought of or came up in the middle.

How do you deal with this? First, never make a schedule until you have scoped the work. This is not just because you need something to write down. Scoping the work forces the people involved to actually start figuring out what they need to make and that will force them to figure out how they are going to get it done. Now you have the "known work". I can't overstate how important this is. Upfront work now saves rework or mistakes or schedule slips later. I've seen it and I believe it. You can't have an accurate schedule before you know what you are doing.

The second piece of advice is the rule of 50%. It's my rule and it's based purely on experience. It may vary between projects, styles or whatever but I've found that even for a well specified project, there's about 50% more tasks there than you think there really are. This is the "unknown work". If I hear that there are 20 days worth of known work left, I can bet that they will be done in 30 days (20 days + 50% of 20 days = 30). If there are 6 months of known work left, they will ship in 9 months. And this isn't just a fudge factor. When doing scheduling, I count down the amount of work left, add 50% to it and that becomes my best guess at a ship date. In the past 4 projects, that date has been the closest thing to right. Since it's a percentage rather than an absolute, it stays accurate even as the amount of work decreases (and unfortunately MS Project can't seem to deal with that)

Rule #4 - No news is rarely good news

You can't adjust to problems unless you know about them. Engineers rarely volunteer that there are problems. They are problem solvers and so they try and fix the problem themselves. If you don't ask, they won't tell. Ask.

Rule #5 - Nothing is ever 90% (“almost”) done

This rule comes from a senior manager at NI. Progammers love to tell you that they are "almost" done. Internally translate that to "I'm almost feature complete.. That whole bug fixing, testing, integration thing doesn't count toward done.". So that means at best they are 50% done.

Making an Accurate Software Schedule

I didn't answer how to make a schedule because once you follow these rules, you're pretty much home. Use whatever you want. I use Excel. SW projects are not usually dependency driven. There is a list of tasks, you estimate a particular amount of time for each task, add in the conversion factor for meetings and other overhead (i.e. usually double the task estimate), account for unknown work (the rule of 50%), add it all up and you get a general target date. Don't tell anyone that date because it is wrong (see Rule #1). Give them the date +/- a quarter and you're probably being accurate. Update the task list weekly. Now focus on the harder things :-)

posted by Joel @ 8:18 PM