We had a guest speaker come in from Johns Hopkins APL to our leadership class at UMBC last night. He shared with us his career experiences and some tips.
One thought I got from his visit was the importance of teaching technical/scientific review meetings leadership. I did a search on the Internet quickly to see what is out there, but there is very little literature in how to successfully run and conduct a technical review.
I am not talking from a process perspective, like what the process for an SRR should be. These processes are well known and understood. But rather I am talking from the leadership perspective. Areas like
1. Tools
- What are the best tools to use during the review, slideware, spreadsheets, technical documents, etc..
- Can reviews be conducted remotely over collaboration S/W like NetMeeting, Notes
- What is more effective in-person or remote meetings? I did both each has it pros and cons
2. Negotiation schemes
- So the client PM takes over the meeting, how do you as the lead SE on the contractor side react?
- Just got into a project yesterday, you need to do a walk-thru tomorrow, who are players? how to run the review smoothly?
3. Time control
- Mr. chatter loves to chat, and whiner complains about each requirement, and repeater has to make sure we all memorize his statements before we leave, how to filter and weed out the garbage talk and retain the technical meat you are looking for?
- One big 8 hr meeting with 1 hr lunch and 2 15-min breaks, or 4 2-hr meetings over 4 days?
4. Scope control
- Ok, we are doing a use case review, but lets quickly go over the architecture, 60/40 opposition, what do you do?
I attended a workshop by Edward Tufte, the professor at Yale last Spring, he discussed some very interesting thoughts about how some organizations fail to conduct reviews simply because they use poor tools. He gave the example of NASA and the shuttle explosion. In his opinion as well as the many experts who evaluated the crash, the failure in the shuttle started not at launch, but rather way back in the technical review process. NASA was too heavily dependent on power point fluff. It was very easy to lose focus of the strategic technical issues and questions during the reviews.
This all needs more research...
One thought I got from his visit was the importance of teaching technical/scientific review meetings leadership. I did a search on the Internet quickly to see what is out there, but there is very little literature in how to successfully run and conduct a technical review.
I am not talking from a process perspective, like what the process for an SRR should be. These processes are well known and understood. But rather I am talking from the leadership perspective. Areas like
1. Tools
- What are the best tools to use during the review, slideware, spreadsheets, technical documents, etc..
- Can reviews be conducted remotely over collaboration S/W like NetMeeting, Notes
- What is more effective in-person or remote meetings? I did both each has it pros and cons
2. Negotiation schemes
- So the client PM takes over the meeting, how do you as the lead SE on the contractor side react?
- Just got into a project yesterday, you need to do a walk-thru tomorrow, who are players? how to run the review smoothly?
3. Time control
- Mr. chatter loves to chat, and whiner complains about each requirement, and repeater has to make sure we all memorize his statements before we leave, how to filter and weed out the garbage talk and retain the technical meat you are looking for?
- One big 8 hr meeting with 1 hr lunch and 2 15-min breaks, or 4 2-hr meetings over 4 days?
4. Scope control
- Ok, we are doing a use case review, but lets quickly go over the architecture, 60/40 opposition, what do you do?
I attended a workshop by Edward Tufte, the professor at Yale last Spring, he discussed some very interesting thoughts about how some organizations fail to conduct reviews simply because they use poor tools. He gave the example of NASA and the shuttle explosion. In his opinion as well as the many experts who evaluated the crash, the failure in the shuttle started not at launch, but rather way back in the technical review process. NASA was too heavily dependent on power point fluff. It was very easy to lose focus of the strategic technical issues and questions during the reviews.
This all needs more research...
No comments:
Post a Comment