« If the customer isn’t there, did the commitment take place? | Main | The problem with percent-complete »
September 11, 2006
Observations from the field – if you’re going to be held accountable for making sure a conversation happens, then make sure the conversation happens.
One aspect of business that his often difficult to manage is making sure the difficult conversations that need to occur during a project actually do occur. The topics of these kinds of conversations can vary from delivery dates, budgets, team dynamics, etc. The underlying theme is that for a variety of reasons, no one wants to bring them up when the team is discussing the project. I think a lot of the difficulty comes directly from people’s desire to maximize pleasure and minimize pain. That is people tend to not address the problematic issues, or it they do, not address them directly. This causes issues when the problems, left unaddressed begin to affect the team’s or organization’s performance, or in a worst case scenario doom the project. Conversely, by focusing on the easier conversations a team might develop an overly optimistic view of a project and miss potential pitfalls along the way.
So how does one address this issue? I think it’s best done by stressing honesty and integrity. Frequently reminding the entire team that they collectively have the responsibility (and duty) to talk openly and honestly about their project and commitments, both good and bad, can go a long way to mitigate this potential time bomb. The way I like to describe it is; if you are responsible for making sure the team addresses the 500 lb. gorilla in the room, don’t mince words. At an iteration review meeting, or a similar time when it is appropriate, bring up the topic by stating ‘One of my roles is to make sure we talk about this 500 lb. gorilla. So I would like to do that now.’ Then begin stating your understandings, questions, etc. about the topic.
It can be uncomfortable to do this the first couple of times, but after a while it becomes matter of fact. With experience, one realizes that the fear and anxiety are usually associated with brining up difficult topics are a personal reaction that should be separated from the business needs associated with discussing the topic. Even if you never get over the butterflies, you start gaining the ability to address topics for their business value, not your personal value. That’s where the integrity and honesty come into play. If you have a high sense of integrity and honesty, then the personal aspects of difficult conversations become even more moot. Instead, your can rely on your sense of ethics to help bring the hard topics to the table.
Another aspect that helps mitigate this risk is to have a role, owned by someone on the team, within the project that makes sure these topics are brought up. Usually this responsibility falls to the project manager. If the project manager is unable to fulfill this responsibility, then someone else must take it over. Some options might be an outside executive, another person on the team with the role as the devil’s advocate or even a group of project manages that critique each other and then present their findings. It cannot be left orphaned, or the conversations will not occur.
Posted by martinolson on September 11, 2006 | Permalink
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341fba8753ef00d834e913cd69e2
Listed below are links to weblogs that reference Observations from the field – if you’re going to be held accountable for making sure a conversation happens, then make sure the conversation happens.:
Comments
Great post as usual.
But when you've got something big like that, is it better to have a separate meeting on it or just lay it out there at the outset because now that you've got everyone there, they all have to discuss it?
Posted by: Andrew | Sep 13, 2006 1:21:10 PM
Thanks for the kind words Andrew.
The way that I tend to deal with complex issues has a lot to do with the team, the project status and the issue. If the team is strong and dealing with the issue won't cause too much of a distraction from getting work done, I tend to deal with it as soon and as directly as possible. If not, I give some thought to how\when to bring up the topic. I don't want to spring a long meeting on anyone, nor do I want to begin a discussion if we don't have enough time to adequately address it.
If the issue is related to the work being done (I.E. we keep revisiting the architecture of the data layer with respect to testing), I might address the issue during the regular course of work by adding a task to the current iteration that says 'Review data layer discussions with respect to testing. Team conversation.' This puts it on the agenda for the iteration, in front of the entire team, and lets the conversation happen in the flow of work. It also lets me raise the importance of the meeting as soon next the next standing meeting.
If the issue is related to the process, I either wait for the iteration review or if it’s a significant problem, I schedule a meeting. In most cases I let the team know that we're going to discuss a difficult issue in the meeting by saying something at the end of the standing meeting like, 'Just a heads up, I'm going to send everyone an invitation to a meeting on Friday to discuss personal hygiene and workspace cleanliness.' I then leave the topic alone and defer the usual probes\questions like 'What prompted the need to meet about that?' with 'We'll talk about it on Friday.'
Posted by: Martin Olson | Sep 14, 2006 4:28:55 PM
The comments to this entry are closed.




