Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Categories: Lean
Over the years I have worked with teams on large systems projects in various industries. These have all tended to be managed with ‘traditional’ project management practices including a waterfall development cycle.
I have observed some key areas for improvement in these projects.
They tend to have a lot of waste.
This manifests as long delays between value-adding activities, rework, and local optimization instead of system-wide improvements. It also comes in the form of lots of busy work that doesn’t add any real value to the final products.
PMOs in general are a big contributor of non-value added busy work in my experience and in my opinion. They’ll spend months revising management plans, project processes on flowcharts, etc. -- usually in a detached way from the actual work that is being done and thus the actual value being created by the project teams.
We’ve all seen it -- a new process document comes down from on high and all the developers and other team members groan as they try to figure out how they can appear to be in compliance with this nonsensical new process and still manage to get some real work done.
The single most valuable resource on any project is the project team members. Big projects with waterfall development in particular tend to view people as ‘widgets’ or ‘resources’ that are interchangeable and simply get assigned tasks to get done.
People are treated as being outside the systems...people are seen as operators of processes instead of part of the processes themselves.
This is a big mistake. When we see people as operators of cogs in a machine simply producing output, we are leaving a great deal of untapped potential on the table. In my experience not only do people want to do good work they can be proud of, they want to contribute intellectually and creatively to the project as a whole. This includes ideas for improving product creation, management and development processes, and a whole host of other attributes that go on in any project.
Milestones and inertia drive project decisions and the focus tends to be on requirements verification, not validation. Delivery to specs is more important than ensuring the specs actually meet the needs and desires of the end users.
The tendency for this to happen increases as a function of time. The cost of making changes increases over time, and because most large projects with a waterfall approach neglect the importance of continuous learning and feedback as being integral to everything they do, many changes are discovered as necessary late in the project and then need to be negotiated down or completely away.
Of course as we all know, customers and end-users don’t really know exactly what they want until they see it. They have a vague idea in the beginning, and most large projects codify this vague understanding into requirements that are increasingly resistant to change as time goes on.
In the end, you have a product which may meet most of the end-user needs but you’ve probably had to negotiate and sacrifice those needs to avoid costly rework. Another phenomenon that is common to see is cutting corners on activities like testing and validation processes -- settling in the end for ‘good enough’.
There is usually little to no focus on, well, focus. Project team members and project managers are always trying to juggle ten tasks at once, and when things fall on the floor we put our fire-fighting hats on.
I know you’ve seen it just as often as I have -- the project has a handful of things in work simultaneously, and team members are bouncing back and forth. They start lots of things, but those items only get completed when management decides they are the ‘red alert’ of the week. This holds especially true for critical resources with a specialized skill. They get bombarded from all directions to help with this little thing, that little thing. They end up working from home at off hours to get their ‘real work’ done when they aren’t being disturbed every ten minutes.
I have observed some key areas for improvement in these projects.
They tend to have a lot of waste.
This manifests as long delays between value-adding activities, rework, and local optimization instead of system-wide improvements. It also comes in the form of lots of busy work that doesn’t add any real value to the final products.
PMOs in general are a big contributor of non-value added busy work in my experience and in my opinion. They’ll spend months revising management plans, project processes on flowcharts, etc. -- usually in a detached way from the actual work that is being done and thus the actual value being created by the project teams.
We’ve all seen it -- a new process document comes down from on high and all the developers and other team members groan as they try to figure out how they can appear to be in compliance with this nonsensical new process and still manage to get some real work done.
They tend to undervalue the creativity of project team members.
The single most valuable resource on any project is the project team members. Big projects with waterfall development in particular tend to view people as ‘widgets’ or ‘resources’ that are interchangeable and simply get assigned tasks to get done.
People are treated as being outside the systems...people are seen as operators of processes instead of part of the processes themselves.
This is a big mistake. When we see people as operators of cogs in a machine simply producing output, we are leaving a great deal of untapped potential on the table. In my experience not only do people want to do good work they can be proud of, they want to contribute intellectually and creatively to the project as a whole. This includes ideas for improving product creation, management and development processes, and a whole host of other attributes that go on in any project.
They demand cutting corners.
Milestones and inertia drive project decisions and the focus tends to be on requirements verification, not validation. Delivery to specs is more important than ensuring the specs actually meet the needs and desires of the end users.
The tendency for this to happen increases as a function of time. The cost of making changes increases over time, and because most large projects with a waterfall approach neglect the importance of continuous learning and feedback as being integral to everything they do, many changes are discovered as necessary late in the project and then need to be negotiated down or completely away.
Of course as we all know, customers and end-users don’t really know exactly what they want until they see it. They have a vague idea in the beginning, and most large projects codify this vague understanding into requirements that are increasingly resistant to change as time goes on.
In the end, you have a product which may meet most of the end-user needs but you’ve probably had to negotiate and sacrifice those needs to avoid costly rework. Another phenomenon that is common to see is cutting corners on activities like testing and validation processes -- settling in the end for ‘good enough’.
They force multitasking on the project teams.
There is usually little to no focus on, well, focus. Project team members and project managers are always trying to juggle ten tasks at once, and when things fall on the floor we put our fire-fighting hats on.
I know you’ve seen it just as often as I have -- the project has a handful of things in work simultaneously, and team members are bouncing back and forth. They start lots of things, but those items only get completed when management decides they are the ‘red alert’ of the week. This holds especially true for critical resources with a specialized skill. They get bombarded from all directions to help with this little thing, that little thing. They end up working from home at off hours to get their ‘real work’ done when they aren’t being disturbed every ten minutes.
About This Series
This series is on the topic of making big projects lean. I am going to use my own experiences working on a large multi-organization and multi-team project, however many of these concepts can be scaled down to smaller projects as well.
The goal here is to eliminate waste as much as possible, having respect for people built-in to the system and management, limit work in progress (WIP), and shorten cycle times for learning and adapting your products and processes.
So buckle your safety belt, and let’s begin.
In This Series:
Posted on: December 26, 2011 08:57 PM |
Permalink