Max's Thoughts on the Issue
Dear Anand:
You pose an interesting question. For all the "theory" and tools and techniques that we like to discuss in project management, when it comes down to it, "real" projects turn out to be quite different!
The short answer to your question is that there are so many variables involved that there is no simple calculation. However, if you are able to make sufficient assumptions, then you should be able to come up with some sort of rule-of-thumb that reflects your particular environment. I'll try and answer your question from "first principles" - but to do so, I'll have to make a lot of those assumptions. However, I have also consulted some of my friends who have provided more experienced input than I can that I'll share with you in a moment.
I'll first paraphrase your question as follows: "What should be the proper length of a practical schedule for a software development project of 100 man-days of effort?" That's about 1000 person-hours including unpaid overtime, or about $100,000 gross. That's not a large project but a nice one for a lot of people.
The first point to note is that any statement of effort before a project starts is an estimate and we can never be sure of the accuracy and reliability of that estimate. In this case, one thing we can almost be sure of is that it will not be exactly 100 man-days. It might be less or it might be more but the likelihood of it being exactly 100 is quite remote. Moreover, there is a much higher probability that it will be more rather than less because it is much more likely that we have overlooked part of the work rather than including work that will not be necessary.
There is a simple lesson here. If you are preparing the estimate, and have the opportunity to do so, then add an extra activity, preferably at the end, that could, if the worst comes to the worst, be omitted. Personally, I always add an activity such as "Final documentation and cleanup" and I try to make that about 3% of the total schedule. It's not a lot, but it is difficult for management to argue against and it is better than nothing.
The next issue is that if we do indeed know, with some confidence, the amount of effort involved, some work has already been done in formulating the project, objectives, and requirements, that sort of stuff. Consequently, we are presumably now talking about the project execution phase. Or, in software parlance, we are talking about "construction" and, further, let us assume that the effort involved in the final "transition" phase is not included in the 100 man-days. If it is, then back those man-days out of the total for the reason I'll explain in a moment.
The next question is: What does the project look like? Does it have elements that can be separated as in a work breakdown structure? How are those related and how many elements can be worked on concurrently? It is rare that you can work on all elements at once - there is usually some sort of precedence involved, a critical path.
But the real nub of the matter is how many people can work satisfactorily together as a team on any one of those elements? That appears to be highly dependent upon two factors. The first factor is the technology methodology you use, and the second is the make up of the team.
On the question of methodology, if you use pure waterfall, you may appear to get it done faster but the risks are much higher, certainly the risks of unfound coding errors, if not outright failure. And those errors found late in the work lead to much longer delays and higher costs to fix. If, however, you use a methodology such as the Rational Unified Process ("RUP") approach, the elapsed time may be a little longer but only because you will be consuming your resources more prudently and effectively. And further, your probability of a successful product will be higher.
On the question of the team makeup, my next assumption is that you have assembled the right mix of roles for the project. After that, the results are highly dependent on the quality of the team members, how experienced they are, how well they know each other's work habits, and how comfortable they are with each other. Still, we can hazard a guess. Conventional wisdom, i.e. practical experience, has it that the optimum number in a working group, including the leader, ranges from five to nine.
Let us pick the average number seven encompassing the roles of, say, architect/team-lead, analyst, developer, and tester. Let us also assume that these individuals can perform more than one role in each case. This will enable better distribution of the work as the work profile varies, i.e. internal "resource leveling".
Then theoretically it would take about fifteen days for this group to consume the 100 man-days. But we know that, in spite of resource leveling, no effort on a task can be mounted at 100% capacity to start of with, nor can it work flat out and stop equally suddenly. You simply have to "ramp up" as more work becomes accessible and "ramp down" as the work peters out. The profile of this effort curve is itself controversial.
For the efficient consumption of our estimated budget hours we must therefore also assume that the number of qualified team people available is variable. That is, we can bring them on and send them off to match exactly the work availability or accessibility. This assumption is also controversial since managements typically don't like to see people standing idle while they are "waiting to be engaged", but we'll let that pass.
I have discussed "Resource Loading" in my paper "Applying Resource Loading, Production
& Learning Curves to Construction: A Pragmatic Approach". You will find it here: .../papers/resource/abstract.htm.
In particular, you will find a typical profile in "Figure 6: Histogram, envelope,
and empirical resource loading input" here: .../papers/resource/learned.htm#fig6.
True this is taken from the building industry, but for any significant sustained efforts
the principle probably holds true.
The reason why I use the "construction" stage of a project as the yardstick is because it is the only part of a project that is sufficiently tangible to have an intrinsic effort content that can be estimated. All the other phases and stages are as long as, or short as, you want to make them - for better or worse!
My Figure 6 shows that 100% engagement
of the full team lasts for only 25% of the total elapsed time. Assuming this to be
true for software development (another big assumption) then we can calculate that
the "best" duration of the "project" under these assumptions is around 23 days. Note,
however, that this number is very sensitive to the percentage duration of the full
engagement of the full team. Note also how I have expressed this, because
it is often very difficult to measure in practice. The full team may be charging
time to the project for a greater proportion of the time but that does not necessarily
mean that they are fully engaged for all of that time!
So, the 23 days should be possible, but I suspect that it, too, is optimistic because it does not allow for:
- Any delays arising from required interaction with the "stakeholders"
- The restraining effect of the number of iterations required for the work in question
Still, if my assumptions are anywhere close for your case, you might establish a Rule-of-Thumb of around 25% of the man-day effort estimate for the project duration. If your teams are smaller (or larger) then you will need to recalculate accordingly, and adjust for any other of my assumptions that do not reflect your situation.
So, after all that, here are some real expert opinions on the next pages.
|
Introduction
