Comments for Ensemble http://ensemblemc.com A Commitment-Based Way of Working Sat, 12 May 2012 17:10:10 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Managing By Commitment – Some Key Distinctions by Timm J. Esque http://ensemblemc.com/2011/10/13/managing-by-commitment-some-key-distinctions-2/#comment-194 Timm J. Esque Sat, 12 May 2012 17:10:10 +0000 http://brightmonk.com/ensemble/?p=1202#comment-194 Thanks for the comment Reza. I think from your comment, we are in agreement that teams and organizations should be managing to goals proactively and with discipline at all times, not just when a key goal is in jeopardy. re: CBPM and MBO... CBPM is focused on projects while MBO was designed to manage the whole organization. One of the limitations of MBO is it has a completely vertical orientation - start at the top and articulate goals down through the organization. So much of what we produce for customers has a horizontal orientation - deliverables are passed from one group to another with value increasing along the way until you have a finished output. We recommend start at the top, get down to the level of key intiatives in the organizations (e.g. new products, key processes, system improvements, etc.) and then start mapping goals horizontally by showing what different teams will deliver to each other (The teams need to create these maps of course). Also, when I was at Intel participating in the MBO or iMBO's as they called it, we were encouraged to have stretch objectives. This may be fine for 6-12 month forecasting, but in the short term we strongly recommend operating from true commitments. This means we are putting our personal reputation on the line and saying we promise to deliver x items by y date. When you have a discipline of turning longer term goals into short term personal commitments you create a culture of accountability. With CBPM we are teaching project managers to create this culture (really a local "team climate") on each project. This is how to truly prevent surprises, on the critical projects, and the others as well. These days, PMs rarely have formal authority over project team members, so they better be able to create accountability between team members. We teach how to do that. HOpe that helps. Thanks for asking. See our website or contact me for more dialogue. Timm Thanks for the comment Reza.
I think from your comment, we are in agreement that teams and organizations should be managing to goals proactively and with discipline at all times, not just when a key goal is in jeopardy.
re: CBPM and MBO…
CBPM is focused on projects while MBO was designed to manage the whole organization. One of the limitations of MBO is it has a completely vertical orientation – start at the top and articulate goals down through the organization. So much of what we produce for customers has a horizontal orientation – deliverables are passed from one group to another with value increasing along the way until you have a finished output. We recommend start at the top, get down to the level of key intiatives in the organizations (e.g. new products, key processes, system improvements, etc.) and then start mapping goals horizontally by showing what different teams will deliver to each other (The teams need to create these maps of course).
Also, when I was at Intel participating in the MBO or iMBO’s as they called it, we were encouraged to have stretch objectives. This may be fine for 6-12 month forecasting, but in the short term we strongly recommend operating from true commitments. This means we are putting our personal reputation on the line and saying we promise to deliver x items by y date. When you have a discipline of turning longer term goals into short term personal commitments you create a culture of accountability. With CBPM we are teaching project managers to create this culture (really a local “team climate”) on each project. This is how to truly prevent surprises, on the critical projects, and the others as well. These days, PMs rarely have formal authority over project team members, so they better be able to create accountability between team members. We teach how to do that.
HOpe that helps. Thanks for asking. See our website or contact me for more dialogue.
Timm

]]> Comment on Managing By Commitment – Some Key Distinctions by Reza Sarraf http://ensemblemc.com/2011/10/13/managing-by-commitment-some-key-distinctions-2/#comment-192 Reza Sarraf Wed, 09 May 2012 18:00:42 +0000 http://brightmonk.com/ensemble/?p=1202#comment-192 Sorry; meant to say MBO (not BMO) Sorry; meant to say MBO (not BMO)

]]> Comment on Managing By Commitment – Some Key Distinctions by Reza Sarraf http://ensemblemc.com/2011/10/13/managing-by-commitment-some-key-distinctions-2/#comment-191 Reza Sarraf Wed, 09 May 2012 17:57:20 +0000 http://brightmonk.com/ensemble/?p=1202#comment-191 Hello Tim: Thanks for your efforts in advance. with respect to item 3, managing breakdowns vs recovery planning; Based on my past experience at Intel, we used to call this Task Force mode, and that is when a failure or lack of delivery is becoming a show stopper and is having a major impact on goals and objectives. under this mode actions are taken a lot more seriously and check points are more frequent. In reality, given the priority of each task/project, why not run all projects with the Task Force philosophy. At the end of the day, we all are weighing the priorities of tasks on hand and allocating resources accordingly. Best Regards, Reza How is CBPM different than BMO ? Regards, Reza Hello Tim:
Thanks for your efforts in advance.
with respect to item 3, managing breakdowns vs recovery planning;
Based on my past experience at Intel, we used to call this Task Force mode, and that is when a failure or lack of delivery is becoming a show stopper and is having a major impact on goals and objectives. under this mode actions are taken a lot more seriously and check points are more frequent.

In reality, given the priority of each task/project, why not run all projects with the Task Force philosophy. At the end of the day, we all are weighing the priorities of tasks on hand and allocating resources accordingly.

Best Regards,
Reza

How is CBPM different than BMO ?

Regards,
Reza

]]> Comment on Our Talks by Timm J. Esque http://ensemblemc.com/resources/our-talks/#comment-162 Timm J. Esque Tue, 21 Feb 2012 16:31:01 +0000 http://brightmonk.com/ensemble/?page_id=81#comment-162 There is a concept in Taoism called Wu Wei - sometimes translated as action through inaction. I don't think pushing is consistent with this concept. When we feel the need to push others, we have run out of ideas to reason with them. Team members on a project generally want the project to succeed as much as the PM. They need to understand what they specifically need to produce to support success and who is depending on them. They need to know that every team member is holding the other's accountable, not just the PM. When the PM puts these things in place, pushing is not necessary (and doesn't help anyway). The closest productive thing to pushing that PMs can do is clearly communicate a challenging and worthy project goal, and then follow through on disciplined CBPM practices. Timm There is a concept in Taoism called Wu Wei – sometimes translated as action through inaction. I don’t think pushing is consistent with this concept. When we feel the need to push others, we have run out of ideas to reason with them.
Team members on a project generally want the project to succeed as much as the PM. They need to understand what they specifically need to produce to support success and who is depending on them. They need to know that every team member is holding the other’s accountable, not just the PM. When the PM puts these things in place, pushing is not necessary (and doesn’t help anyway).
The closest productive thing to pushing that PMs can do is clearly communicate a challenging and worthy project goal, and then follow through on disciplined CBPM practices.
Timm

]]> Comment on The Hardest Lesson to Learn? by Clinton http://ensemblemc.com/2012/01/04/the-hardest-lesson-to-learn/#comment-134 Clinton Thu, 09 Feb 2012 06:02:37 +0000 http://ensemblemc.com/?p=1736#comment-134 kanban in Lean is more alctrauecy described as a tool or technique rather than an overall process or system. So it’s kind of confusing to compare kanban with Scrum.I like the idea of focusing on improving rather than being Agile, Lean, etc. kanban in Lean is more alctrauecy described as a tool or technique rather than an overall process or system. So it’s kind of confusing to compare kanban with Scrum.I like the idea of focusing on improving rather than being Agile, Lean, etc.

]]> Comment on Our Talks by Yudith http://ensemblemc.com/resources/our-talks/#comment-133 Yudith Thu, 09 Feb 2012 05:01:58 +0000 http://brightmonk.com/ensemble/?page_id=81#comment-133 I like the blog - thank you for psoting. But I have a question about pushing as mentioned in the Tao and in your post: if the PM does not push - how do you expedite when the schedule slips? Does not pushing mean that you just flow like water and try to see if there are alternatives to getting the work done within the same constraints - a change in words (which can result in a completely different atmosphere)?Thanks againTryllid I like the blog – thank you for psoting. But I have a question about pushing as mentioned in the Tao and in your post: if the PM does not push – how do you expedite when the schedule slips? Does not pushing mean that you just flow like water and try to see if there are alternatives to getting the work done within the same constraints – a change in words (which can result in a completely different atmosphere)?Thanks againTryllid

]]> Comment on Team Building and Ensuring Goals are Met : Same Thing by Birgit Zacher Hanson http://ensemblemc.com/2012/01/23/team-building-and-ensuring-goals-are-met-same-thing/#comment-111 Birgit Zacher Hanson Tue, 31 Jan 2012 21:33:26 +0000 http://ensemblemc.com/?p=1812#comment-111 The dysfunction on most of the teams I have witnessed is that people do not see and thus step over the first two layers in this model. They are so focused on getting the task done, the deadlines met and keeping their clients happy that they fail to develop an approach to systematically build trust and manage commitments. Unfortunately, the lack of trust goes hand in hand with the withholding of important information (including the internal conversations around willingness and capacity.) Without trust people wont' open up fully, won't renegotiate powerfully and the silence is often misinterpreted as buy-in leading to future and costly breakdowns. This book lays the foundation for commitment-based management. Thanks for the review and reminder of such pertinent information. The dysfunction on most of the teams I have witnessed is that people do not see and thus step over the first two layers in this model. They are so focused on getting the task done, the deadlines met and keeping their clients happy that they fail to develop an approach to systematically build trust and manage commitments.

Unfortunately, the lack of trust goes hand in hand with the withholding of important information (including the internal conversations around willingness and capacity.)

Without trust people wont’ open up fully, won’t renegotiate powerfully and the silence is often misinterpreted as buy-in leading to future and costly breakdowns. This book lays the foundation for commitment-based management. Thanks for the review and reminder of such pertinent information.

]]> Comment on Questions from Commitment-Based Project Management (CBPM) Practitioners by Timm Esque http://ensemblemc.com/2011/11/16/questions-from-commitment-based-project-management-cbpm-practitioners/#comment-53 Timm Esque Wed, 14 Dec 2011 19:01:04 +0000 http://ensemblemc.com/?p=1625#comment-53 Anil is referring to the simple CBPM rule that a deliverable is not considered Done until the downstream Users of that deliverable say that they received the deliverable and it meets pre-defined quality specifications. The other simple rule that applies here is that quality for a deliverable should always be agreed to (between owners and users) before a commit date is put on that deliverable. If I was concerned that my Users were letting the Owners off too easy, I would start asking some probing questions about the quality criteria in the review meetings. E.g. what were the agreed to criteria? And you are saying you are satisfied that each of them has been met? I would do this for all deliverables for awhile, and then just on a random sampling basis after awhile. These are some generic answers to subtle issues. It is always a good idea to do a lot of listening before jumping to conclusions about what is making it difficult for someone to get on board. What are they committed to? What is missing? What can be done to help them choose to tryout CBPM as it is designed? Thanks for the questions. Anil is referring to the simple CBPM rule that a deliverable is not considered Done until the downstream Users of that deliverable say that they received the deliverable and it meets pre-defined quality specifications.
The other simple rule that applies here is that quality for a deliverable should always be agreed to (between owners and users) before a commit date is put on that deliverable. If I was concerned that my Users were letting the Owners off too easy, I would start asking some probing questions about the quality criteria in the review meetings. E.g. what were the agreed to criteria? And you are saying you are satisfied that each of them has been met? I would do this for all deliverables for awhile, and then just on a random sampling basis after awhile.
These are some generic answers to subtle issues. It is always a good idea to do a lot of listening before jumping to conclusions about what is making it difficult for someone to get on board. What are they committed to? What is missing? What can be done to help them choose to tryout CBPM as it is designed?
Thanks for the questions.

]]> Comment on Questions from Commitment-Based Project Management (CBPM) Practitioners by Timm Esque http://ensemblemc.com/2011/11/16/questions-from-commitment-based-project-management-cbpm-practitioners/#comment-52 Timm Esque Wed, 14 Dec 2011 18:41:44 +0000 http://ensemblemc.com/?p=1625#comment-52 Thanks for getting this started Jim. Going to take a while to build up the community, so in the interim will share my thoughts on your specific question. Still interested in how others would/have approached this situation. Our first advice when someone is resisting to make weekly commitments is to ask what they can commit to. What are they working on now and what can they commit to have done end of tomorrow or even end of today. It can help to discuss how making commitments gives a person more power to say "No" to some of those requests that pop up. There is also a common mis-perception that commitments are written in stone. In fact, a principle of managing with commitments is that commitments are negotiable. There should be no stigma attached to speaking up as soon as a commitment seems to be in jeopardy and negotiating a modified commitment in alignment with the team's goals. This sometimes needs to be over-communicated, especially when people feel they were unfairly treated in the past (could have happened in another org or before you got there). Obviously, a habit of renegotiation commitments all the time is not very productive, but our experience is when people start managing commits, they get better at meeting them. Peer pressure is also helpful especially in getting started managing commitments. It is a lot harder for one person to say it is impossible to operate from commitments, when their colleagues are making and meeting commitments in their regular team meetings. Other thoughts? Thanks for getting this started Jim. Going to take a while to build up the community, so in the interim will share my thoughts on your specific question. Still interested in how others would/have approached this situation.

Our first advice when someone is resisting to make weekly commitments is to ask what they can commit to. What are they working on now and what can they commit to have done end of tomorrow or even end of today. It can help to discuss how making commitments gives a person more power to say “No” to some of those requests that pop up.
There is also a common mis-perception that commitments are written in stone. In fact, a principle of managing with commitments is that commitments are negotiable. There should be no stigma attached to speaking up as soon as a commitment seems to be in jeopardy and negotiating a modified commitment in alignment with the team’s goals. This sometimes needs to be over-communicated, especially when people feel they were unfairly treated in the past (could have happened in another org or before you got there). Obviously, a habit of renegotiation commitments all the time is not very productive, but our experience is when people start managing commits, they get better at meeting them.
Peer pressure is also helpful especially in getting started managing commitments. It is a lot harder for one person to say it is impossible to operate from commitments, when their colleagues are making and meeting commitments in their regular team meetings.
Other thoughts?

]]>