BACKGROUND
The invention relates generally to meeting management, and more particularly to a method and system for managing a meeting and its output.
The meeting may be managed manually or automatically. The manual process for managing a meeting is feasible when the meeting involves only a few people and small or less items in the agenda. However when the meeting involves large group of people, the coordination of the meeting becomes nightmare and managing action items would be very difficult and tedious task.
Present placations send meeting requests to participants and book their calendar and also send reminders for the meetings. Some of the applications track the meeting requests in the calendar. And in some current system the recording of the meeting conversations are also stored.
Some applications convert the conversation into text [i.e, transcript] and store them as minutes of the meeting. Most of the. rent application only stores the action items resulted from the meeting/discussion. Current application circulates the proceedings of the meeting along with important documents to tie participants of the meeting [both attendants and absentees]. Some of the placation gives an opportune to the participants for creating the discussion item list for the meeting and the agenda for the meeting too.
None of the current applications illustrate the effort spent by participants in attending the meeting, tracking the Line Items, parameterize the central functionalities and synchronize Meetings and Static Testing or Meetings and Reviews etc which are important. If participants/chairpersons of meetings want to check the details of the effort spent during some period [for the \\4iole project or for a particular meeting], current applications do not provide ttie facility to do so. Or if data needed extemal/intemal audit, current applications do not provide the facility for the

extraction & illustration. Line Items are items teat are decided to be lined up and followed [e.g. Action Items in a Meeting]
Current applications do not have tike provision to keep track of the action items produced in the meetings or defect logged in the course of the meetings. By tracking, here it means that: Suppose an Action Item has been logged by the course of a meeting, there is no point in getting the Action Item logged if it'll not be Fixed/Closed. To get the Action Item Pied/Closed it needs to be monitored or tracked.
Sometimes it is required to prevent addition of Action Items or modify details of a meeting after the meeting is over. Current ‘placations do not provide this flexibility.
While Static Testing is being done, for every review/walkthrough/Inspection a meeting a scheduled between the reviewer and the author. Firstly, in this scenario some Action Items are being logged for the meeting and some defects are logged for the review. Secondly, no different effort spent for the meeting and review. Present applications fail in both of the cases: 1) In moping defects with line items and 2) In mapping efforts of Static Testing and meetings [So fails in synchronizing Meetings and Static Testing], Also \neon a Line Item is moped with one or more defects/review items, upon closing Line Item all tfie associated defects should get closed automatically. This facility is not present in current applications.
Line items that are logged in current ‘placations can either be reopened till the Defect/Line Item is in 'Fixed' status or allowed after its closure [depends on parameter], current applications do not provide the flexibility to control the reopening of Line Items/Defects. Moreover, applications present currently do not control the functionality centrally.
Hence, there was an need for better meeting management application which would reduce the effort spend on tracking defects by automating the process and which will have the feature of moping between Review Defects and Meeting Action-

Items and up w*iich would have flexibility in operation or flow of functionalities controlled centrally.
BRIEF DESCRIPTION
In one embodiment of the present technique, a method for managing a meeting is disclosed. The proposed metiiod comprising of several functionalities viz. effort meter functionality for showing collective and individual effort spent in the meeting; parameterization functionality for giving the flexibility to control the behavior of the meeting; synchronization facility for synchronizing of meeting and static testing/reviews; and defect tracking functionality for tracking the defects by sending electronic mails on controllable interval.
In another embodiment of the present technique, a metiiod for keeping track of details of all the Meetings / WaiJcthroughs / Inspections is disclosed. The main objective of this method will be to capture 'Minutes of the Meeting', 'Line Items' (confirmations / defects / confirmations / review items) of tiie meeting, 'Participants' & their 'roles played' and all other possible attributes a meeting can have. This method will help teams / projects in following vp the confirmations / action items / defects / review item discussed in the meeting. This method will have additional functionalities of sending reminders to the persons \’’lom Line Items have been assigned till the Line items are not fixed and once it is fixed reminders will be send to the person who has logged the defect. The status of the meeting will remain Open till all the Line Items are not closed. But if there are no Line Items for a meeting the meeting will get closed automatically once it is created (if the meeting Chair Person agrees).This will help the team leaders / managers / reviewers in following-up or tracking. This method will have functionality of presenting all tfie line items in Inbox of the assignee. In the Inbox, the defects will have first information of 'Defect Heading', 'Raised By" and 'Fixed By' (if any) & 'Closed By' (if any). The method will allow adding / removing / modifying Line Items of a particular project only till the fifth d’ of Meeting Day or the review, so that all Line Items will have to be decided within a fixed time limit [However this time limit can be modified at project level].

DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the foUowing detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
FIG, 1 is a flowchart depicting a method for business flow creation of project/team in one embodiment of the present technique;
FIG 2 is a flowchart depicting a process of meeting/review lifecycle in one embodiment of tiie present technique;
FIG. 3 is a flowchart depicting a method for parameter functionality in one embodiment of the present technique;
FIG. 4 is a flowchart depicting a method for parameter functionality for modifications and reopening of closed line items/defects in one embodiment of the present technique;
FIG 5 is a block diagram of the synchronization between meeting and static testing/review in one embodiment of the present technique;
FIG. 6 is a flowchart depicting a method for report generation functionality in one embodiment of the present technique;
FIG. 7 is a diagram showing how an individual may spend effort in different meetings and different reviews in one embodiment of the present technique;
FIG. 8 is a diagram showing how the resources of a project can spend efforts [in total] in different projects and different meetings in one embodiment of the present technique;
FIG. 9 is a diagram representing the Inbox facility of the method for each user in one embodiment of the present technique;

FIG. 10 is a diagram showing effort spent in attending the meeting employee wise and collective in one embodiment of the present technique;
FIG. 12 is a system illustrating a generalized computer networJc arrangement, in one embodiment of the present technique.
DETAILED DESCRIPTION
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention which is known to the inventors at the tirae of filing the patent ‘plication. Of course, many modifications and adaptations will be ‘parent to ihose skilled in the relevant arts in view of tfie following description in view of tiie accompanying drawings and the upended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificify, depending on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragraphs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since tiie present technique is defined solely by the claims.
As a preliminary matter, the definition of the term "or" for the purpose of the following discussion and the upended claims is intended to be an inclusive "or" That is, the term "or" is not intended to differentiate between two mutually exclusive alternatives. Rather, the term "or" vMen employed as a conjunction between two elements is defined as including one element by itself, the other element itself, and combinations and permutations of the elements. For example, a discussion or recitation employing the terminology "A" or "B" includes: "A" by itself, "B" by itself and any combination thereof, such as "AB" and/or "BA." It is worth noting that the present discussion relates to exemplary embodiments, and the upended claims should not be limited to the embodiments discussed herein.

The present invention relates to Meeting, Static Testing/Review management, and more particularly to a method and system for managing a Meeting/Review and its output.
In one embodiment of the present technique, the method for keeping track of details of the Meetings / Walkthroughs / Inspections is disclosed. The main objective of this method is to capture 'Minutes of the Meeting', 'Line Items' (confirmations / defects / confirmations / review items) of the meeting, 'Participants' & their 'roles played' and all other possible attributes a meeting can have. This method will help teams / projects in foUowang up the confirmations / action items / defects / review item discussed in the meeting. The metfiod will have additional functionalities of sending reminders to the persons vAom Line Items have been assigned till the Line items are not fixed and once it is fixed reminders will be send to the person w4io has logged the defect.
In another embodiment of the present technique a method for managing a meeting is providing effort meter functionality for showing collective and individual effort spent in the meeting. The method also provides parameterization functionality for giving the flexibility to control the behavior of the meeting. The method provides synchronization facility for synchronizing of meeting and static testing/revievre and it also provides defect tracking functionality for tracking the defects by sending electronic mails on controllable interval. The method also provides inbox facility for user to view all assigned defects/Line Items by him/her and to him/her along with other defects in the review item / meeting.
The proposed method makes the static analysis process easy by providing facility for customized reminders for better fracking; by providing Inbox facility for better maintaining and by providing Reporting and Effort Matrix facility for better analysis. The method maintain each and every minute details of meetings held in a project/team and in addition to that it gives a facility to record action item/line items of a meeting [also helps in following up them]. The method can display the efforts spend by different project members in meetings / static analysis [Individually and

collectively] for individual meetings/static analysis or collective one. This can be done through Effort Meter functionality.
The method can control the certain behaviors of the applicarion centrally through parameter functionality. Some of the parameters those control the behavior/action of meetings are; Defect Reminder Flag; Defect Reminder Period, Line Item/Defect logging period, Nfodification for closed Meeting/Review Flag, Reopening of closed Line Item/Defect Flag, Report Gener’on Scheduled Period, Report Output Format, Report Store Directory, Mail IDs etc. So changing tiie parameters will affect all the meetings for the project [Different projects can have different parameter setting].
The Reporting and Inquiry functionality gives user facility to view fetch records by using different filters provided by the application. Some of filters that can be used are; External / Internal Meeting, Type of review [Code/SRS/Test Plan etc]. Single person or multi person review. Effort details. Status of Project / Review Item / Meeting / Line Items / Defects etc.
Referring to Fig l.viiiich is the business flow charts of the project or team creation facility of the method. All the meeting / review details have to be logged under a Project or a Team. For creation of a new Project / Team the owner [Project Leader/Team Leader] has to send a request to the administrator along with the Project Code/Team Code, the list of project members/team members and their roles 100. The Administrator 130 will validate the Project Code / Team Code with the existing data present in database 110. If the requested code does not match with the existing codes then seed data will be created and confirmation will be send to the Leader/Manager along with the default password 120 [vAich has to be changed by users 140 later on]. If the requested code matches with the any of the existing codes then same is be conveyed to the requester 150. Request now should be reinitiated with another Code.
Referring to FIG. 2, vAich is a flow chart of Ihe meeting / review life cycle. After Project Code/Team Code is created as explained in FIG. 1, authorized members or user can log into the application 200 (which is based on the proposed method) and

can add meetings/review items 210. While adding the meeting/review system will check whether Project/Team status and match the name with current database 220. If criteria satisfy tiien error message is displayed 230[Error Message: "Project/Team is closed" or "Review/Meeting exists"] else meeting/review with details [Meeting/Review Details: Participants, Roles, Recurring Meetings, Hours Spend, Venue, Agenda, Minutes of Meetings, Line Items/Defects Present etc] is added 240. If Line Items/Defects Present fl’ 250 is NO then status of the Meeting/Review becomes CLOSED immediately after Review/Meeting is saved 260 else the user is allowed to add defects/line items 270. Reminder e-mails are sent to the assignee of the Line Item/Defect depending on the reminder flag and period set at parameter level 290. On next save of modification if all Line Items/Defects are closed 280 then Project/Team status becomes CLOSED. Depending on Defect Logging Period user will be allowed to log defects after X days of Meeting/Review being logged.
Referring to FIG. 3, vAich is a flow chart of the parameter functionalities of the proposed method. When user tries to log a Line Item/Defect to an alreatfy logged Meeting/Review 300, first the method checks Defect Logging Period at Parameter level 310, If Line Item/Defect Logging Period is zero then method does not allow adding additional Line Items/Defects widi error message "Additional Defects can not be logged" 320. If Logging Period is greater than zero and "Current Date ~ Meeting/Review Start Date < 'Defect logging period" then method allows logging defects 330 else restricts with error message "Defect Logging Period is closed" 340. [Meeting/Review Start Date: This is decided on the Meeting/Review Date mentioned in each Review/Meeting]
A Background process 350 checks every 24 hours the Defect Reminder Flag 360 and Defect Reminder Period 370. If flag is YES and current date is valid according the Period defined reminder as in electronic mails are sent to the assignees of Open defects 380 else no reminders are sent.
Referring to FIG. 4, which is a flow chart of the parameter fimctionalities of the proposed method for modifications and reopening of dosed line items/defects. The method provides the provision of modification of closed meetings 400 and in

some case it is restricted. If the Modify Closed Meeting/Review flag at parameter level is YES 410thenonly users are allowed to modify the project 420.
Similarly in some cases it is required to modify closed Line Items/Defects. This facility is also been provided by tiie method. If the defect has been Fixed 430 then closed and Reopening Closed Defects flag at parameter level method allows reopening the closed defect. If any of the conditions fail the reopening is not possible 440, i.e. if defect has been closed without being marked as Fixed [closed right after being marked as abandoned or invalid] or the flag is set as NO.
Referring to FIG. 5, which is a diagram showing the synchronization between the meeting and reviews. The method provides the facility for synchronizing tiie meeting and review by moping with the help of "M’ ID". In Static Testing life cycle, in most of the cases meeting is arranged to a review [code review or document review]. In order to synchronize the meeting 510 with the review 520 and in order to map these two events mefliod has a unique and simple way of attaching a M’ ID 500 to both Meeting and Review. In the foreground while logging a meeting/review the Meeting ID or Review ID is attached with Review or Meeting respectively. Similarly while logging Line Items/Review Defects, the respective Defect ID/Line Item ID [each Line Item 530 and Defect 540 has different ID] are attached respectively [Line Items are attached to Defects through Key ID]. A Review is not allowed to be linked with multiple Meetings and vice versa. A Line Item 530 can be linked with multiple Defects 540 and vice versa. Line Item can be linked Defecte of attached Review only [same applies for Defects].
Referring to FIG. 6, which is a flow chart of tiie report generation facility of the method. The method provides the option of adhoc report generation [in desired output format and with desired filter] and to generate reports in desired format [with no filter] on a scheduled period [This Report Scheduled Period is mentioned at parameter level] from Meeting Start Date and at the same time mail tiie reports to the concemed people, and method also stores the reports in a desired location of the server as mentioned in the parameter functionality 620.

This process is executed by manually running batch job which checks wiiether Scheduled Date has arrived 600 or not (by checking "Project Start Date ~ Current Application Date" a multiple of Report Schedule Period 610). The list of persons to be mailed is decided on participant list of the meeting or people involved in the review (authors, reviewers etc).
The method has effort meter functionality to display the individual and collective efforts spend in a project or in a team. Referring to FIG. 7, ‘‘ich shows how an individual or person 700 may spend effort in different meetings 710 and in different reviews 720.
The FIG. 8 demonstrates how the resources of a project 800 can spend efforts [in total] in different reviews 820 and different meetings 810.
Referring to FIG 9 which shows the inbox facility of the method for each user. Structurally the Inbox of the user will be divided in two parts: Items assigned to the User 910 and Items assigned by the user or logged by the user 900. The Inbox reveals the heading of the Defect/Line Item, Assigned To 920/ Assigned By 950, Status 930 and Logged/Assigned Date 940 on the directory page of the items.
Best mode of tiie invention
Consider a project wiiich feels need of using this metiiod for managing a meeting. First the manager sends a request to the administrator with Project Code as PRJ_01 along team list and their roles in the application. The adnurustrator checks creates the project code, gives permission to all of the team members and sets a default password and communicates the same to tiie Manager vAio in turn communicates to his team members.
After logging in, the manager first sets up the parameters to suite the project. Some of the sample values are: Defect Logging Period: 3 Reminder Flag: YES Reminder Period: 2

Modification of Closed Meeting/Review: YES
Reopening of Closed Items: YES
Report Schedule Period: 3
Report Format: CSV
Report Directory: D;\Reports\PRJ_0!
Report Distribution List: A@infosys.com; B@infosys.com; C@infosys.com;
D@infosys.com
The first meeting Mi is conducted on agenda XXX. Team decides to log details in the application (application is based on the proposed method). D has not attended the meeting, only A, B, C have attended the meetings. The efforts logged and are different of different resources due to the Line Item assignment and rework activities.

Meeting Ml
EMPLOYEE EFFORT
A 4
B 7
C 9
Table ]
Table 1 shows the employee wise effort spend in a meeting Ml,
On the similar line, meeting M2, M3 and review Rl and R2 were logged correctly in the application.

Meeting M2
EMPLOYEE EFFORT
A 14
B 12
C 4
Table 2

Meeting M3
EMPLOYEE EFFORT
A 13

B 2.5
C 17
Table 3

Review Rl
EMPLOYEE EFFORT
A 16
B 11.5
C 24
Table 4

Review R2
EMPLOYEE EFFORT
A 1.5
B 6.5
C 19
Table 5
Table 2 shows the employee wise effort spend in a meeting M2. Table 3 shows the employee wise effort spend in a meeting M3. Table 4 shows the employee wise effort spends in a review Rl. Table 5 shows the employee wise effort spends in a review R2,
However Meeting M3 and Review Rl are interlinked as for Review Rl the Meeting M3 has been conducted. '
The common hours are as shown in Table 6 with in Meeting and Review [calculated by Effort Meter functionality]

Common Hours M3/R1
EMPLOYEE EFFORT
A 13
B 2.5
C 17
Table 6

The thought of common hours came into picture because each employee has put some extra effort in Review/Rework and ‘art from this spent some hours in meeting. For example resource employee A has spent 3 hours in review and rework and 13 hours. So totaJ effort of 'A' in RJ and M2 will be 16 hours and not 29 hours [i.e. 16+13].
The mapping of Line Items of M3 to Defects of Rl is shown in Table 7.

Line Items of Meeting M1 Defects of Review Rl
Line Item1 Defecti

Defect2

Defects
Line Item2 Defect4
Line Item3 Defects
Line Item4 Defects
Line Items

Here on close of Line ItemI Defecti, Defect2 and Defects will be closed automatically. Similarly on close of Defect6 Line Item4 and Line ItemS will be closed.
Here reminder mails will be coming each combination [e.g. Line ItemLDefectl, Line Iteml:Defect2, Line Item3:Defect5 etc]. There will not be separate mails for Line Item3 and Defects.
Since Defect Logging Period is 3, after 3 days of Meeting is logged, no further Defects or Line Items can be logged.
Reminder mails are sent to the assignees on every second day keeping their assignor in loop till the defects are not fixed and closed.
Here the closed Line Items/Defects can be reopened again as the flag Reopening of Closed Items is YES.
Referring to FIG. 10 wWch is a diagram showing effort spent in attending the meeting employee wise and collective in one embodiment of the present technique.

Reports will get generated every third day and stored in folders for example say D:\Reports\PRJ_01 folder in CSV format and mailed to A@infosys.com, B@infosys.com, C@infosys.com & D@infosys.com mail CDs.
After all the Line Items of meeting Ml are closed, the meeting will get closed. After this some of the meeting details are allowed to be modified since Modify Closed Meeting/Review flag is YES.
After all the Reviews and Meetings are closed the project will be closed after a certain date. After that if someone wishes to add a meeting or review to this project, system will validate and restrict.
Exemplary Computing Environment
One or more of the above-described techniques may be implemented in or involve one or more computer systems. Figure 11 illustrates a generalized example of a computing environment 1100. The computing environment 1100 is not intended to suggest any limitation as to scope of use or functionality of described embodiments.
With reference to Figure 11, the computing environment 1100 includes at least one processing unit 1110 and memory 1120. In Figure 11, this most basic configuration 1130 is included within a dashed line. The processing unit 1110 executes computer-executable instructions and may be a real or a virtual processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory U20 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. In some embodiments, the memory 1120 stores software 1180 implementing described techniques,
A computing environment may have additional features. For example, the computing environment 1100 includes storage 1140, one or more input devices 1150, one or more output devices 1160, and one or more communication connections 1170. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 1100. Typically,

operating system software (not shown) provides an operating environment for other software executing in the computing environment 1100, and coordinates activities of the components of the computing environment 1100.
The storage 1140 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which may be used to store information and wiiich may be accessed within tiie computing environment 1100. In some embodiments, tiie storage 1140 stores instructions for the software 1180.
The input device(s) 1150 may be a touch input device such as a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scanning device, a digital camera, or another device that provides input to the computing environment 1100. The output device(s) 1160 may be a display, printer, speaker, or another device that provides ou’ut from the computing environment 1100.
The communication connection(s) 1170 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal ihat has one or more of its characteristics set or changed in such a marmer as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
Implementations may be described in the general context of computer-readable media. Computer-readable media are any available media that may be accessed within a computing environment. By way of example, and not limitation, within the computing environment 1100, computer-readable media include memory 1120, storage 1140, communication media, and combinations of any of the above.
Having described and illustrated the principles of our invention with reference to described embodiments, it will be recognized that the described embodiments may

be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computing environment, unless indicated otherwise. Various types of general purpose or specialized computing environments may be used with or perform operations in accordance with the teachings described herein. Elements of the described embodiments shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to vMch the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.
While the present invention has been related in terms of the foregoing embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments depicted. The present invention may be practiced with modification and alteration within tfie spirit and scope of the appended claims. Thus, the description is to be regarded as illustrative instead of restrictive on the present invention.

WE CLAIM:
1, A computer implemented method for manning one or more meeting,
the method comprising:
displaying collective and individual effort spent in tike meeting using effort meter functionality;
providing the flexibility to control tike behavior of the meeting using parameterization functionality;
synchronizing of meeting and static testing reviews using synchronization functionality; and
tracking defects by sending electronic mails on controllable interval using defect tracking functionality.
2, The method as recited in claim I, wiremen providing the flexibility to
control the behavior of the meeting using parameterization functionality further
comprising:
logging line items/defects using line Item/defect logging functionality;
allowing to set defect reminder period using defect reminder period functionality;
sending defect reminders using defect reminder flag functionality;
allowing / restricting reopening of closed defect / line items using closed line Items / defect flag functionality;
allowing / restricting modification of closed meeting using modification for closed meeting flag functionality;

generating report using report generation schedule functionality; and
storing and sending the reports using storage directory and e-mail IDs parameter functionality.
3, The method as recited in claim 1, further comprising inbox facility for user to view all assigned defects/Line Items by the user or for the user along with other defects in the review item / meeting.
4. The method as recited in claim I, further comprising review process support functionality for:
storing information of reviews items;
communicating the review items;
keeping track of status of review items; and
providing aid for online review of meetings.
5. The method as recited in claim I, further comprising recording the minute details of the meeting wide storing/maintaining/tracking the Line Items/Action Items of the meetings.
6. A computer program product comprising a computer usable medium having a computer readable program code embodied therein to manage a meeting, the method comprising:
program code adapted for displaying collective and individual effort spent in the meeting using effort meter functionality;

program code ad Ted for providing ice flexibility to control titer behavior of the meeting using parameterization functionality;
program code dated for synchronizing of meeting and static testing/reviews using synchronization functionality; and
program code ad Ted for tracking defects by sending electronic mails on controllable interval using defect tracking functionality.
7. The product of claim 6, further comprising program code adapted for
inbox facility for user to view all assigned defects/Line Items by the user or for the
user along wifely other defects in the review item / meeting.
8. The product of claim 6, further comprising program code adapted for
review process support functionality of the meetings.
9. The product of claim 6, further comprising program code adapted for
recording the minute details of the meeting wiA storing/maintaining/tracking the Line
Items/Action Items of the meetings.