The concern about too-detailed project management is correct. In my consulting career we helped a client whose products were late, though the software system said everything was on schedule. The individual small steps had names like PT133A. Employees time cards logged the time for each step, feeding the project management reporting system. A helpful programmer had written a program that helped confused employees fill out their time cards with the project steps they SHOULD HAVE been working on, not reality.
Defined process can help diffuse expert skill wider among less experienced persons while they learn. But there is a limit to what can be conveyed through description. The simple concept that recording and confirming more detailed level of activity will improve performance is flawed, because each written task requires judgment as to the priority and emphasis, PT133A can and will be pencil whipped and eventually software created to automate the worthless pretend activity. As projects, operations, services and systems become more complex there’s a critical need to engineer and plan, including the communications among knowledge domains needed at each point. Long ago this was impossible without software and improving software improves performance and ability to operate more complex systems. But also the inherent vectors of degrading operation effectiveness such as proceduralization and silos need to learned and practices of periodic critical renewal developed. There’s an ethical component too the socialization of youth toward discovery, challenge and effort, being thrilled with engaging and surmounting complexity and diverse domains and the intense focus, effort, collaboration and velocity that comes with it. There’s a balance of gray beards and systems engineering to succeed in today’s challenges.
What an impressive essay. Not only does it 'ring true' generally, but--more importantly--it accords with what I heard from civil (and other) engineers working in the Canadian nuclear (energy) sector from the late 1960's to early 1990s. Thank you so much for this, and for the links to Petrovnik's book, etc.
The concern about too-detailed project management is correct. In my consulting career we helped a client whose products were late, though the software system said everything was on schedule. The individual small steps had names like PT133A. Employees time cards logged the time for each step, feeding the project management reporting system. A helpful programmer had written a program that helped confused employees fill out their time cards with the project steps they SHOULD HAVE been working on, not reality.
Defined process can help diffuse expert skill wider among less experienced persons while they learn. But there is a limit to what can be conveyed through description. The simple concept that recording and confirming more detailed level of activity will improve performance is flawed, because each written task requires judgment as to the priority and emphasis, PT133A can and will be pencil whipped and eventually software created to automate the worthless pretend activity. As projects, operations, services and systems become more complex there’s a critical need to engineer and plan, including the communications among knowledge domains needed at each point. Long ago this was impossible without software and improving software improves performance and ability to operate more complex systems. But also the inherent vectors of degrading operation effectiveness such as proceduralization and silos need to learned and practices of periodic critical renewal developed. There’s an ethical component too the socialization of youth toward discovery, challenge and effort, being thrilled with engaging and surmounting complexity and diverse domains and the intense focus, effort, collaboration and velocity that comes with it. There’s a balance of gray beards and systems engineering to succeed in today’s challenges.
What an impressive essay. Not only does it 'ring true' generally, but--more importantly--it accords with what I heard from civil (and other) engineers working in the Canadian nuclear (energy) sector from the late 1960's to early 1990s. Thank you so much for this, and for the links to Petrovnik's book, etc.
Can't find an option to edit the errors (misspelled Petrunik) and infelicities of my comment. But the admiration and gratitude come through, I hope.