Level: Introductory Joe Marasco, Former senior vice president, Rational Software
30 Apr 2004 from The Rational Edge: The author of "The Software Development Edge" describes software development project progress in terms of classical physics, showing how the phases of iterative development can be mapped in terms of velocity and forces.
Projects tend to have a "percent completion" curve that is remarkably consistent from project to project. As a physicist, I have taken a look at this regularity and attempted to describe the underlying forces acting on the project by considering the derivatives of this curve. While extending the laws of physics to project dynamics may be somewhat speculative, I hope to help project managers understand the rhythm of their teams.
Have You Seen This One Before?
Most of the time, progress curves reported at the end of a project
look like the one shown in Figure 1.
Figure 1: A Typical Project Percent Complete Curve
In fact, most projects are planned to have a progress curve that looks like this. Most wind up reporting progress that looks somewhat like the plan, with some distortion to reflect reality.
Because so many project completion curves look like this, I began to wonder if there are fundamental forces at work that cause the curve to be this way. How does a physicist approach this problem?
It All Goes Back to Newton
Some people claim that "modern" physics started with Newton, although the first modern physicist was probably Galileo. No matter. What Newton told us was that the acceleration of a body was proportional to the force applied to it, the proportionality constant being the inverse of its mass. The more force, the more acceleration.
The problem is that acceleration is something we experience rarely.
We experience it when our car peels out at a stoplight, when we
stomp down on the brakes, or when an elevator first takes off or
comes to a sharp stop. More often, we are aware of two other variables,
velocity (speed, in common parlance) and position (location, or
where we are). We seem to be aware of going fast or going slowly,
and we are usually aware of where we are. But force is only indirectly
related to these metrics.
Derivatives, Rates of Change, and the Slope of the Tangent
For the calculus-aware, we know that velocity is the first derivative of position, and that acceleration is the first derivative of velocity, making acceleration the second derivative of position. If you never mastered calculus (or have forgotten it), substitute "rate of change" for "derivative." That is, your velocity is the rate of change of your position, and your acceleration is the rate of change of your velocity.
According to Newton, acceleration is proportional to the force applied, so the second derivative of the position of an object is proportional to the force. Another way of saying this is that you have to take the applied force and integrate twice to get information about the position. This is definitely not something that is intuitive for most of us. So we'll leave this integrating twice business alone for now, with the knowledge that there is sufficient mathematics to perform our integrations and differentiations once we understand the mechanisms.
For those of you who reason or think better graphically, remember that you can find the derivative or rate of change for any curve by looking at a line tangent to the curve at the point in which you are interested. For example, in the first example below -- the parabola -- the derivative or rate of change at the midpoint is zero. We can tell this because the tangent line to the curve there is horizontal, which has a slope -- or rate of change -- of zero. Prior to that, the tangent at any point has a positive slope; after the midpoint, the slope is negative.
A Simple Physical Example
A ball thrown vertically up in the air has a very well-defined
trajectory.
1
If we plot the
height as a function of time, we get the nice parabola shown in
Figure 2.
Figure 2: Trajectory for a Vertical Ball Toss
A note on the graphs in this article: we used Excel to plot them. We took the horizontal axis -- elapsed time -- to run from zero to a hundred percent, and then we used mathematical formulae
2
to generate the data values. We always normalize the vertical axis to "one" -- that is, we have the height go from zero to its maximum, which we call "one." We computed all the derivatives numerically, once again using Excel to do the computations and the plots. Hence you can replicate all of this yourself and need no knowledge of calculus to derive the results.
Now if we plot the velocity of the ball
3
,
we get the graph shown in Figure 3.
Figure 3: Velocity for a Vertical Ball Toss
Note that I have "normalized" the vertical axis so that the velocity falls between plus one and minus one; this helps us understand the concept by abstracting out the numbers
4
. This graph tells us that the ball starts out with a maximum velocity of one "unit," and that velocity decreases linearly until its reaches zero at the midpoint of its flight. This makes sense to us, because the midpoint of the flight is the highest point it achieves; at that instant, the ball is going neither up nor down, so its velocity is zero. Then it begins to fall, so its velocity is negative
5
. When the ball arrives at its starting point, its speed is exactly the same as when it was launched, except it is moving in the opposite direction.
Now, what about acceleration? Well, we just repeat the process
one more time, obtaining the graph shown in Figure 4.
Figure 4: Acceleration for a Vertical Ball Toss
Once again, we have "normalized" the numerical value
6
to -1. What this is telling us is that there is a constant acceleration. That is consistent with our model; close to the surface of the earth, the gravitational force is constant. And it is "negative" because we have chosen "up" to be positive, so the attractive force of gravity pulls the ball "down."
Note that this acceleration is negative for the entire flight of the ball -- even when the velocity is positive (upward flight), the acceleration is negative. We are "subtracting" velocity throughout the flight: We start out with some positive velocity which reduces to zero at the highest point, and then we keep subtracting until the velocity is as negative at the end as it was positive at the beginning.
Whew! Newton is vindicated. We have "experimentally" verified that a parabolic position graph implies a constant acceleration, which in turn implies a constant force.
Can we use reasoning of this type to understand the "forces" at work on a project? As with acceleration, we do not experience these forces directly. Rather, we observe things that are indirectly related. So let's return to the percent complete curve; it describes what happened, plotting the combined results of all those forces we don't directly observe. If we assume this project completion graph is prototypical, then what would that tell us about project dynamics?
The "Project Completion" Graph: Plotting Position Against Time
As we have already pointed out, most projects can be plotted according to the following graph:
7
Note that we have once again normalized things, so that the time axis goes from zero to a hundred percent, and the vertical axis also goes from zero to one hundred percent.
Also note that we have somewhat arbitrarily positioned 50% complete at 50% of the elapsed time. The symmetry of the curve is a simplifying assumption, but one that is useful for this exposition. For the time being, we have no reason to assume otherwise.
8
The Curve of Human Behavior
Generically, these curves are referred to as "S-Curves"
9
because they resemble the letter S if you stand back a bit and squint. They describe a wide variety of human behavior; the classic "learning curve," for instance, assumes this shape. The notion that a project completion curve mirrors a learning curve ought to tell us something.
When we begin to learn something new, we spend a lot of time fumbling around without understanding much. This corresponds to the first, "flat" part of the curve, where time goes by without much progress. Then, as we begin to understand what is going on, our progress increases; this is reflected by the second part of the curve, sometimes called "the ramp." During this period we actually make a lot of progress per unit time, and if we could continue at this rate we would finish our task sooner. But inevitably, we enter the third part of the curve, which goes flat on us again. What is happening here is that we "plateau"; we stop making dramatic progress, and the last few percent (learning all those remaining annoying details) takes a long time. This learning experience is repeatable over and over again, from domain to domain.
When the ramp is gently inclined, we talk about an "easy" learning curve; when the ramp goes up very fast, we talk about a "steep" learning curve. Many people cannot handle steep learning curves; they need more time to assimilate the bulk of the new knowledge.
"Quick studies" are interesting people; they have a very short approach period, go up a very steep ramp, and then quit without ever learning the last few percent. By truncating both flat parts and navigating steep ramps, they can radically abbreviate the time it takes them to acquire knowledge and skills. But they are rare indeed. Most of us do best with two flat parts and a moderate ramp.
Projects follow a similar rhythm. Early in the project, you make
progress slowly. There is a lot of planning, organizing, and discovery
that causes you to expend a lot of effort without making much tangible
progress. Once you get going, you get on the ramp, and progress
feels (and probably is) somewhat linear (although we know it is
not quite linear). Late in the project, things slow down again,
which explains why finishing is hard. Once again, nailing down all
the details you need to complete to deliver the product takes a
relatively long time to do. That is why a project that is 90 percent
done is probably low risk from a technical point of view, but will
still take a while to finish. Things slow down at the end, and there
is almost nothing you can do to fix that. Adding people at this
stage, for example, will just push the end date further out, as
has been shown over and over again.
What about new product acceptance? Same thing. Slow at first, as people have to find out about the product, understand its costs and benefits, talk to their colleagues, and go through a selection and acquisition process. These are the early adopters. Then there is a ramp, when the product "catches on" and demand seems to go through the roof. This is the point Geoffrey Moore calls "crossing the chasm,"
10
when a product goes mainstream. This goes on for a while, and then sales begin to slow. We have now hit the third part of the curve, the plateau. The product is now deemed "mature," with trailing or late adopters being the principal buyers. Very likely, another rival product is hitting its ramp at this point and taking away market share from the earlier product. So this universal curve also represents a product's sales lifecycle.
The Project Velocity Curve
Before getting into myriad debates about how "real" this curve is, let's just assume that it represents the majority of reported "percent complete" data and see what can be inferred. Like many other examples in physics, we first try to understand the idealized behavior, and then modify our conclusions by adding back in the effects of air resistance and other real world phenomena to the model.
The crucial observation is that this curve is a "position versus time" plot. In other words, this curve plots our "position" at any point in time. Now, what does the "velocity" curve look like?
Mimicking the steps used above, we have the technology to answer that question.
Taking the rate of change of our project completion curve yields
the graph shown in Figure 5.
Figure 5: Velocity for Project Percent Complete Curve
By now you are used to having the vertical axis normalized. What
this graph tells us is that projects start off slowly and move faster
for a while. Then they reach maximum velocity (in Figure 5, maximum
velocity is achieved at the halfway point, but that is because our
project completion curve is symmetric), and then start to slow down.
As you cross the finish line, you are actually going fairly slowly,
much as you did at the very beginning.
This is consistent with our common, everyday experience. Projects are slow to get started, they seem to "gather momentum" at some point, and then they "bog down," and things go more slowly. Finishing is hard. Getting all the fine details worked out so that you can deliver the product seems to take forever. Often it feels like you stagger across the finish line.
Once again, the exact values for this curve may vary, but the pattern, from project to project, is remarkably consistent. So what does this say about the underlying "forces" driving the project?
Well, at this point the physicist would take another derivative. Let's do that!
The Project Forces Graph
The resulting acceleration curve, which implies the forces at
work, looks like the one in Figure 6.
11
Figure 6: Acceleration for Project Percent Complete Curve
What are we to make of this?
Well, here's one interpretation: During the first third of the
project, we see an increasing positive force. This corresponds to
a lot of enthusiasm for the new project, the addition of new team
members, and a general optimism about the chances of success. This
might cynically be called the "ignorance is bliss period." It is
this positive, increasing force that causes the project to gain
velocity (sometimes colloquially called "momentum," or "the big
mo").
12
At about the one-third point, this positive force begins to decline. This could correspond to reality setting in; people are far enough along to start to understand what the real problems are and are beginning to feel some schedule pressure. After all, they have now used up one third of the time but still have mountains of work left to do. Also, the team is beginning to feel the full burden of a large staff; a lot of time is spent in meetings, and communicating information to all the members of the team grows difficult.
And then we reach the halfway point. At this point, according to the graph above, a negative force sets in. The team begins to feel the project "pushing back." Many of the really tough problems are not succumbing to solutions as quickly as we thought. People begin to really panic as more and more sand slips through the narrows of the hourglass. At about the two-thirds point, the force hits its maximum negative value; there is this sensation of swimming in molasses. If the project stays here for very long, it dies.
And then, when we most need it, the project "turns the corner." There is a breakthrough, and all of a sudden, things don't look quite so bleak anymore.
13
While there is still a negative force at work -- the knowledge that there are still a million details left to complete, and not much time to do it in -- this negative force decreases. The main reason for this is that the team can see the finish line. The negativity decreases until we get across the finish line.
Be aware that the actual "turning points" on this curve -- one third, one half, two thirds -- will vary from project to project, and will in turn affect the velocity curve and the project percent completion curve. There is nothing magic about the one-third, one-half, and two-thirds completion points; these result from the symmetric project completion curve we originally chose for ease of exposition. The exact points on our project are unknowable; all we can "predict" is that it will go through these phases.
This is kind of gratifying. We start with a prototypical percent complete curve, take a couple of derivatives, and infer the forces underlying the project. The data seems to empirically fit the theory. Have we really accomplished anything here?
Reality Intrudes
A physicist looks at a theory from a number of different points of view. It is always dangerous to extrapolate physical ideas like position, velocity, and acceleration to group dynamic variables like "project percent complete," "project velocity," and "project forces." We must be extremely careful not to attribute more "science" to this than can really be there.
On the other hand, the analogy seems to give results that are consistent with reality. So let's move to the next step.
A physicist judges a theory by its ability to explain and predict. That is, a theory must first explain the results of all known experiments. If experimental results exist that contradict a theory, then the theory is wrong, unless you can go back and show that the experimenter made a mistake. In our example, we have seen that most projects have a similar percent complete curve, so all that will change from project to project is the details of the transition points of the derived curves.
And that brings us to the limited utility of the theory. What we would like to be able to do is to predict the percent complete curve while we are at some state of incompletion. Or to put it another way, we want to know when we are going to be finished. At any point in time, all we have is that portion of the curve "behind us," and some notion of the velocity curve. The "forces" curve is pretty hard to pin down quantitatively. In fact, it is often hard to understand the velocity curve, although metrics that could indicate velocity would be very, very useful. Knowing your "position" is important, but to more accurately forecast, you need both actual position and actual velocity.
Today, many of our project metrics focus exclusively on position -- "Where are we?" As we can see from this discussion, having velocity metrics -- rate of change of position, how fast are we going? -- is equally important. And should we ever get to the point of being able to understand how the velocity is changing, then we would have an even more complete picture. So we need to think about project metrics collection in this light.
What About Iterative Development?
All that we have said is somewhat introductory to the notion that
we don't do projects in one fell swoop, but break them down into
iterations. Each iteration has its own rhythm, so the graphs described
above are really only an approximation. For example, for a project
with four iterations, the percent complete curve would probably
look more like Figure 7.
Figure 7: Percent Complete Curve for a Four-Iteration Project
Here what we see are four S-curves stacked one on top of another. Percent complete is cumulative, and we have made the assumption that each iteration takes 25% of the time and gets us 25% along on the completion curve. In the following sections we will depart from this simplifying assumption.
Now let's jump to the velocity and acceleration (forces) curves that correspond to this four-iteration percent complete graph.
Figure 8: Velocity and Forces in a Four-Iteration Project
What do these graphs of the derivatives tell us?
What we see is that the velocity curve replicates itself four times -- no surprise there. The project gains and loses velocity four different times, corresponding to each iteration having a somewhat similar rhythm. The second derivative curve -- acceleration
14
-- has three discontinuities, which we can also "see" in the velocity curve.
15
What this means is that at the start of each iteration after the first, you need to "kick" the project out of its residual negative force from the previous iteration and impart an initial positive force. This is what causes the velocity vector to change abruptly. Without this instantaneous, discontinuous force, you won't get going again without losing time.
Most good project managers know about this and apply the requisite force at the appropriate time. We shouldn't be all that surprised by the discontinuity -- after all, we started at zero with a non-zero positive force to get the project underway. All we are saying is that at the end of the iteration we still have a residual negative force, and we need to "jump start" back to that positive force we began with.
Having applied this positive force, you need to once again build it until the iteration hits its "wall," and the inevitable negative forces set in. Then it's just a question of hitting the breakthrough for that iteration, the one that again reverses the negative force curve.
So now we know how to apply our model to a multiple iteration
project. It's the same game: Plot the percent complete curve, take
the derivatives, and interpret the results. The only thing that
has changed is that our percent complete curve is a little more
complex at the outset. But the rules of the game are the same.
But all this is a bit boring when all the iterations look the same; not to mention the fact that we have no insight regarding the real project at hand, because thus far in our analysis nothing truly mirrors reality. So let's get real.
Iterations and Phases
In real life iterative development, we may have many iterations, divided up into distinct phases. How can we inject this sort of reality into our model?
Well, I'm not up to a multi-phase, multiple-iterations-per-phase graph. And it's not clear that we need that complexity anyway. After all, it is the phases that have the biggest difference in their characteristics, not the iterations within the phases. So, to keep things reasonably simple, let's model the phases and assume only one iteration per phase.
The Rational Unified Process® defines four phases:
16
- Inception
- Elaboration
- Construction
- Transition
These four phases do have different characteristics. Early in
the project, we are doing a lot of discovery (new learning). In
the middle of the project, we do somewhat less discovery but lots
of invention; there is still a lot of learning going on. Later in
the project, we are actually doing the activities that count for
"completion"; some invention and lots of implementation. Learning
drops off a bit as the project moves toward completion.
17
At this point it is necessary to decouple the ideas of "learning" and "completion." Up until now we have been assuming they are the same. Here are some numbers that my colleague Philippe Kruchten
18
believes are applicable to the four phases:
Table 1: Learning and Completion Metrics for Phases in the Rational Unified Process
|
Phase
|
Percent of Elapsed Time
|
Percent Learned
|
Percent Complete
| | Inception | 0 - 10 | 0 - 10 | 0 - 5 | | Elaboration | 10 - 40 | 10 - 60 | 5 - 25 | | Construction | 40 - 90 | 60 - 90 | 25 - 90 | | Transition | 90 - 100 | 90 - 100 | 90 - 100 |
|
What these numbers tell us is that we learn faster than we achieve completion when we do phased, iterative development. This accelerated learning is what helps us reduce risk. How do we introduce these ideas into our model?
We have only two modifications to make:
- We are going to plot "percent learned" and "percent complete" separately.
- For each of these curves, we will plot the S-Curve segments according to Table 1, in order to model that level of reality.
Results
Here they are. We'll present all the results together in Figure 9 and then open up the discussion. We include Philippe's table again so that it is easy to remember the phases.
|
Phase
|
Percent of elapsed time
|
Percent Learned
|
Percent Complete
| | Inception | 0 - 10 | 0 - 10 | 0 - 5 | | Elaboration | 10 - 40 | 10 - 60 | 5 - 25 | | Construction | 40 - 90 | 60 - 90 | 25 - 90 | | Transition | 90 - 100 | 90 - 100 | 90 - 100 |
|
Figure 9: Graphs for Table 1 -- Learning and Completion Curves
Discussion of Results
There would appear to be a lot of explaining to do.
First, let's address the difference in the shapes of the learning and completion curves. Basically, you achieve 60% of your learning in the first 40% of the project, and are only 25% complete at that point. This reflects the notion that in iterative development we emphasize learning early to reduce risk. The counterweight is that you don't make much "visible" or "tangible" progress, because often the learning does not have many artifacts that go along with it. In any event, as a project manager you are going to have the following conversation at the 40% point of your project:
Boss: "You've used up 40% of the time, but you show only 25% complete. You are in big trouble."
You: "Not really. In iterative development, learning is important in the first half. And we have accomplished 60% of the learning we set out to do."
Boss: "Really? That's great. Can you show me the 60%?"
At this point I would suggest having some additional arrows in your quiver.
Now let's look at the velocity curves. Let's defer discussion of the first and fourth phases to later, because it's more interesting to discuss these and their associated forces at the same time. For the moment, let's concentrate on the Elaboration and Construction phases, where there are interesting differences.
What we see is that learning velocity peaks during Elaboration, whereas completion velocity peaks during Construction. This is consistent with our model, in which we set out to get over the learning hump in Elaboration, sacrificing or deferring completion a bit. The idea is that the measurable artifacts of completion only begin to really show up during Construction, so that is when that curve shows its peak.
We might ask why both velocity curves go down to almost zero at the 40% point and then back up. Wouldn't it be better if we could "keep" some of that velocity across the boundary? Yes, it would. The reason we can't is that the two S-Curves join at the boundary. In fact, discontinuities in the force curve show up at the boundaries for this very same reason. The reality that corresponds to this mathematical artifact is that distinct phases cause disruption on any project. That is why many senior project managers try to blend things at the boundary; they sometimes try to get an "advance team" working on the next phase a little early (before the antecedent phase is actually done) to smooth the transition over the boundary. It is hard to pull this off. The other logical consequence of this effect is that the more phases you have, and the more iterations you have within phases, the more boundaries you create. If there is a fixed overhead at each boundary, then you increase your total overhead by increasing the number of phases and iterations.
The forces comparison for Elaboration and Construction is also pretty clear; the learning forces are stronger during elaboration and relatively weak during construction. On the other hand, we note that the completion forces have about the same peak values during both Elaboration and Construction, which is a good thing.
Now let's address the Inception and Transition phases. Each of these is accomplished over a short time interval, only 10% of the project each. Because the S-Curve causes its derivative curve to have a peak, accomplishing that turnaround in a short period of time causes the peak to be bigger. Correspondingly, the force curve necessary to turn around the velocity curve in this short interval also requires large peak forces. This is why when we get to the force curve, both for learning and construction, we see maximum peak forces in these intervals. It is a result of having a very short interval. The antidote, if you will, is to not have S-Curve behavior during these short periods. If the progress curve here were simply linear over the interval, then the force would be less. S-Curves and their derivatives do better over longer time periods. They are perhaps the right model for long periods, and a poor model for short intervals.
On the other hand, these "large" forces may be real and not artifacts of the S-Curve compressed into short intervals. It is certainly the case that we have large forces at the end of the project, during Transition. Anyone who has ever had to finish a project will attest to that; it's what makes finishing so hard -- you need a big push when the team is the most tired. And, there are also large forces early in the project, during Inception, because it is at the end of Inception that we have our first "go/no go" decision to face. If people working on the project are concerned about cancellation at this early branch point, then you can be sure that there will be large forces at work.
One Last Graph
There is one other graph that is perhaps of interest. Let's assume
that we can "add" the completion forces and the learning forces
together. Force is a vector, so the assumption we are making here
is that the completion forces and the learning forces are co-linear,
or acting in the same direction, a somewhat arbitrary assumption.
However, if we make this assumption, then we can sum the forces
and get the total force on the project as a function of elapsed
time, as Figure 10 shows.
Figure 10: Total Forces on a Project (Learning + Completion)
Let's look at some areas under the curves in the four regions.
19
We note that all the segments have the same form, so let's look
at the peak value of the total force and the length of time the
segment is in play; the product of these two will be proportional
to the area, as Table 2 shows.
Table 2: Product of Total Force Peak Value and Time Interval Length
|
Phase
|
Percent of Elapsed Time
|
Length of Time Interval
|
Peak Value of Total Force
|
Product (Impulse)
| | Inception | 0 -10 | 10 | 0.8 | 8 | | Elaboration | 10 - 40 | 30 | 0.4 | 12 | | Construction | 40 - 90 | 50 | 0.2 | 10 | | Transition | 90 - 100 | 10 | 1.0 | 10 |
|
For the mathematically and physically inclined, we know that the area is an integral, and the integral of force over time is equal to the change in momentum.
20
What we see from the table is that the change in momentum is roughly the same over the four phases. The change in momentum (or impulse) is the same during Construction and Transition -- ten units. The biggest impulse is during Elaboration, twelve units. And the combined impulse of the first and second phases -- twenty units -- is equal to the combined impulse of the third and fourth phases. Half the total impulse is applied during the first 40% of the elapsed time; this again expresses the idea of "front loading," which we believe is a good thing.
Note also that the discontinuity in the total force curve at the 40% boundary is not too large. That is probably also a good indicator.
So the conclusions drawn from using Kruchten's and Royce's numbers for learning and completion percentages in the four phases are consistent with the benefits we believe we see in iterative development projects. While we have made many assumptions and pushed the model about as far as we are comfortable with, the results do appear to be both internally consistent and consistent with observed behavior.
Summary
We have taken a simple, universal model -- the S-Curve -- and applied it to software project management. We used simple physics to infer from the S-Curve the velocity and acceleration, and hence the forces, at work on the project. We extended the model to multiphase iterative development and found results that are consistent with observation. We even attempted to separate learning from completion metrics and separately analyze those forces. Finally, we added the forces together and drew some conclusions about the total force as a function of time, and the impulse applied to the project during its various phases.
Much of this analysis is speculative, and we encourage you to ponder this and give us alternate interpretations of the graphs we have drawn. I hope that many of you will find other nuggets in here that neither my reviewers nor I have found yet.
In the meantime, the conceptual model can make us ready to anticipate and deal with the various phases of the project as they play out. Knowing that there is some degree of "determinism" at work can sometimes be a comforting thought when a project hits its low point and you're worried that the team may lose hope.
Notes
1
For the purposes of this example,
we will ignore air resistance. As in all physics experiments that
make this assumption, this has the disastrous side effect of killing
the experimenter, as he has no air to breathe.
2
If you really, really, want to know the formulae
I used, send me an e-mail.
3
We do this by numerically differentiating the
data points from the parabolic curve. That is, we take successive
differences of the values of the first curve, then multiply by a
constant to get the values to fall between plus and minus one. The
careful observer will notice that this causes us to "miss" the first
point on the first derivative curve, and the first two points on
the second derivative curve, and also cause a very slight shift
(half a bin, actually) on the derivative curves. This won't become
noticeable until later; it doesn't affect the arguments at all,
but is just an artifact of how we are computing the derivatives.
4
One convention is important: the "up" direction
is positive. This will determine which velocities are positive and
negative.
5
Hence the difference between velocity and speed.
Speed is always positive; as the ball falls, it speeds up. However,
its velocity becomes more negative. The number representing speed
and velocity gets larger in magnitude; however, velocity takes into
account direction, so it becomes a larger negative number.
6
Our friend Excel insists on calling zero "-0."
We are smart enough to know that there is only one zero, and it
doesn't have a sign.
7
Here come the caveats. This is of course an
idealization. Real life curves are rarely so smooth. Also, projects
don't uniformly move forward, although it is rare to see a reported
percent completion curve show a dip. But the real problem is that
there is no single metric we can use across the entire project to
capture "percent complete." One of the largest problems on any project
is figuring out how to differentiate reported progress from actual
progress.
8
You may see curves that look like this that
have various other "percent completes" at 50% of the elapsed time.
It is allowed. We don't deal with them here for simplicity.
9
On Sesame Street, we would say that this section
is brought to you by the letter "S".
10
Geoffrey A. Moore and Regis McKenna, Crossing
the Chasm : Marketing and Selling High-Tech Products to Mainstream
Customers, Revised Edition. Harperbusiness, 1999.
11
The slight shift mentioned in footnote 3 is
noticeable here; the forces curve should cross the axis at 50%.
Once again, this is an artifact of the crude way in which we compute
the derivative, and is absolutely irrelevant to the argument.
12
Physics seems to intrude into our language
even when we don't want it to.
13
The more crusty project manager may be heard
to murmur at this juncture, "We may finally have broken the back
of this son of a bitch."
14
By now you are used to the idea that the graphs
can be labeled "acceleration" or "force" interchangeably.
15
It may be hard to see, but there is a difference
between the four peaks at 100% on the velocity curve and the three
troughs at about 10%. The passage through the maxima is smooth,
with a zero derivative. On the other hand, the passage through the
minima is not smooth; the slope changes abruptly. That is what leads
to the discontinuity on the acceleration (force) curve.
16
Philippe Kruchten, The Rational Unified
Process: An Introduction, Second Edition. Addison-Wesley, 2000.
17
The relevant reference here is: Grady Booch,
Object Solutions: Managing the Object-Oriented Project, p.
61. Addison-Wesley, 1995.
18
The "completion" numbers come from work by
Philippe Kruchten and Walker Royce in 1999 on the Rational Unified
Process. See footnote 16. The "learning" numbers are from a private
communication with Philippe, and represent his best estimate.
19
Here we will consider all areas to be positive.
That is, we take the absolute value of areas below the axis, so
that there are no "negative" areas. If we didn't do this, the total
area would integrate to zero.
20
More precisely, the integral of the force over
time is the impulse, which is equal to the change in momentum.
About the author  | | | Joe Marasco, a retired senior vice president and business unit manager for Rational, held numerous positions of responsibility in marketing, development, and the field sales organization, overseeing initiatives for Apex and Visual Modeler for Microsoft Visual Studio. In 1998 he served as Senior VP of operations. He retired from Rational in 2003. He holds a Ph.D. in physics from the University of Geneva, Switzerland, and an M.B.A. from University of California, Irvine. |
Rate this page
| 
