|
CPM vs. SDLC
While I was reading a popular, bold-faced thread posted by Norrick, I encountered a mention of the GANTT charts and the like, and that triggered a rant I've been nurturing about the futility of Microsoft Project; of network diagrams actually.
I've prepared a handful of proposals and those plain boring documents myself, including Critical Path Method (CPM) analysis for the project schedule, but alas! with a diffident heart.
I have been sulking at the inaptness of a CPM network diagram to represent an SDLC activities.
For many reasons, some of which are here, and most of which I forget because I don't put them to paper when I am thinking the night in bed away, I believe a CPM (or even PERT for that matter, that's worse with its resource allocation) is not suited to represent an SDLC:
* Many SDLC activities are spiral and CPM assumes activities only to be linear. For instance, a debug-and-fix drill is iterative and cannot be represented on a network diagram.
* Some activities are dependant on more than one activity in an SDLC but CPM disallows any convergent or divergent nodes other than the terminal nodes.
* CPM requires that every activity be represented on the network diagram only once, whereas some activities, especially those that are spiral and can be carried our asynchronously need to be represented as more than 1 activity or node.
How unrealistic! And they just want it because they think its a mundane routine to have one or more diagrams that no one understands, but has nostalgic memories of from their college days at the B-school, where they remember smoking more cigarettes than having read pages of their course book.
Sathyaish Chakravarthy
Tuesday, February 17, 2004
I think there is something wrong with IT. I think you'll find that most people on JOS will see your title and think that:
CPM is an old operating system for Z80 computers.
SDLC is IBMs version of HDLC, Synchronous Data Link Control.
I know we're not talking about cutting edge technology but this sort of re-use is painful.
whattimeisiteccles
Tuesday, February 17, 2004
Suggestion:
Don't use Critical Path, Use Critical Chain.
OR
Don't use waterfall, use iterative.
These two ideas will help more than arguing over PERT vs. GANNT, in my experience ...
Matt H.
Tuesday, February 17, 2004
>Critical Path, Use Critical Chain
Oh..oh...I am choked of oxygen, astro. Astro speak ahead, slow down!
What's the big diff, dude?
Tuesday, February 17, 2004
I don't think that PERT/CPM is a great tool for modeling software development work, but the objection is mostly centered on how these tools fail to incorporate uncertainty and variation.
I don't really agree with the objections you've raised, however:
Spirals: Spirals are a logical model of work, great for packaging a certain kind of similarity into a small logical package that is executed again and again. This work is carried out linearly in time, however. Each time you move through the spiral, it is a different instance, and needs to be accounted for as such. The network diagrams make this explicit.
Also, there is a point of diminishing returns on how far you drill down into the work detail with these things. For instance, it doesn't usually make sense to drilldown below the point where work is transferred between two resources. A primary goal of these project networks is to facilitate synchronization of resources - unnecessary when only a single resource is involved. Use a to-do list to capture necessary details at this level of granularity.
Convergent/Divergent Nodes: Convergent nodes are supported explicitly in PERT networks. Divergent nodes are also supported, but all paths must eventually converge on a single target end state. If you think about it, this makes sense. The end state means that all work has been completed and is therefore dependent on the completion of each independent chain of tasks.
Each activity appears only once: I think you are confusing a logical model of work with a physical model. Each *instance* of and activity is captured exactly once. There's no reason you can't have 3 tasks that are identical except for when they are performed.
swabbie
Tuesday, February 17, 2004
Hi swabbie,
Thanks for such an overwhelming participation in this thread. I have some adamant views to share. Tomorrow. Night time. Going home.
Cuss me all ya bitches, I am the king of pop! Will return tomorrow.
Sathyaish Chakravarthy
Tuesday, February 17, 2004
Eli Goldratt's book "Critical Chain" describes a radically different approach to managing the risk of the project running late.
On the other hand, in traditional, PERT-Chart derived project worldviews, a single task running a single day late can create a one day project slip. Critical Chain Accounts for this. Critical Path does not.
The two are very different ...
Matt H.
Tuesday, February 17, 2004
I'm not familar with Critical Chain. So when you say, "a single task running a single day late can create a one day project slip. Critical Chain Accounts for this. Critical Path does not." What do you mean by "accounts for this"?
Critical Path accounts for this by showing that if any task along the critical path slips a day then the whole project slips a day. What does Critical Chain do differently?
Nick
Tuesday, February 17, 2004
If a task on the critical PATH slips one day, the end date of the project slips as well. Critical CHAIN places a buffer at the end of the project that protects the project end date from being impacted by uncertainty (i.e. slips) inherent in critical tasks. The goal here is to make the project timeline stable in the presence of uncertainty.
This is a simplified explanation. If you want to bone up on the details, check out Frank Patrick's website:
http://www.focusedperformance.com
Click on the "Project Management" link near the top.
swabbie
Tuesday, February 17, 2004
I'm sorry, the "These words sound similar and I'm too lazy to check google and amazon" thing is really starting to bother me.
Joel Spolsky did a review of critical chain awhile back that explains the theory:
http://www.joelonsoftware.com/news/20021119.html
--> In a nutshell, the theory is "Pad the project, not each individual step"
Enough.
Matt H.
Tuesday, February 17, 2004
Well, that was an interesting reaction, Matt.
When I'm having a conversation with someone and mention something they're not familiar with, I certainly don't expect them to say, "Hold on. I'm going to go Google that and maybe read a book on it." Usually, they would just ask "what's that?". And if I could sum it up in a sentence or two (like you were able to do), I wouldn't give it a second thought.
In my view, discussion forums are just conversations extended into cyberspace. The flow of conversation is stilted, but all the other rules should apply.
Nick
Tuesday, February 17, 2004
"Pad the project, not each individual step" nicely summarizes one effect of the Critical Chain method, but doesn't really touch on the method or the logic behind it at all. Check out the website I mentioned above, or post a question here. I'll be happy to attempt an answer. Frank Patrick reads this sometimes as well, or at least used to. I'm sure he'd be happy to hold forth as well, if he sees a question.
swabbie
Tuesday, February 17, 2004
<SWABBIE ARGUES>
Spirals: Spirals are a logical model of work, great for packaging a certain kind of similarity into a small logical package that is executed again and again. This work is carried out linearly in time, however. Each time you move through the spiral, it is a different instance, and needs to be accounted for as such. The network diagrams make this explicit.
Also, there is a point of diminishing returns on how far you drill down into the work detail with these things. For instance, it doesn't usually make sense to drilldown below the point where work is transferred between two resources. A primary goal of these project networks is to facilitate synchronization of resources - unnecessary when only a single resource is involved. Use a to-do list to capture necessary details at this level of granularity.
</SWABBIE ARGUES>
Label_Iteration:
That's is exactly my point worded against it. Debug and fix is spiral. You discover a bug by testing, you fix the bug, then you regression test, then you rebuild and ship a new version. This is not just for one bug alone and I am not talking at the bug (micro) level, rather at the activity level. But this cycle is, umm...a cycle. It is cyclic. So you should ideally have a circle winding into itself, to depict this rather than a node connector connecting a linear progression of nodes.
<SWABBIE ARGUES>
Convergent/Divergent Nodes: Convergent nodes are supported explicitly in PERT networks. Divergent nodes are also supported, but all paths must eventually converge on a single target end state. If you think about it, this makes sense. The end state means that all work has been completed and is therefore dependent on the completion of each independent chain of tasks.
</SWABBIE ARGUES>
Once more, same thing as I said. You cannot have a divergent node, a node from which more than one activity shoots off, in CPM. That is an illegal representation. But it is not unlikely in the real world. The only place it allows you to have convergent and divergent nodes is at the terminals, i.e START activity and the RESULT activity or event rather.
<SWABBIE ARGUES>
Each activity appears only once: I think you are confusing a logical model of work with a physical model. Each *instance* of and activity is captured exactly once. There's no reason you can't have 3 tasks that are identical except for when they are performed.
</SWABBIE ARGUES>
On Doubt GoTo Label_Iteration
My predicament emanates from the real world project proposals that a company like Microsoft reviews and expects you furbish a network diagram for a humungous sized project to be completed in less than 2 months. I held my head redrafting the CPM over and over again a several times and I also bore the onus of writing the whole darn proposal, I won't bitch.
Sathyaish Chakravarthy
Wednesday, February 18, 2004
"So you should ideally have a circle winding into itself, to depict this rather than a node connector connecting a linear progression of nodes."
The cycles play out linearly in time, though. You don't start cycle two until cycle one is completed. Logically you are correct, the work is like a loop and a loop is the best way to think about and understand it. The point of the network diagram, though, is to show how things play out over time. To do this, you have to unroll the loop and show how each instance of the loop relates to the others in time. These are two views of the same thing, but they serve different purposes. The "loop" view is useful for understanding the logical structure of the work. The network view is useful and appropriate for understanding the temporal structure of the work.
"The only place it allows you to have convergent and divergent nodes is at the terminals, i.e START activity and the RESULT activity or event rather."
This is not accurate. Convergent and divergent nodes can appear anyplace in a network. Convergent nodes represent synchronization points where several distinct pieces of work must come together, for example code integration. The predecessor nodes represent independent necessary conditions for the node they converge on. Divergent nodes are places where one node serves as a necessary condition for several other nodes. for example, you might have both code generation and documentation tasks dependent on the completion of a prototyping task. In project, you can create these relationships in several ways including the little button that looks like a link in a chain, or by typing row numbers into either a predecessor or successor field.
Perhaps I am just misunderstanding what you are saying.
As far as constructing these diagrams goes, I feel your pain. The tools are tedious and difficult to work with. They provide very little support for working with things in a logical manner, and they are improperly used by a lot of folks, including those that want a precise, detailed picture of work at exactly the point in the project when you have the least information.
My typical approach is to use Project only as a GUI. I have other tools for working with the data, and I pull it into Project as needed so I can have the pretty charts and whatnot. I typically try to avoid this approach, though, because there is so much bad intuition out there about what these pictures are trying to tell you.
swabbie
Wednesday, February 18, 2004
 Recent Topics
Fog Creek Home
|
