> but we should not have to self-manage our own productivity in imperfect systems laid atop programmer thinking to simply do our work.
And
> And we can’t expect each user to be both a maker and a self-manager, especially with the imperfect tools on the market.
Why can't we expect these things? Lots of life seems to expect this of me.
Project management isn't about tools or even process. It's about doing the hard work of analyzing, defining, and organizing the next batch of work. Then do the work. Rinse and repeat. This gets harder with more people because alignment and communication takes more time and effort.
The best situations I've seen were always because one or two people took the brunt of that thankless work. The tools and process were merely supporting that work.
True. It took me years to realize that the most difficult thing is actually to systematically derive what to do in which order and concurrence, and that in any decently complex project, systems engineering (an art and science apparently long forgotten) methods are the only way to derive that in a sufficiently reliable way. The result is - no wonder - not just a gantt chart, but an n-dimensional model with multiple levels of detail. The PMI writings just tell you that you e.g. have to create a WBS, but they leave you all alone with how to derive something like this systematically. Accordingly, the many PM tools seem helplessly naive to me, where some computer scientists have simply built something that corresponds to the outward appearance of what they assume under PM.
I worked for many years on large, complex government projects and eventually started building prototypes for tools that would be useful (e.g. https://github.com/rochus-keller/FlowLine2 or https://github.com/rochus-keller/WorkTree); but you would have to invest a lot more development resources, and whether people would understand the tools and their usefulness (so there would be a market) is questionable.
Both. There is (or was) an established Systems Engineering body of knowledge with methods how to do systems analysis and in parallel synthesize the system and process architecture. But there were actually no decent tools to support it; most tools were actually just drawing tools or expensive text editors (e.g. DOORS). And the few PM tools (e.g. Microsoft Project) stopped working properly when there were thousands of tasks. So we had to somehow cope ourselves with the immense, permanetly changing amount of information. Today there are much more tools and possiblities to implement tools for large projects, but I have the impression that in the last ten years many methods have been forgotten or watered down beyond recognition.
4 comments
[ 2.6 ms ] story [ 81.2 ms ] thread> but we should not have to self-manage our own productivity in imperfect systems laid atop programmer thinking to simply do our work.
And
> And we can’t expect each user to be both a maker and a self-manager, especially with the imperfect tools on the market.
Why can't we expect these things? Lots of life seems to expect this of me.
Project management isn't about tools or even process. It's about doing the hard work of analyzing, defining, and organizing the next batch of work. Then do the work. Rinse and repeat. This gets harder with more people because alignment and communication takes more time and effort.
The best situations I've seen were always because one or two people took the brunt of that thankless work. The tools and process were merely supporting that work.
I worked for many years on large, complex government projects and eventually started building prototypes for tools that would be useful (e.g. https://github.com/rochus-keller/FlowLine2 or https://github.com/rochus-keller/WorkTree); but you would have to invest a lot more development resources, and whether people would understand the tools and their usefulness (so there would be a market) is questionable.