AD-00030

Software development projects have increased in number due to rapidly changing technology and user demands for easier to use, complex software applications.  Therefore software developers need to constantly review not only the quality of products they develop but also the quality of processes they follow during their software projects.  The following type of project review, which is a day long meeting, was used repeatedly by groups of software developers, at a major mainframe and client server software development lab, both during and after software projects.  Depending on the size or complexity of the project, the size or maturity of the project team, and/or the amount of problems occurring there would either be both a facilitator and a chauffeur or just a chauffeur.

At the beginning of each meeting the project lead presented a brief description of the purpose of the software application or revision.  Also given was a presentation of the project scope, budget, resources, and timelines.  This information was shown using presentation and project management software applications.  These applications, which were initialized right from the Meetingworks agenda, were left running in the background during the rest of the meeting so people could refer to the information if necessary.

The next item on the agenda was a collection of thoughts, using the Generate tool, about "what is going well" if the review was conducted during the project; or "what went well" if the review was conducted after the project.  The thoughts were categorized using the Organize tool and printed for use later in the meeting.

Then an outline of categorized problems, which had been created at a previous project review, if there had been one, were reviewed (using the Organize tool) to determine if they were still problems and removed from the list if already handled.

Participants then created lists of any new problems using Generate.  The new problem list was opened in an Organize window (next to the old, categorized problems outline, if there was one from a previous review).  The new problems were discussed and clarified so that succinct, understandable problem statements were established.  New problems were then moved into categories to create an outline.  If this was not the first review then the new problems would be moved into previously established categories and, if necessary, new categories were added to the outline.

For each category the problems were prioritized by ranking them in order of most important to least important to correct, given the project scope, budget, resources, dependencies, and timelines.  This was done using the Evaluate tool.

The group broke into subgroups, each working on a category or categories of problems, to prepare action plans to correct the new problems.  The groups all started with the highest ranked problem in each category (along with any others that made sense to work on with the highest ranked one because of timelines or dependencies).  A specific amount of time was allotted for this part of the agenda so people worked through as much as they could in that timeframe.  The printed lists of thoughts about what was good about the project were used for reference at this time.  For each problem an overall action (purpose) statement was created, along with individual task statements with assigned timeframes and responsible parties.  One person from each subgroup input the action plans within a multiple topic Generate (where all of the new problem statements were the topics).  The information from the Generate step was then reviewed by the whole group using the Organize tool.  Changes and clarification items were input by the chauffeur.  Action plans were printed and distributed so the responsible parties could begin or continue working on them.  The next project review meeting date and time were reiterated, any subgroup meetings needed to continue on action plans were set up, and the meeting was adjourned.