I was sitting in a series of meetings yesterday and getting frustrated with the extent to which I was failing to understand what was being discussed -- the mix of 5,000 acronyms and highly technical engineering "stuff" got to me [and pausing the discussions to ask a question was not an option]. So I switched gear and instead of trying to understand the meaning of what was being said, I tried to focus on the bigger picture. Who are the people in the room? Why are they there? What is the broader purpose of the meeting? What is really going on?
I don't think I did more than scratch the surface in terms of understanding what was going on but at least my level of frustration was lowered to a manageable level. Getting out of the meeting was obviously another option but I had been asked/told to sit through it and so I was under pressure to actually try my best to make the most of it.
So, here are some reflections which have nothing to do with what was actually said during the meeting:
1. If I don't understand something, how many other people in the room are not understanding it?
2. If I am there because I have been told to be there and I don't have any incentive to ask for clarifications or actually say anything in the meeting, how many people in the room are in the same boat?
3. The only time I've ever experienced writer's block is when I am sitting in a meeting attempting to take note, my brain is unable to process what is being said and I have nothing to write except "I don't get this".
4. As soon as I realized I was not going to get much out of the meeting, I started to think about how many other things -- more productive things -- I could be doing if I wasn't stuck in this meeting. That made it even more difficult to concentrate on what was being said.
5. At one point, a project I knew something about was being discussed. Suddenly, some of what was being said made sense. Simply put, I had some context for that discussion. I had no point of reference for the other issues being discussed and therefore no way of making connections to any prior knowledge. The people in the room (those who understood what was being discussed) had a long history of communicating around the issues being discussed.
6. Let's imagine a new staff in the room who happens to have technical expertise in the area being discussed. How much more than me is he/she understanding? Quite a lot, but without the prior conversations and context knowledge, he/she isn't grasping everything either.
Lesson: When trying to communicate something to a person you don't know very well, be aware of the fact that the person doesn't necessarily share your frame of reference and might have very little incentives to tell you that they're not grasping what you're talking about....
Thursday, September 11, 2008
Thursday, September 04, 2008
Case Studies
The Office of the Chief Knowledge Officer (OCKO) at NASA's Goddard Space Flight Center - where I work - makes extensive use of case studies to facilitate knowledge sharing across missions. These are case studies developed by the OCKO team based on real missions, including some that have not yet launched. The case studies tend to focus on project management rather than technical issues. The technologies and engineering challenges may be complex, and the science questions being asked may be difficult to understand for the average person, but the project management challenges are not that simple either.
The case studies have also been initially written with a specific audience in mind (project managers and their deputies) and with a specific purpose in mind (for use in the context of facilitated workshops). A "case" can be presented in different versions depending on the time allocated in the workshop and the purpose of the use of that case. For example, a short version of a case (one page) can be used as a teaser to introduce a group to case studies before they are presented with a longer case.
In the past few days, I've also come to realize that the younger generation of engineers and future NASA project managers would also greatly benefit from these case studies. Whereas the discussion question for groups of project managers tends to be "What would you do as the PM for this project?", the discussion question for future PMs needs to be adjusted to their current roles. I'm not sure whether the entire case study would need to be rewritten. I've also come to realize that there are dangers in rewriting case studies. The more they are rewritten to suit a particular purpose, the greater the danger of straying away from the real story. The best approach might be to keep the case unchanged but to adjust the facilitation and trigger question that starts the discussions around the case.
The case studies have also been initially written with a specific audience in mind (project managers and their deputies) and with a specific purpose in mind (for use in the context of facilitated workshops). A "case" can be presented in different versions depending on the time allocated in the workshop and the purpose of the use of that case. For example, a short version of a case (one page) can be used as a teaser to introduce a group to case studies before they are presented with a longer case.
In the past few days, I've also come to realize that the younger generation of engineers and future NASA project managers would also greatly benefit from these case studies. Whereas the discussion question for groups of project managers tends to be "What would you do as the PM for this project?", the discussion question for future PMs needs to be adjusted to their current roles. I'm not sure whether the entire case study would need to be rewritten. I've also come to realize that there are dangers in rewriting case studies. The more they are rewritten to suit a particular purpose, the greater the danger of straying away from the real story. The best approach might be to keep the case unchanged but to adjust the facilitation and trigger question that starts the discussions around the case.
Subscribe to:
Posts (Atom)