Comments on: Understanding Project Constraints http://www.reformingprojectmanagement.com/2007/02/04/753/ The magazine for the project age Wed, 08 Oct 2008 08:24:50 +0000 http://wordpress.org/?v=2.0.5 by: Hal http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12964 Tue, 06 Feb 2007 02:11:19 +0000 http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12964 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! 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!

]]> by: Joe Ely http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12958 Mon, 05 Feb 2007 20:19:36 +0000 http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12958 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?? 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??

]]> by: Diana Hutchinson http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12955 Mon, 05 Feb 2007 18:03:56 +0000 http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12955 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. 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.

]]> by: Greg Howell http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12950 Mon, 05 Feb 2007 14:56:21 +0000 http://www.reformingprojectmanagement.com/2007/02/04/753/#comment-12950 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 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

]]>