Understanding Project Constraints
February 4th, 2007 by HalOver the years I've written quite a bit about constraints. In the process environment there are physical constraints which are easy to spot. You'll see work piling up in front of the constraint. Projects are always constrained. We think that the big constraint is time. The project promise date (deadline) provides a limitation on how much can be accomplished. Most of us are familiar with physical constraints. Getting more done is limited in some way by how much capacity one can bring to the situation. It can appear that physical constraints are the only constraints. In other postings I've written about policy constraints and paradigm constraints. Perhaps I'll revisit them. Until last Friday, I hadn't considered that there was another class of constraints. Jim Dallas changed my mind.
Might increasing shared understanding lead to increased project throughput?
Jim left a comment to my posting You Can't Manage or Improve what You Don't Understand. He said, "Understanding (is) the real project constraint." That one line set me back in my chair. He argues that a project team's throughput is limited by what they understand. Jim is not saying "what they know how to do." That would be a physical constraint. He's saying that they are limited by what they understand about the project, the concerns of the clients, the interests of others on the team, and the interests of the firm. These are just starters. Jim went on to speculate on what we might do to increase shared understanding.
I think he's on to something…something big. What do you think?
Related Posts
- PPC Data Surprises Leads to Creation of New Index The Last Planner System® (LPS) has been used in Brazil since early 1990s. The researchers have data on over 130 p...
- Physical Project Constraints The first in a five-part series on applying the Theory of Constraints in the project setting. Projects of all types g...
- Customers, Promises, and TOC Final remarks on the series on Theory of Constraints Frank, Joe, and I had fun blogging collaboratively on the Theory o...
- 5 Practices for Managing (Constrained) Projects Successfully Projects are always constrained. Accept it. Now what? (Day 5 in the TOC series.) We've discussed three types of cons...
- Look-Ahead Planning Last week I proposed a set of meeting protocols for conducting projects on a lean basis. These protocols are used wit...
February 5th, 2007 at 9:56 am
I think my Special Education Professor brother, Ken, first explained to me three different approaches to intelligence and its measurement. 1. What you know. 2. How well you can reason, think. 3. How fast you can learn. The first two are typical in the US but rarely the third. Now I am not sure I have this right but I like the idea of the focus on rapid learning and how to develop this in project organizations. G
February 5th, 2007 at 1:03 pm
I agree Jim is onto something unexpected and thought-provoking.
As project managers we try to define the scope and get the customers to explain what they need, but often we are left to make some educated guesses to meet the customer schedule requirement. This isn’t always due to lack of communication — often the customers don’t really know themselves what they need. That is one point of the agile development process — to give the customer a quick prototype to get feedback on whether you are going the right direction. It’s usually easier for customers to give you feedback on what they don’t want than what they want, and a strawman or prototype helps enable that communication process.
And then there is the understanding within the team. That is much more within our control as project managers, but that’s not to say it’s easy, either. Voicing assumptions, asking people to explain their thoughts, documenting my assumptions and sharing those pictures and words with the team for are ways I’ve worked on this area.
I’ve been reading a book, “Made to Stick: Why Some Ideas Survive and Others Die” by Chip Heath and Dan Heath. One idea in this book is the Curse of Knowledge. Once you have a certain knowledge, you can’t not have the knowledge, and it’s hard to remember that not everyone else has that same knowledge. We tend to communicate as though others have at least some portion of the knowledge we have, when in reality, they may be thinking of something totally different.
February 5th, 2007 at 3:19 pm
A useful idea, Hal.
And if this is the constraint, do we not then utilize Godratt’s sequence to exploit, subordinate, elevate and repeat? To better deal with project understanding??
February 5th, 2007 at 9:11 pm
Continuing with Joe’s question, if understanding is limiting what the team can do, then we exploit what understanding we have; we subordinate everything else that calls on that understanding; we find some way to increase the understanding that is present; and then we repeat the process starting with that higher level understanding.
Seems too mechanical for me. I once had the Goldratt folks in to help us identify the constraint for our company. They conducted a workshop/working session with about 16 people from our company. The Goldratt leaders kep looking (fishing) for physical constraints. But my team wouldn’t let them be just look at that. All had read 2 or more Goldratt books. They knew enough to look for policy and paradigm constraints. In the end the team identified the organization’s constraint. It was the availability of leadership. The Goldratt people didn’t know what to do.
I think we have a similar situation. If understanding is the constraint, is it a result of policy or paradigm constraints? If so, then what can we do about either policies or paradigms to disappear (evaporate) the condition? Maybe, as Greg points out, it’s not a result of the policies or paradigms. Rather, it is associated with no policy or paradigm. In other words, as project leaders we can establish a goal for continuous learning and couple that with appropriate supporting policies. Or maybe I’m being too literal with this constraints stuff!