Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Categories: Lean
Management of projects is an important role, however in many cases it is overrated.
We project managers tend to exaggerate our discipline to the extent that observers may conclude we feel management is the goal of projects. That our role is the most important one.
How arrogant.
Unfortunately, this leads to several troublesome trends I’ve seen time and time again on projects of all kinds. It creates roadblocks to progress which are codified and made a part of the project organization. And yet we think we are helping our teams get things done.
Planning
Progressive elaboration can be utilized to great benefit even within a waterfall approach to managing projects, but it doesn’t seem to happen well as often as it should. Even within ‘agile’ projects managers will approach planning with a hubris allowing them to believe their crystal ball magically allows for detailed plans way out into the future.The world doesn’t operate that way, unless you are cranking out very similar products over and over again, for the same end-users.
And yet large projects commonly go through a design phase in which requirements are elicited, detailed Work Breakdown Structures are drawn up, rather detailed designs are created, etc. In aerospace, we have a several planning milestones as a standard process way before teams actually start doing real work:
- System Requirements Review (SRR)
- Preliminary Design Review (PDR)
- Critical Design Review (CDR)
This process can take a long time (years in some cases) and only afterward do development teams start working on releases of the systems. Each of these releases are generally fairly large, primarily (in my opinion) because of the high overhead and coordination costs involved due to what is mostly waste; busy work that does not add value to the end products.
Months and years can pass between the time requirements are elicited, designs are made, and something is actually implemented. And yet managers are surprised and disappointed when designs change before and during the course of implementation.
Change Management
Changes happen constantly on projects. Going back to the arrogance of thinking we can successfully plan in detail way in advance, many managers see change as a bad thing. This includes project managers, sponsors, executives, etc.What is typical about change management implementations, especially on large projects?
- Long cycle times - months to make changes
- Painful change process - perhaps subliminally to prevent change requests?
- Lots of waste - many times, the change process itself takes up more time and effort than the actual implementation of the change request -- but not because of the value-added activity (evaluation and approval/rejection of the change request), most of the time is wasted in cycle time delays, CYA and nitty-gritty impact assessments, and other busy work.
Configuration Management
Primarily, the problem here is confusing configuration management with change management. Many organizations see this as the same activity, the same discipline. It’s not.Configuration is about controlling what version of a product is deployed in a specific environment. This applies to documentation, code, COTS packages, hardware, and anything else that is part of the products being produced or the tools for getting the project done.
The same criticisms of change management apply to configuration management as well on large projects. Many times the method for configuring an item in a baseline or in a specific environment (a specific test environment for example) is so long and painful that we tend to like large releases so we don’t have to deal with configuration management that often.
Risk Management
Risk management is important, and having a system in place to encourage the identification and proactive tackling of risks is critical -- especially on large projects. However just as noted with the other management disciplines, on large projects risk management tends to be a behemoth time-suck in which more time is spent over the course of months on valueless pieces of busywork that could have been better spent actually mitigating or avoiding the negative risk.We spend months on templates, automation, fancy prioritization schemes, etc. When it comes down to it, all you need is to define the risk in a sentence, figure out how to address it if it’s worth it, and go do it.
1. Define: [Given] {condition} [there is a possibility] {risk event} [resulting in] {consequence}
2. Decide: Mitigate/Accept/Avoid/Exploit -- How?
3. Take Action
Know Your Place, Managers
These management practices and more exist for the project team and stakeholders, not the other way around. They are not ends in and of themselves, they are part of the means to the end only. Especially on large projects, these disciplines can sprout little fiefdoms whereby leads or managers over these areas believe the project exists for them and not the other way around.
This leads to initiatives to create a slew of standardized templates, convoluted processes that try to manage every exception to the rule, and a separation from reality as team members focused on these management areas disassociate themselves with the people doing the real work of producing products for the end users.
In my experience, if you view your role as a manager to facilitate the ability of the people involved with actual product creation (developers, end users, team members), it’s much easier to contribute real value to the team.
In This Series:
Posted on: December 27, 2011 09:16 AM |
Permalink