Comments on: You Can’t Manage or Improve what You Don’t Understand http://www.reformingprojectmanagement.com/2007/01/31/750/ The magazine for the project age Fri, 15 Apr 2011 17:20:14 -0700 http://wordpress.org/?v=2.8.5 hourly 1 By: Jim Kissane http://www.reformingprojectmanagement.com/2007/01/31/750/comment-page-1/#comment-12970 Jim Kissane Tue, 06 Feb 2007 11:14:51 +0000 http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12970 I agree with you and Greg completely. Wile you can complete a project you don't understand, you can't learn from it, or duplicate it in the future. Here's a thought to ponder - How do you gauge (assess) understanding? One of the leading areas of inquiry in my Workforce Development blog (<a href="http://kissaneasylum.typepad.com/workforce_development/" rel="nofollow">http://kissaneasylum.typepad.com/workforce_development/</a>) has to do with assessing skills. Is understanding a skill or a competency? How does one assess how a person (or for that matter - an organization) comes to "understand something? I agree with you and Greg completely. Wile you can complete a project you don’t understand, you can’t learn from it, or duplicate it in the future. Here’s a thought to ponder – How do you gauge (assess) understanding? One of the leading areas of inquiry in my Workforce Development blog (http://kissaneasylum.typepad.com/workforce_development/) has to do with assessing skills. Is understanding a skill or a competency? How does one assess how a person (or for that matter – an organization) comes to “understand something?

]]>
By: Joe Ely http://www.reformingprojectmanagement.com/2007/01/31/750/comment-page-1/#comment-12860 Joe Ely Thu, 01 Feb 2007 21:14:39 +0000 http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12860 Diana said it better than I did...let's not have metrics for metrics' sake. Hal, your steady encourgement for good conversations is very relevant as well. The metric, per se, can be akin to using a hammer instead of a wrench to tighten a bolt. Both tools are valid, but only in the right setting. Diana said it better than I did…let’s not have metrics for metrics’ sake.

Hal, your steady encourgement for good conversations is very relevant as well.

The metric, per se, can be akin to using a hammer instead of a wrench to tighten a bolt. Both tools are valid, but only in the right setting.

]]>
By: Diana Hutchinson http://www.reformingprojectmanagement.com/2007/01/31/750/comment-page-1/#comment-12853 Diana Hutchinson Thu, 01 Feb 2007 15:25:22 +0000 http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12853 The challenge for managers is to decide what is most important. Metrics for metrics sake are worse than meaningless as they drive busywork. Once we have a metric that is important, I agree it should drive another layer of investigation/discussion into what drives that metric. If we just measure something without thinking about how we can improve that metric, we may not get to the root causes and the best possible end result. The challenge for managers is to decide what is most important. Metrics for metrics sake are worse than meaningless as they drive busywork.
Once we have a metric that is important, I agree it should drive another layer of investigation/discussion into what drives that metric. If we just measure something without thinking about how we can improve that metric, we may not get to the root causes and the best possible end result.

]]>
By: Bob Wells http://www.reformingprojectmanagement.com/2007/01/31/750/comment-page-1/#comment-12852 Bob Wells Thu, 01 Feb 2007 15:25:11 +0000 http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12852 Aren't humans universally/norotiously transactional? I think Drucker is right to imply a measurement is always going to drive behavior, and Oglesby simply adds that if the resulting behavior is going to be termed "management," then there is a prerequisite of understanding. Aren’t humans universally/norotiously transactional? I think Drucker is right to imply a measurement is always going to drive behavior, and Oglesby simply adds that if the resulting behavior is going to be termed “management,” then there is a prerequisite of understanding.

]]>
By: Hal http://www.reformingprojectmanagement.com/2007/01/31/750/comment-page-1/#comment-12851 Hal Thu, 01 Feb 2007 14:54:28 +0000 http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12851 I find that 'understanding' comes from conversation. Being in conversation about measures can contribute to understanding what is going on. Posting measures in prominent locations close to the process being measured and proximate to the people who are involved in the process can lead to further understanding. Also, there's nothing better to avoid misunderstanding than annotating charts calling attention to special cases, changes in process, and anomalous events. I find that ‘understanding’ comes from conversation. Being in conversation about measures can contribute to understanding what is going on. Posting measures in prominent locations close to the process being measured and proximate to the people who are involved in the process can lead to further understanding.

Also, there’s nothing better to avoid misunderstanding than annotating charts calling attention to special cases, changes in process, and anomalous events.

]]>
By: Jim Dallas http://www.reformingprojectmanagement.com/2007/01/31/750/comment-page-1/#comment-12845 Jim Dallas Thu, 01 Feb 2007 12:50:49 +0000 http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12845 Hal, after reading Critical Chain a while back I spent some time thinking about "understanding as the real project constraint", rather than time. This resonated because a lot of a PM's real fears (losing key people, stakeholder relations, changing scope, appropriate levels of documentation, having the right architect) are to do with understanding, as are many methodology discussions (pair programming, iteration lengths etc.) Some of the interesting areas to explore are i) How much time to spend (over) communicating ? How/whether to verify whether communication is understood ii) How much time to spend on-boarding people/ preparing on-boarding material iii) What is the rhythm of understanding (e.g. daily wiki updates, weekly meetings, controlled document releases). What are the media (stories, specs, pictures). What is the culture iv) What is the 'cost' to the project to re-understand, or to absorb a change in understanding v) When & what should people not try to understand/ When should the whole team understand vi) What are the right 'chunks' to cut a project into - Who does this ? - can they be treated as black-box by the other teams ? How does a sub-team and a PM negotiate how they will be measured ? Didn't come up with any definitive answers, but it's a fun line of enquiry and a lot of good PM practices can be linked back to an 'understanding view' Last story - I interviewed a PM professor in the UK years ago while speccing a tool to give Sponsors detailed granular data on a project - his response was - 'the sponsors are usually accountants - if you give them detailed data about an area they don't understand, they will believe they do understand and just cause trouble' Cheers Jim (ps - love your work & Blind Men+ the elephant) Hal, after reading Critical Chain a while back I spent some time thinking about “understanding as the real project constraint”, rather than time. This resonated because a lot of a PM’s real fears (losing key people, stakeholder relations, changing scope, appropriate levels of documentation, having the right architect) are to do with understanding, as are many methodology discussions (pair programming, iteration lengths etc.)

Some of the interesting areas to explore are
i) How much time to spend (over) communicating ? How/whether to verify whether communication is understood
ii) How much time to spend on-boarding people/ preparing on-boarding material
iii) What is the rhythm of understanding (e.g. daily wiki updates, weekly meetings, controlled document releases). What are the media (stories, specs, pictures). What is the culture
iv) What is the ‘cost’ to the project to re-understand, or to absorb a change in understanding
v) When & what should people not try to understand/ When should the whole team understand
vi) What are the right ‘chunks’ to cut a project into – Who does this ? – can they be treated as black-box by the other teams ? How does a sub-team and a PM negotiate how they will be measured ?

Didn’t come up with any definitive answers, but it’s a fun line of enquiry and a lot of good PM practices can be linked back to an ‘understanding view’

Last story – I interviewed a PM professor in the UK years ago while speccing a tool to give Sponsors detailed granular data on a project – his response was – ‘the sponsors are usually accountants – if you give them detailed data about an area they don’t understand, they will believe they do understand and just cause trouble’

Cheers
Jim
(ps – love your work & Blind Men+ the elephant)

]]>
By: .Joe Ely http://www.reformingprojectmanagement.com/2007/01/31/750/comment-page-1/#comment-12842 .Joe Ely Thu, 01 Feb 2007 12:05:08 +0000 http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12842 Do we combine these two concepts, Hal, by saying "Only measure that which you understand." ?? If I understand something well (say my finished good inventory), I can measure it with confidence, knowing it shoud lead me to good actions. OTOH, if I don't understand something well (say a nagging yield problem) measuring it will only breed frustration; driving understanding, rather than merely measuring it, will more likely lead to implmentable solutions. Good post! Do we combine these two concepts, Hal, by saying “Only measure that which you understand.” ??

If I understand something well (say my finished good inventory), I can measure it with confidence, knowing it shoud lead me to good actions.

OTOH, if I don’t understand something well (say a nagging yield problem) measuring it will only breed frustration; driving understanding, rather than merely measuring it, will more likely lead to implmentable solutions.

Good post!

]]>