Not to defend software engineers, but there are plenty of examples of projects exploding in time and cost outside the software industry. For example, Boeing's 777X (which is not even a new design), was supposed to launch in 2019-2020. Today, it is expected to launch in 2025, see https://youtu.be/wyJFnPWe-gs.
I was having just this debate with some colleagues about two weeks ago. Having had success with leading some projects using a dependency graph, I simply could not, and cannot, fathom the spreadsheet approach.
Of course, as is the norm in our industry, I was completely oblivious to prior art. I knew I couldn't be the first person to have used a dependency graph to manage a software project. But I didn't know specifically about CPM --- even though I knew about CP/M. ;-)
I wonder when this industry will figure this out. In the end, take the best parts of the existing tools (waterfall and agile) and make your own project planning. At _least_ take from either waterfall or agile. It seems we're always inventing our own and they're always worse than either extreme.
<blockquote>We are a species that can build and operate cruise ships and construct safe airplanes with approximately 340,000 parts, but we cannot plan the implementation of a new payments and HR system.</blockquote>
Given the steady drumbeat of stories about Boeing failures, I'm not sure we can construct safe airplanes anymore, either...
Project management for any kind of project involving "design" is a tricky beast. By definition, "design" involves unknowns, so any project planning done in advance must be either vague and fuzzy , or full of made-up shit. Planning is also an overhead that doesn't directly contribute to getting the job done. It can help you figure out very roughly what needs to be done, in what order, and how long it will take, but aside from some possible dead-end avoidance and better task-ordering, it doesn't really reduce the total amount of work required, it just adds more work. The more accurate and further into the future it tries to project, the more unknowns it has to predict, and the more work and BS it becomes.
You can expend more and more effort on more detailed/accurate/prophetic project planning, but there is a definite decline in the return-for-effort. From my experience with big waterfall Aerospace projects, accurate plans required accurate requirements and designs in advance to try to minimize the unknowns. History showed "the earlier in the waterfall process that errors are made, the more expensive they are to rectify", so more and more effort was expended on trying to get these right, till the planning/requirements/design was significantly more work than actually implementing it. And they still got it wrong.
"Agile" was a reaction to this; why waste too much effort on planning/design/etc in advance when it's going to be wrong anyway? Let's just iterate our way to the solution! Unfortunately, iteration is not always an optimal way to reach the solution, and you can't iterate your way out of a local-maxima. You can find yourself iterating down every dead-end-path to a sub-optimal solution that can't be iterated better any more, and requires a complete re-write from scratch.
So the sweet-spot is somewhere in the middle. The trick is have a rough plan all the way to the best-guess-end-goal, but don't waste too much effort on it. Beyond a minimum level of effort it will not finish the project any cheaper/faster/better, and will only give diminishing improvements to estimates of what the final cost/time will be. Know that it's just a best-guess for now, and update it as you go. Use it to inform your development iterations to allocate resources, avoid possible dead-ends, and choose a path that can reach the best solution.
Identifying critical paths is definitely one of the useful tools for doing this, but be aware of the effort-vs-return trade-offs in any kind of future projections for design projects, and that they are always varying degrees of wrong.
I've been known to plan projects with graphviz :)
But yes, then I constantly got questions amounting to "why can't you just use a spreadsheet?!"
Not to defend software engineers, but there are plenty of examples of projects exploding in time and cost outside the software industry. For example, Boeing's 777X (which is not even a new design), was supposed to launch in 2019-2020. Today, it is expected to launch in 2025, see https://youtu.be/wyJFnPWe-gs.
Yikes --- you must be inside my head some how!
I was having just this debate with some colleagues about two weeks ago. Having had success with leading some projects using a dependency graph, I simply could not, and cannot, fathom the spreadsheet approach.
Of course, as is the norm in our industry, I was completely oblivious to prior art. I knew I couldn't be the first person to have used a dependency graph to manage a software project. But I didn't know specifically about CPM --- even though I knew about CP/M. ;-)
I wonder when this industry will figure this out. In the end, take the best parts of the existing tools (waterfall and agile) and make your own project planning. At _least_ take from either waterfall or agile. It seems we're always inventing our own and they're always worse than either extreme.
<blockquote>We are a species that can build and operate cruise ships and construct safe airplanes with approximately 340,000 parts, but we cannot plan the implementation of a new payments and HR system.</blockquote>
Given the steady drumbeat of stories about Boeing failures, I'm not sure we can construct safe airplanes anymore, either...
Project management for any kind of project involving "design" is a tricky beast. By definition, "design" involves unknowns, so any project planning done in advance must be either vague and fuzzy , or full of made-up shit. Planning is also an overhead that doesn't directly contribute to getting the job done. It can help you figure out very roughly what needs to be done, in what order, and how long it will take, but aside from some possible dead-end avoidance and better task-ordering, it doesn't really reduce the total amount of work required, it just adds more work. The more accurate and further into the future it tries to project, the more unknowns it has to predict, and the more work and BS it becomes.
You can expend more and more effort on more detailed/accurate/prophetic project planning, but there is a definite decline in the return-for-effort. From my experience with big waterfall Aerospace projects, accurate plans required accurate requirements and designs in advance to try to minimize the unknowns. History showed "the earlier in the waterfall process that errors are made, the more expensive they are to rectify", so more and more effort was expended on trying to get these right, till the planning/requirements/design was significantly more work than actually implementing it. And they still got it wrong.
"Agile" was a reaction to this; why waste too much effort on planning/design/etc in advance when it's going to be wrong anyway? Let's just iterate our way to the solution! Unfortunately, iteration is not always an optimal way to reach the solution, and you can't iterate your way out of a local-maxima. You can find yourself iterating down every dead-end-path to a sub-optimal solution that can't be iterated better any more, and requires a complete re-write from scratch.
So the sweet-spot is somewhere in the middle. The trick is have a rough plan all the way to the best-guess-end-goal, but don't waste too much effort on it. Beyond a minimum level of effort it will not finish the project any cheaper/faster/better, and will only give diminishing improvements to estimates of what the final cost/time will be. Know that it's just a best-guess for now, and update it as you go. Use it to inform your development iterations to allocate resources, avoid possible dead-ends, and choose a path that can reach the best solution.
Identifying critical paths is definitely one of the useful tools for doing this, but be aware of the effort-vs-return trade-offs in any kind of future projections for design projects, and that they are always varying degrees of wrong.
The CPM sounds a lot like a Gantt chart.