Fog Creek Software
Discussion Board




Painless Software Schdules and Varying Staff Level

We've been using an Excel-based PSS at my company and it has generally worked out great. However, we've run into a couple of gotchas I wanted to run by this group (and especially the Fog Creek folks).

To give you some backgroun, the project estimated out to around 1400 engineering hours. We convert hours to days by dividing by 7hrs/day assuming 1 hr per day will be lost to unexpected and unrelated discussion, meetings, bathroom breaks, etc. It was a bit of a fight to get mgmt to agree to the 7 hr thing but we (engineers) eventually prevailed. We have mgmt that ranges (on any given day) from highly enlightened to annoyingly in-your-face micromanaging. However, PSS has succeeded in getting mgmt less in our face because it shows percentage complete and completion dates automatically which is just awesome.

So gotcha number one is: varying staffing levels. The project began with one person, soon another was added (myself) and we very quickly got up to 3, then 4, then 3.5 people. Now we are back to 3, soon 2 (vacation for me, Seattle, you may have seen that other thread), and probably eventually 1-1.5 or whatever.  Trying to calculate how many hours left is easy, just sum the Remain column. However, try converting that to weeks and a completion date when the number of engineers is varying so much (or at all!).

I ended up adjusting the number of engineers at the moment and putting hours in the schedule to account for the time spent on the other projects they were working on. Ha ha ha. Nice try me. Has anyone else run into this and how do you deal with it?


Number two is really a warning more than anything: do not go too long without updating the schedule. Just yesterday I updated it with a collegue I am working closely with and neither of us had updated it in nearly two weeks. What a pain!

We basically had to go down the list of 130 tasks and say: Is this done? Did we work on this? And make a list of all those tasks and then say: ok 8 workdays have gone by, that's 56 hrs each.. how can we distribute these hours among these tasks...  All precision was lost for that time. We basically filled up all the tasks that had time available and evenly distributed any slip among all the tasks we touched. We knowingly did ourselves a disservice by doing this but we had no choice since we couldn't remember exactly how much time was spent on each task.

So, a word to the wise: keep your painless software schedules updated every day or two or three or they are not so painless - or valuable.

dmooney
Wednesday, November 20, 2002

Use FogBUGZ.  It's built right in :)

Michael H. Pryor
Wednesday, November 20, 2002

>>>>>>>>>>
Use FogBUGZ.  It's built right in :)
>>>>>>>>>>

FogBUGZ allows you to keep a painless software schedule, also?

William C
Wednesday, November 20, 2002

FogBUGZ has what built right in?

Using my FogBUGZ trial I setup of cases with estimates and listed them. I assigned some to one engineer and some to another. At the bottom of the page it shows me the sum of the hours estimated to complete those tasks.  Awesome! The spreadsheet I created based on the Painless Software Scheduels essay does the exact same thing perfectly well.

How is FogBUGZ helping me w/ calculating a completion date with varying staffing levels or keeping me updating the schedule every few days? Michael, I'm missing something.

dmooney
Wednesday, November 20, 2002

Dmooney - doesn't Microsoft Project do this stuff automatically?
The beauty of microsoft project is that it allows you to be as simple as you wish, if your just adding hours no problem, if you're worried about resource allocation, no problems either, plus a whole heap of other stuff, reports etc.

Alberto
Wednesday, November 20, 2002

>>>>>>>>>>
doesn't Microsoft Project do this stuff automatically?
>>>>>>>>>>

And how does this answer the question? :)

He's using Excel.  This was advice from Joel.  See his painless Software Schedule article.

I'm sure someone else has followed Joel's advice, or maybe Joel himself knows what to do in this situation.

But,
a) Microsoft Project is usually overkill
b) There's a learning curve to Microsoft Project when you've never used it before.
c)  If you've 1) never used it before ...or 2) already did the schedule in Excel and am almost done with the project ... why would you then spend hours/days converting it over to Microsoft Project just to get this one feature?

I'm baffled! :) :)

William C
Wednesday, November 20, 2002

Here is the link to Joel's article about "Painless Software Schedules" using Excel:

http://www.joelonsoftware.com/articles/fog0000000245.html

William C
Wednesday, November 20, 2002

Actually I'm wondering if the slight additional bit of complexity brought on by having a varying staff level neccesitates using Project or something like it. However, I can't stand Project. Whenever I try to do something it 'adjusts' the schedule for me in the completely wrong way. You HAVE to define dependencies for every little thing otherwise it gets confused. I could go on. Please somebody tell me how to accomodate varying staff levels w/o going the MSProject route. Joel?

dmooney
Wednesday, November 20, 2002

Tell me if I need to take another look at project but I still have a residual bad taste in my mouth from two years ago.

dmooney
Wednesday, November 20, 2002

I had the same distast for microsoft project, I've always used excel for simple project plans, but about 2 years ago I was working on a project with 4 developers and needed something more complex, also the management expected to see professional project plans, so be it. I put myself (at my own expense) on a 2 day MS project course which cost me $200 but was well worth it. I always found MS project a bit daunting, like any tool if you don't know how to use it.

Now I always use it, even for the simple stuff.

Alberto
Thursday, November 21, 2002

"Please somebody tell me how to accomodate varying staff levels w/o going the MSProject route"

  Assign tasks to people.  Figure out who your current critical path is (the guy who is "holding up" the software.)

  Concentrate on him.  If the critical path isn't 100% on your project, then you need to shift the load around.  (This is what I got from skimming the theory of constraints and applying a little common sense.)

  In other words, even if you juggle around staff, the project still isn't going to be done until the critical path is done.  So that's what you have to concentrate on.  (You can't let the others slip too much, or else somebody else is going to become the critical path.)

  This is more project management guidance than PSS guidance, I know, so here's my only PSS guidance:

- In order to predict the end date (at all), management HAS to "guarentee" resources.  That is, as long as they haven't shifted resources yet, you can semi-accurately predict the end date.  As soon as they do, they are blowing your estimates, and they need to know it.  Shifting resources on you is going to cause you overhead work to  to figure out and re-adjust the schedule - they need to know this.  (You can't just take 1,000 hours and divide by 4 programmers, then 8 hours per day.  It doesn't work that way.)

  For a DETAILED description of why it doesn't work that way, I'd recommend "The Mythical Man-Month", the longest-running book on software project management that I am aware of.  (Core thesis:  Software is like babies; a woman can have a baby in 9 months, but 9 women can't have a baby in one month ...)

  Time off and other project is predictable - you just say "i'm at 50% on project X, so I can only give 3 hours a day ..." (if you task switch, you've gotta allocate time for each task PLUS the switch ...)

  Good Luck.  My final advice is to get a project "sponsor" who can speak to upper mgt about "good engineering practices" because they probably aren't going to listen to you - you have too much to gain by lying to them.  (Sorry, that's the way people see it.)

regards,


Matt H.
Thursday, November 21, 2002

Add the hours to your total project time.

In your example you have 3.5 developers working 7 hours per day (or 35 hours per week). With a project that requires 1,400 hours of development you will be complete in 11.43 weeks (assuming everyone is working always).

Now, say that 2 of your developers will be taking a week off during the project. That means that the project is loosing 70 hours of developer time. Another of your developers has project going out and will loose a week because of it, that’s another 35 hours of developer time. You now have to adjust for 105 hours of lost time.

<Required Time> + <Lost Time> = <Total Project Time>.

1,400 + 105 = 1,505

The adjusted total would be 1,505 hours of development time, or 12.29 weeks.

I wrote a schedule package for automotive repair, and this question drove me nuts for a week. I had this complex spreadsheet so I could model the entire process and find an algorithm for it. I was kicking myself when I finally realized it came up with the same total by simply adding the total lost hours to the total required hours.

Hope this helps.

Oh, and Mat is dead on. You should always find and independent person to prove your numbers and bring them to management. While it might seem silly (and maybe insulting to not be trusted), it always works out best for everyone involved. You’ll prove your point and management will trust the numbers. And the next time, management will be more likely to trust you because you’ve been proven correct in the past.

Marc
Thursday, November 21, 2002

That's actually what I did and found to be difficult to maintain.

"I ended up adjusting the number of engineers at the moment and putting hours in the schedule to account for the time spent on the other projects they were working on. Ha ha ha. Nice try me. Has anyone else run into this and how do you deal with it?"

The problem is when somebody leaves the project, it is hard to get them to update the schedule for it anymore.

And when somebody joins the project, you have to figure out how many hours they should have put into the project so far and mark it all as elapsed.

I think Matt H's suggestion is good but will just require some more sophiticated formulas to figure out who has the most work assigned to him and calculate the end date based on that. I think Bugzilla identifies this person as "Most Doomed" but only does it by bug count rather than the sum of the estimates for those bugs.

dmooney
Thursday, November 21, 2002

*  Recent Topics

*  Fog Creek Home