By Dr. Gerald Mulenburg, PMP:
When I learned of an opportunity to sit in on a major NASA project review as a “fly on the wall,” I jumped at it. This seemed like a great way to learn about the new Kepler project. Kepler is a special purpose mission in the NASA Discovery Program, with an objective that the project’s principal investigator William Boruki says is to “explore the skies for terrestrial-like planetary systems around other stars, in order to answer one of the most enduring questions humans have asked throughout history: Are there others like us in the universe?”
Fly-on-the-wall was an experiment in knowledge sharing, offering project practitioners an opportunity to learn from observing good project-related meeting processes as they occurred in real time. This idea surfaced after several senior project managers commented that they had little, if any, training or experience in holding reviews, making presentations, holding team kick-off meetings, or in many other project management activities until they “had to do one.” A common refrain was, “I’d never even seen one!”
To participate as a fly began an interesting and revealing odyssey for me, watching and listening to peer review presentations and discussions from the Kepler-Ground Segment development team to other NASA and contractor managers. These were the key players who would decide how the project would be structured and who would establish a preliminary schedule for this portion of the project.
Now operating in space, Kepler was a joint project between two NASA Centers. Mission control and overall data management were the responsibility of the Ames Research Center, and the telescope and the launch portion were to be managed by the Jet Propulsion Laboratory. The primary instrument of Kepler is a specialized one-meter diameter photometer telescope, positioned in Earth’s orbit to “stare” for four years at a small portion of the night sky, containing over 100,000 stars similar to our sun, and to capture images of Earth-like planets rotating around them. This peer review of the project’s ground segment portion emphasized that Kepler was not a large, complicated project.
I was impressed that the meetings started on time, stayed on time, and even finished a little ahead of schedule, despite a lot of active discussion about the control and management techniques to be employed in the project and who had what responsibility. No fewer than eight separate functional organizations with integral roles in the project attended the meeting, from across three continents including North America. And this was said to not be a complex mission! My hat went off to the Kepler project team for their thoroughness, professionalism and ability to stick to the purpose of the meeting. Some useful tips that I picked up as an observing fly for future use in meetings include:
- INTRODUCTIONS: Not introducing everyone in the room; only the key players at the main table. Other important contributors, who gave parts of the presentation or contributed to the discussions when appropriate, introduced themselves. Some of these people were high-level representatives who did not seem to mind their secondary roles in the meeting.
- PURPOSE: Clearly stating the purpose of the meeting at the beginning and, even more important, clearly stating what the meeting “was not” about. This set the stage for efficiency and minimized distracting comments. A facilitator kept the meeting moving along but never “squashed” anyone who had a relevant comment or contribution.
- OMBUDSMAN: Assigning a key member at the table as an ombudsman with a strong enough personality to cut off discussion when it would be part of a later presentation (not relevant now), or to end comments that contributed little (those who love their own voice) or when it would be more appropriate for an off-line conversation (those who can’t let go but just-might have something important to say). This process worked well and was conducted in a polite, professional manner.
- ROLES AND RESPONSIBILITIES: A particularly useful chart on one wall, referred to often during the meeting, showed a roles and responsibilities matrix with the key organizations involved in the project, listed across the top as column headings, and the project functional elements as role headings down the left-most column. The row-column intersections in the matrix clearly identified the organization responsible for each of the functions, removing much confusion that might otherwise have occurred.
I believe fly-on-the-wall is an extremely simple but valuable knowledge-sharing technique, easily duplicated in any organization. Tips from observers in well-run meetings can be shared with project managers and teams, and have high potential for encouraging an outcome of project success.
In what ways do you think the fly-on-the-wall technique can help your projects?