Oscar Winners

 

 

SLUMDOG MILLIONAIRE

 

Sean Penn
MILK

 

Kate Winslet
THE READER

 

SLUMDOG MILLIONAIRE

 

DEPARTURES

 

SLUMDOG MILLIONAIRE

 

SLUMDOG MILLIONAIRE

 

SLUMDOG MILLIONAIRE

 

SLUMDOG MILLIONAIRE

 

THE DARK KNIGHT

 

THE CURIOUS CASE OF BENJAMIN BUTTON

 

SMILE PINKI

 

MAN ON WIRE

 

Heath Ledger
THE DARK KNIGHT

 

SPIELZEUGLAND (TOYLAND)

 

SLUMDOG MILLIONAIRE

 

THE CURIOUS CASE OF BENJAMIN BUTTON

 

THE DUCHESS

 

THE CURIOUS CASE OF BENJAMIN BUTTON

 

LA MAISON EN PETITS CUBES

 

WALL-E

 

SLUMDOG MILLIONAIRE

 

MILK

 

Penelope Cruz
VICKY CRISTINA BARCELONA

 

Toshiba Launches The TG01 i-Killer

Wow! Is the first word that came to me when I heard the news and lay my peepers on the largest screen ever to make it to the mobile phone segment – 4.1-inches with a WVGA (800 x 480 pixels) resolution. I was even more impressed when I saw the company that put this baby out. Toshiba has launched this iKiller, their TG01 PocketPC, that’s running on Qualcomm Snapdragon platform using a Windows Mobile 6.1 OS. Just so you know, there is no other mobile device that runs on this system yet. 

Toshiba has also gone with a customized 3D UI to add a little pizzazz to the mix. The Mobile Internet Device is powered by a 1GHz mobileCPU. Aside from its extremely large display and a slim 9.9mm thick body, this GSM handset is quite well equipped too with features that include – 

• Internal GPS with A-GPS
• Bluetooth 2.0
• Wi-Fi
• EDGE/GPRS and 3G with HSDPA support
• 512MB internal memory with up to 32GB for external via MicroSD cards
• 3.2 megapixel camera
• Support for DivX video playback.
• Internet Explorer Mobile 6 with full support for Flash and a virtual track pad for web navigation
• Shake control for specific features as well as an accelerometer for screen rotation

Image Source 

Other than that the company and Qualcomm have claimed that the TG01 will actually be able to go for a whole day without recharging thanks to the CPU’s dynamic speed control. 

The TG01 mobile will be available in two colors according to the images making the rounds – black and white. It’ll hit Europe later this year through exclusive operator deals. There’s no pricing mentioned yet so stay tuned.

Defect Prevention: Reducing Costs and Enhancing Quality

“Prevention is better than cure” applies to defects in the software development life cycle as well as illnesses in medical science. Defects, as defined by software developers, are variances from a desired attribute. These attributes include complete and correct requirements and specifications as drawn from the desires of potential customers. Thus, defects cause software to fail to meet requirements and make customers unhappy.

And when a defect gets through during the development process, the earlier it is diagnosed, the easier and cheaper is the rectification of the defect. The end result in prevention or early detection is a product with zero or minimal defects.

How serious are defects in software development? In the United States, up to 60 percent of software developers are involved in fixing errors, Computer Finance Magazine reported in 1998. This fact alone, without consideration of providing the quality needed to please customers, shows the value of preventing software defects.

Advantage of Early Defect Detection

Data to support the need for early fixes of software defects is supplied by several reports. The National Institute of Standard Technology (NIST) published a study in 2002 noting that the cost of fixing one bug found in the production stage of software is 15 hours compared to five hours of effort if the same bug were found in the coding stage.

The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase (Figure 1).

 

Figure 1: Relative Costs to Fix Software Defects

                                                                                                      Source: IBM Systems Sciences Institute 

Can software defects be prevented by simply logging them into some “defect tracking tool/system,” documenting them and providing fixes for them? The obvious answer is no, though this is the first step toward defect prevention.

Defect prevention involves a structured problem-solving methodology to identify, analyze and prevent the occurrence of defects. Defect prevention is a framework and ongoing process of collecting the defect data, doing root cause analysis, determining and implementing the corrective actions and sharing the lessons learned to avoid future defects.

Principles of Defect Prevention

How does a defect prevention mechanism work? The answer is in a defect prevention cycle (Figure 2). The integral part of the defect prevention process begins with requirement analysis – translating the customer requirements into product specifications without introducing additional errors. Software architecture is designed, code review and testing are done to find out the defects, followed by defect logging and documentation.

 

Figure 2: Defect Prevention Cycle

                                                                                           Source: 1998 IEEE Software Productivity Consortium 

The blocks and processes in the gray-colored block represent the handling of defects within the existing philosophy of most of the software industry – defect detection, tracking/documenting and analysis of defects for arriving at quick, short-term solutions.

The processes that form the integral part of the defect prevention methodology are on the white background. The vital process of the defect prevention methodology is to analyze defects to get their root causes, to determine a quick solution and preventive action. These preventive measures, after consent and commitments from team members, are embedded into the organization as a baseline for future projects. The methodology is aimed at providing the organization a long-term solution and the maturity to learn from mistakes.

Most of the activities of the defect prevention methodology require a facilitator. The facilitator can be the software development project leader (wearing another hat of responsibility) or any member of the team. The designated defect prevention coordinator is actively involved in leading defect prevention efforts, facilitating meetings and communication among team and management, and consolidating the defect prevention measures/guidelines.

The five general activities of defect prevention are:

1. Software Requirements Analysis

 

Table 1: Division of Defects Introduced into Software by Phase
Software Development Phases	Percent of Defects Introduced
Requirements	20 Perecent
Design	25 Percent
Coding	35 Percent
User Manuals	12 Percent
Bad Fixes	8 Percent
Source: Computer Finance Magazine

Errors in software requirements and software design documents are more frequent than errors in the source code itself, according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only more probable but also are more severe and more difficult to remove. Front-end errors in requirements and design cannot be found and removed via testing, but instead need pre-test reviews and inspections. Table 1 shows the defects introduced during different phases of the software development life cycle. 

From the studies made by various software development communities, it is evident that most failures in software products are due to errors in the requirements and design phases – as high as 64 percent of total defect costs (Figure 3), according to Crosstalk, the Journal of Defense Software Engineering.

 

Figure 3: Origin of Software Defects

                                                                      Source: Crosstalk, the Journal of Defense Software Engineering 

Hence, it is important to have a proper process of analyzing the requirements in place to ensure that the customer needs are correctly translated into product specifications. Perhaps two or three iteration of interactive sessions with the customer can be of great help in verifying the understanding of the developer about actual requirements.

2. Reviews: Self-Review and Peer Review

Self-review is one of the most effective activites in uncovering the defects which may later be discovered by a testing team or directly by a customer. The majority of the software organizations are now making this a part of “coding best practices” and are really increasing their product quality.

Often, a self-review of the code helps reduce the defects related to algorithm implementations, incorrect logic or certain missing conditions. Once the developer feels they are ready with the module code, a glance through the code and understanding what it does compared to what it is supposed to do, would complete the self-review.

Peer review is similar to self-review in terms of the objective – the only difference is that it is a peer (someone who understands the functionality of the code very well) who reviews the code. The advantage is that of a “fresh pair of eyes.”

3. Defect Logging and Documentation

Effective defect tracking begins with a systematic process. A structured tracking process begins with initially logging the defects, investigating the defects, then providing the structure to resolve them. Defect analysis and reporting offer a powerful means to manage defects and defect depletion trends, hence, costs.

A defect logging tool should document certain vital information regarding the defect such as:

• Correct and complete description of the defect – so that everyone on the development team understands what it is and how to reproduce it.
• Phase at which it is found – so that preventive measures can be taken and propagation of the defect to next phase (software build) is avoided.
• Further description of the defect by screenshots.
• Names of those who uncover defects – so everyone knows who to contact for a better understanding of the defect.

4. Root Cause Analysis and Preventive Measures Determination

After defects are logged and documented, the next step is to analyze them. Generally the designated defect prevention coordinator or development project leader facilitates a meeting to explore root causes.

The root cause analysis of a defect is driven by three key principles:

• Reducing the defects to improve the quality: The analysis should lead to implementing changes in processes that help prevent defects and ensure their early detection.
• Applying local expertise: The people who really understand what went wrong are the people present when the defects were inserted – members of the software engineering team. They can give the best suggestions for how to avoid such defects in the future.
• Targeting the systematic errors: There may be many errors or defects to be handled in such an analysis forum; however, some mistakes tend to be repeated. These systematic errors account for a large portion of the defects found in the typical software project. Identifying and preventing systematic errors can have a big impact on quality (in terms of defects) for a relatively small investment.

With these guidelines, defects are analyzed to determine their origins. A collection of such causes will help in doing the root cause analysis. The defects are classified based on their types. A Pareto chart is prepared to show the defect category with the highest frequency of occurrence – the target. An example of defect classification in a Pareto chart is shown in Figure 4.

 

Figure 4: Example of Defect Classification in a Pareto Chart

 

Root cause analysis is the process of finding and eliminating the cause, which would prevent the problem from recurring. Finding the causes and eliminating them are equally important.

Each defect category and the causes making those defects happen can be represented using a cause-and-effect diagram, as shown in Figure 5.

 

Figure 5: Cause-and-Effect Diagram for a Defect

 

The cause-and-effect diagram, also known as a fishbone diagram, is a simple graphical technique for sorting and relating factors that contribute to a given situation. A team usually develops the cause-and-effect diagram in a facilitated brainstorming session. Once the root causes are documented, finding ways to eliminate them requires another round of brainstorming. The object is to determine what changes should be incorporated in the processes so that recurrence of the defects can be minimized.

5. Embedding Procedures into Software Development Process

Implementation is the toughest of all activities of defect prevention. It requires total commitment from the development team and management. A plan of action is made for deployment of the modification of the existing processes or introduction of the new ones with the consent of management and the team. Some of the other activities in this phase of defect prevention are:

• Monthly status of the team should mention the severe defects and their analyses.
• Fortnightly or monthly (based on the project schedule) meetings to make the team aware of the systematic errors/defects, their symptoms and solutions.
• Embedding the defect prevention measures in software development life cycle processes.
• Learning from the previous project’s root cause analysis of defects should be used as the baseline for future projects.
• Monitoring the defect prevention progress. Is the number of defects decreasing? Is the development team learning from past mistakes?

Finally, defect prevention is not an individual exercise but a team effort. The software development team should be striving to improve its process by identifying defects early, minimizing resolution time and therefore reducing project costs.

Conclusion: Beyond ‘To Err Is Human’

To err is human but defect prevention practices enhance the ability of software developers to learn from those errors and, more importantly, learn from the mistakes of others. The benefits of implementing a defect prevention methodology are:

• Improved checklist for product quality
• Reduced rework effort
• Significant reduction the number of defects and their severity
• Better communication among the project team and upper management
• More optimized resource planning

Srikanths US PICS

Meetings with the team

To provide a regular forum for communications to ensure that all team members:

 

·          understand and can speak to the larger context of the project,

·          develop together a common vision and set of goals for the project which encompass all aspects (not just software, or implementation, or customer relations, but all aspects together),

·          have a common understanding of the current status of the project,

·          maintain direction and movement toward their goals,

·          avoid becoming too narrow in their focus by concentrating on a single area of responsibility.

 

Method

 

Schedule and conduct weekly team meetings according to the project hierarchy.  On a small project with a small project team there might need to be only one such meeting each week.  On a larger project, Project Managers should hold weekly team meetings with their Team Leaders and Team Leaders should hold similar weekly team meetings with their team members.

 

Conduct meetings in person, preferably, or via a conference phone‑call, if necessary (for example, with remote teams). Adhere to a standard meeting time and place.  Make sure that everyone does everything they can to attend the meeting.  If someone is off on a business trip or working off site, include them via a conference call if at all possible.  Don’t be too quick to accept excuses (there are always seemingly valid reasons for not attending the meeting) or any suggestion that a weekly meeting is a waste of time.  The chairperson is at fault if the meeting is not run as efficiently or as effectively as it should be.

 

Use the meeting technique to plan for, schedule, and conduct an effective and efficient meeting.  Do not allow the meeting to be used to ask questions or hold discussions which are of interest to only a small number of the participants.

Meeting technique

 

Arrange to have individual status reports distributed and read by team members in advance of each meeting.

 

Use a standard agenda for each meeting, including the following:

 

·          individual status – goals and accomplishments,

·          issues for discussion and resolution (e.g., problems or risks arising from team status or raised by team members),

·          outstanding decision requests, change requests, and fault reports,

·          quality metrics and trends,

·          summary of action items.

 

Have each person provide a brief status update, highlighting his or her three (maximum of five) most significant accomplishments or events over the past week and the three (maximum of five) most significant items that they or their team realistically plan to accomplish next week.  Make sure that each person focuses on what the others need to know about each area of responsibility. Do not allow anyone to simply list what they or their team members are continuing to work on, or to get into long detailed explanations.

 

Make sure that everyone saves editorial comments, questions, or issues for a systematic and focused question and answer period when all presentations are complete.  As soon as an item does not need further discussion as a group, or cannot be resolved in the meeting, assign it for follow up to the individual responsible, as appropriate. 

 

Review the status and impact of all outstanding Decision Requests, Change Requests, and Fault Reports, as appropriate.

 

Follow-up on risk items in accordance with the risk management technique.

Risk Management

 

Give each participant a final opportunity to raise any of the following:

 

·          issues (e.g., interfaces between components, items not followed‑up),

·          requests for advice (e.g., “can you suggest a way to …?”),

·          problems (e.g., items not being tested correctly at the unit level),

·          warnings (e.g., potential slippages to schedules, and dates),

·          suggestions (e.g., to improve the processes being used by the team),

·          compliments (e.g., “great job …”).

 

Conclude the meeting by summarizing the action items and record, communicate, and track all action items to completion. See also:

Manage Action Items

 

Prepare a brief, action-oriented set of meeting minutes, summarizing the decisions reached, along with a brief explanation for why each decision was made, to preserve the “collective memory” of the project. Distribute the minutes to the participants and file the minutes on the team’s LAN or in the Project Book.

 

 

Meeting With the Team Checklist

CHECKLIST FOR MEETING WITH THE TEAM
	Yes	No	N/A	Remarks
Is there a regular weekly meeting for all members of the project team to review status, share experiences, provide suggestions, and resolve problems and concerns?
Does the meeting follow a standard agenda?
Is each participant given an opportunity in the team meeting to raise issues, problems, warnings, or suggestions for improvements?
Is the team meeting used to share information on the customer, the project, and social news?
Is the team meeting used to provide feedback on how the overall project is doing (both from delivery and customer management)?
Is the team meeting used to review the status and impact of all outstanding decision requests, change requests, and fault reports, as appropriate?
Are team meetings run effectively (e.g., is project meeting time properly managed)?
Does everyone attend team meetings on a consistent basis?
Are action items from team meetings recorded and followed through to closure?
Are the Project Manager and Team Leaders meeting regularly with team members on an informal and individual basis, in addition to the team meeting (“management by walking around”)?

Reporting Weekly Status

To summarize and communicate the accomplishments for the reporting period, the objectives for the coming period, problems (if any), the status of outstanding risk items, and suggestions for dealing with issues and problems.

 

Prepare Individual Status Reports

 

Have each team member use the standard template or equivalent (e.g., Checkpoint) to prepare a Weekly Status Report. Make sure that each report is brief (point form), focused on the key information to be communicated, and directly related to the team member’s scheduled activities as defined in his or her Project Tracking Document.

 

Sit down with each team member to go over his or her Weekly Status Report, identify and resolve any variances from plan, assess the team member’s continuing commitment, and review whether there are any new risk factors present.  Use constructive criticism to help the individual improve his or her performance if necessary.  Apply risk management to any new risks that may have been identified.

            Constructive Criticism

            Risk Management

 

Prepare Summarized Team and/or Project Status Reports

 

Summarize all individual reports to the team or project level to provide key accomplishments, objectives, and problems (if any) for the week. Attach statistics and/or charts or configuration management reports showing the screen, report and function counts to provide a quantitative view of progress.  Include with the summarized report updated versions of each of the following (as appropriate):

            Project Tracking Summary Report,

            Risk Management Log,

            Change Request Log,

            Decision Request Log,

            Fault Report Log.

 

Distribute and Follow-Up Status Reports

 

Distribute the summarized Project Weekly Status Report and attachments to project team members, and file these on the team’s LAN or in the Project Book.  Retain the latest four status reports in the Project Book and archive previous reports in the project files.

 

Walk-through the summarized Project Weekly Status Report and attachments with the Delivery Line Manager and the Acceptor. Formally record and manage the action items that result and track them through to closure.  

 

 

CHECKLIST FOR WEEKLY STATUS REPORTING
	Yes	No	N/A	Remarks
Is each team member preparing a weekly status report in a timely manner, in the format defined in the knowledge base?
Is each status report directly related to the team member’s scheduled activities as defined in his or her project tracking document?
Do team leaders sit down with each team member to go over his or her report, identify and resolve any variances from plan, assess the team member’s continuing commitment, and review whether there are any new risk factors present?
Is the Project Manager producing a consolidated weekly status report based on the reports from team members?
Is the Project Manager preparing a weekly risk report, using the standard template, to identify the seven to ten top current risks?
Are each of the following attachments added to the weekly status report where applicable: Risk Report; Change Request Log; Decision Request Log; Fault Report Log; Graph of Planned, Started and Completed Modules?
Does the Project Manager walk through the weekly status report and attachments with the Delivery Line Manager each week?
Does the Project Manager walk through the weekly status report and attachments with the Acceptor each week?
Are the completed weekly status reports and attachments filed in the Project Book?
Are action items that result from the weekly status reporting process formally recorded and tracked through to closure?

Reporting Monthly Status

To keep project status visible to senior management in the customer and delivery organization by providing an appropriate summary of project status on a regular monthly basis.

 

Prepare Monthly Status Report

 

Use the standard template (or an equivalent presentation format) to prepare the Project Monthly Status Report.  Attach statistics and/or charts or configuration management reports showing the screen, report and function counts to provide a quantitative view of progress. 

 

Include with the Project Monthly Status Report the updated version of each of the following (as appropriate):

current project schedule (e.g., summary Gantt chart),

quality metrics and trends (as defined in the Quality Management Plan)

Risk Management Log,

Change Request Log

Decision Request Log

Fault Report Log

 

Walk through the Project Monthly Status Report and the relevant attachments with the Delivery Line Manager prior to distribution.

 

Distribute and Follow-Up Status Report

 

Distribute the Project Monthly Status Report (minus any company confidential attachments) to the Delivery Line Manager, the Acceptor, and the Acceptor’s Line Manager (i.e., the core members of the Project Steering Committee), as part of the regular progress review process.

 

File the Project Monthly Status Report and attachments on the team’s LAN or in the Project Book.  Retain the latest four status reports in the Project Book and archive previous reports in the project files.

 

Formally record and manage the action items that result from the Project Monthly Status Report and track them through to closure.

 

See Also

 

           Checklist for Monthly Status Reporting

A Team Building Process

The purpose of this post is to provide some simple, practical guidance to facilitate the team building process.

 

Method

 

In order to achieve effective teamwork, the team building process must start early and continue throughout the life of the project. Although some aspects of team-building can be addressed by special activities and exercises, in practice most team-building is built into the everyday activities of the project.  Team building approaches are incorporated into the guidelines for:

 

            Obtaining Resources

 

            Holding a Kick-Off Meeting

 

            Setting Goals and Objectives

 

            Obtaining Commitment

 

            Establishing Standards and Procedures

 

            Project Training

 

            Project Communications

 

            Project Meetings

 

            Rewards and Recognition

 

            Monitoring Team Morale

 

            Conducting Performance Appraisals

 

            Avoiding Burnout

Design/Analysis Walk-Thru Checklist

DESIGN WALK-THROUGH CHECKLIST
	Yes	No	N/A	Remarks
Does the unit perform the required functionality?
Does the database design support the functionality?
Is the design composed of small enough modules to permit easy understanding for maintenance?
Is the logic and hierarchical decomposition accurate?
Are parameters used and referenced correctly?
Does the design style adhere to project standards?
Are data structures efficient for access and storage?
Are all called units documented to a sufficient level of detail so that the design of the unit under review can be completed?
Can redundancies be eliminated by using common modules?

ANALYSIS WALK-THROUGH CHECKLIST
	Yes	No	N/A	Remarks
Does the documentation and/or prototype demonstrate that the analyst understands the customer’s environment, requirements, and problems?
Does the documentation adhere to standards?
Does the external design reflect or solve the customer’s requirements or problem?
Does each process or product comply with the customer’s requirements for that process or product?
Does the logical file/database design support the requirements?
Are all subsystem functions, inputs and outputs addressed?
Have all interfaces among subsystems been considered?
Have all data and transaction volumes been documented?
Will all data and transaction volumes be accommodated?
Have all security provisions, backup and recovery procedures, and audit trails been included?
Is this approach the most efficient approach to solving the problem?
Does the approach taken provide what is required but not more than necessary?
Will the hardware and software support the approach?
Is the level of detail correct? (Critical areas should be covered in detail)
Have conversion requirements been addressed?

Better Meetings

We all have them, and as you probably remember, they still suck.  But that isn’t to say that we can’t work to make meetings better!  Meetings should be used for communicating with team members and promoting group problem solving.  The meetings technique can be used for any form of meeting from small gatherings of two or three participants to large scale gatherings.  The approach needs to become more formal as a meeting gets larger.

Method:

PRIOR TO THE MEETING

 

Understand the Purpose

 

Make sure that you clearly understand:

 

·          the purpose of the meeting,

 

·          the subjects to be covered,

 

·          who needs to be there so that the objective can be achieved,

 

·          why each person needs to be there.

 

Make sure that the necessary people, materials, and equipment are available.

 

Create the Agenda

 

Think through the items to be covered and establish a logical sequence, with the most important items being dealt with as early as possible.

 

State clearly what is expected to be achieved with each item (e.g., communicating information, generating discussion, reaching a decision).

 

Allocate time according to the importance of each item.

 

Distribute the Agenda in Advance

 

Distribute the agenda sufficiently in advance so that:

 

·          everyone is briefed ahead of time,

 

·          everyone knows what is expected from them,

 

·          all participants have sufficient time to prepare, if necessary.

If a decision is required, provide sufficient advance notice so that the participants can do any necessary research ahead of time.

CREATING THE CLIMATE FOR THE MEETING

 

Welcome the Group

 

Be early and meet the participants individually as they arrive.  In this way, you can begin to talk more freely with the participants and you do not walk into a room full of unknown faces with which you have to begin an interaction.

 

Review the Objectives and Agenda

 

Review the objectives (“why we are here”).

 

Review the agenda (“how we are going to accomplish our purpose”).

 

Establish Ground Rules

 

Establish some specific rules of conduct up-front such as:

 

·          participation must be full-time: no in and out, 

·          everyone participates: no non-participation, no dominating the discussion,

 

·          no side discussion,

 

·          “green light” on ideas but stay focused on the topic at hand: no off-topic discussion, no getting side tracked, no getting into too much detail,

 

·          don’t argue about what you don’t know.

CONTROLLING THE MEETING

 

Role of the Chairperson

 

As the chairperson, you are in control.  You need to be confident, assertive, and able to control the level of participation by all those in the meeting.  You determine when the meeting begins and ends, and when there will be breaks.  You are responsible for the flow of the meeting, and for ensuring that all members participate and don’t try to force their opinions on other members of the group. 

 

Be goal directed and manage the available time well, to ensure that the meeting moves forward toward achieving its goals. 

 

Controlling the Discussion

 

Make sure that material is presented in an orderly manner.  Using the analogy of a court case, deal with the evidence first, then the interpretation of the evidence, and finally the assessment and decision-making.

 

Make sure that the bulk of the talking is done by the participants but also ask questions and periodically draw conclusions or summarize.  Even the conclusions and summaries can be stated in the form of questions, for example:

 

            “Let me see if I understand this correctly,  … ?”

 

Don’t let anyone in the group leave with the feeling that their ideas were not listened to or that they were not given the chance to speak – such people may very well undermine the group results sometime in the future.  The group members must work together. As they work closely together, they generate a momentum and synergy, and can see the results associated with their active co-participation. 

 

Record action items immediately as they arise.

 

Make sure that agreement is obtained by consensus rather than by a show of hands or by the dictation of the facilitator.  If consensus is not being reached, use a technique such as responsive listening.

 

            “I hear one group saying ….. I hear the other group saying ….. Is that right?”

 

Conclude the meeting by summarizing the decisions reached and reviewing the action items assigned to each person.

HANDLING PROBLEM SITUATIONS

 

Controlling the Person who Speaks Too Much

 

Don’t allow any one person to take an unfair amount of time.  Use direct comments if necessary to control the person who speaks too much.  For example:

 

            “Jim, we’ve heard your idea, let’s see if any of the others in the group have ideas to add.” 

 

Eliminating Side Conversations

 

Make sure that only one person speaks at a time.  Guard against side conversations in which comments are exchanged between a sub-set of the members and not with all members of the session. A simple approach is to highlight that this is happening and bring the meeting back to order.

 

Drawing Out Silent Non-Participants

 

Make sure that all participants are involved by drawing out non-participants if necessary. For example, you might explicitly poll each person in turn, and by name, and ask for their input on the topic.

 

As you draw them out, make sure that they are given the chance to voice their opinions and ideas fully without interruption by others. For example:

 

            “Excuse me Jim, I don’t think Jeff was finished, go on Jeff”

 

Staying On Track

 

Encourage free thinking, but don’t let a session degenerate into office politics, drawn-out examples that are only marginally related to the direction of the meeting, or too much detail, to the point that these side paths consume the time of the group.

 

Watch this very carefully.  Be aware that everyone has a tendency to go into too much detail too soon.  Always ask yourself if you really need to know this information now, to make the decisions you are currently working on.

 

Although ideas must be discussed fully to allow for agreement, you must be able to discern when agreement has been reached and move on to the next item of discussion.  Be flexible in this area, though, as sometimes all the goals cannot be met.

 

As a facilitator, call a time out if the discussion is getting off track or becoming overly heated – use your hands and arms to draw attention, if necessary.  If the issues seem to be important, make a visible note of them (for example, on a flip chart) as items to explore later.

 

Move on in the original direction of the agenda and come back to these side issues at another time, when the main topic is exhausted, at a special session to deal with the issues, or through some other means such as an interview.  For example:

 

            “That’s a good question, but since it’s beyond the scope of our area of consideration, let’s discuss it later.”

 

            “Those are good points, we’ll note them as possible items for consideration, but getting back to our topic …”

 

Resolving Conflicts

 

In the event of a conflict that can not be resolved through discussion, identify the facts required to make a decision, assign responsibility for gathering these facts, and consult the manager most able to make a decision.

 

For the most part, conflict resolution can be non-confrontational.  However, if issues arise that can not be resolved in any other way, an agreed-upon conflict resolution procedure must be applied.  The aim of such a procedure is to make sure that any such conflicts are resolved by management, reflecting its perspective on the priorities and needs of the project, rather than by project personnel.  The results of the conflict resolution procedure are then binding upon all.

 

If there are strongly divergent opinions you may find it necessary to suggest that the meeting be stopped until:

 

•           the participants have had time to think about, research, or discuss the issue with others and return with fresh ideas, or

 

•           additional people can be added to the meeting, such as specialists or key decision makers.

 

Other Problems

 

In the event of any other problems occurring, be free to comment on what is happening and take time out if necessary. For example:

 

            “I’m unable to follow the meeting when more than one person talks at once.” 

            “I’d like to take a five minute break to get my thoughts together.”

 

            “I’m feeling angry right now and I need a two hour break to cool off.”

ROLE OF THE SCRIBE

 

Responsibility

 

The scribe is responsible for keeping a log of the discussions and decisions of the group.  This log, the meeting minutes, becomes an essential part of the project records.

 

Skills Required

 

This role requires many skills and takes extraordinary concentration – it is incorrect to think of the scribe as hardly more than a human dictaphone. 

 

The scribe needs to have a good awareness for what is being discussed, as no one can keep good notes on things that they don’t understand.  The scribe must also know how to record and manage information for the project.  The quality of the records determines the quality of the group’s permanent collective memory of what happened and how. 

 

A scribe who captures a complete account of what the meeting accomplished, without excessive detail, in a manner that is well organized and understandable, is an extremely valuable team member.

 

Creating the Meeting Record

 

In creating a meeting record, new scribes often either try to write down everything as if they were taking dictation, or else wait until the group reaches some conclusion and just summarize.  Neither approach is ideal.

 

A good process record keeps track of key events along the way to the outcome, especially alternatives considered, decisions made, and the arguments presented.  Often, it is equally important to know what approaches were rejected and why as to know what approach was selected.  However, a “he said” or “she said” record is neither necessary nor optimum.

 

In developing the record, some categories of information are so commonly generated that they warrant separate recording for special attention, for example:

 

·          keep a list of action items for noting things that come up in discussions but are not acted on right away,

 

·          record “deferred decisions,”

 

·          keep a “suggestions box” where bits and pieces of good ideas or partial solutions can be set aside temporarily.

 

All three special categories serve to record things that might otherwise be lost or forgotten, and help the group to make efficient use of time.

 

By recording digressions and distractions in one of these specialized bins, the group can stay on track with the main problem without losing useful information.  These bins can also keep a group from getting stuck on discussions that are going nowhere.  Instead of more wheel‑spinning, an issue can be moved to one of the bins for later attention.

 

Before closing the meeting, make sure that everything in the bins has been accounted for.  Also, make sure that the action items are assigned to a specific individual and are subsequently followed through to closure.

 

Tips and Hints

 

To improve efficiency, the scribe should consider taking a portable computer into the meeting.  Creating the draft minutes on-line minimizes the documentation effort required after the meeting. The draft minutes can then be cleaned-up and distributed quickly and efficiently via e-mail.

 

Write references to possible changes in scope or contractual requirements so that they do not imply approval of the change. Approval will be obtained at another time.  For example, write “a licence for xxx software may be required” rather than “we must acquire a licence for xxx software.”

 

Refer to individuals by initial and last name (e.g., F. Brown).

 

If references to documents are to be included in the minutes, include the document name and number and, if appropriate, page number or section number.

 

With some types of meetings, it can be useful to have the meeting minutes formally signed-off by the participants.  The above process is particularly effective for these situations.  The minutes can be printed off at the conclusion of the meeting and approved or revised on the spot, while all of the necessary participants are still in attendance.

 

Particularly with regularly scheduled meetings, it can be useful to periodically assess the effectiveness of the meeting through a survey of the participants (sample checklist).

 

 

CHECKLIST FOR MEETING EFFECTIVENESS
Project Name:
Meeting Name:
Date and Time:				Place:
Please rate the effectiveness of the meeting by assigning a value from 0 (worst) to 5 (best) to each item. Return the completed form to the Quality Assurance Manager.
Ground Rule								Rating
The meeting objective was clear.
There was a published agenda with specific objectives for each item (for information, for discussion, for action), and allotted time.
Attendance was appropriate. There was a valid reason to require each person to take time away from their other responsibilities to attend.
I was notified in advance of the topic, my role in the meeting, and what I may be asked.
All of the staff and resources required were available.
There was a facilitator (chairperson) appointed to keep the meeting on track.
The meeting started on time.
There was a process (ground rules) defined for how the meeting was to run.
The meeting kept to the agenda and the allotted time for each item, and the ground rules were followed.
There was consensus achieved.
Action items were assigned where appropriate
There was a person assigned to document minutes.
Minutes were provided within a reasonable period and adequately documented the meeting.
Comments (constructive suggestions)
Completed By (optional):					Date: