Everyone on every project should take responsibility for giving suggestions about enhancements to the methodology administrator. The methodology itself should contain an explicit task for post-installation review, when customer satisfaction with the application is measured and methodology enhancements are sought from the project team.
Other questions related to process improvement and project management include:
§ How was the time spent on the project divided among the various tasks?
§ If the project is repeated, would a different amount of time be spent on such tasks as requirements definition?
§ Did the time spent on every task contribute to the quality of the product? If not, should the task be changed or deleted, or should the adaptive questionnaire be changed to exclude this task in similar future projects?
§ Was there anything needed for the project that was not covered in the methodology? If so, should it be added?
§ How many times were the estimates of effort and delivery date revised? How could more realistic estimates have been made?
§ As well as these questions about the nature of the technical process, project managers should ask questions about its output:
§ What measures of deliverable quality are relevant?
§ What defects in deliverables were found, during development and after installation?
§ How is customer satisfaction measured, other than in post-installation review?
§ With a defined process and metrics of success, project managers can move on to ask more profound questions about the culture and whether the process should be continuously improved or obliterated and replaced:
§ Does the incentive climate focus on activity or on results?
§ How are project teams and project managers rewarded for meeting user needs for timely quality applications?
§ What penalties are there for people who disrupt the process, for example, users who constantly change their minds about what they want? The best methodology and process management tools may be useless if there is no incentive for anyone to deliver quality.
Process Management and Business Process Reengineering
Process management allows senior managers to contemplate business reengineering and ask, “Should there be an application development function in this organization?”
Business process reengineering “doesn’
t mean tinkering with what already exists or
making incremental changes that leave basic structures intact. … It means asking the question: ‘
If I were recreating this company today, given what I know and given current technology, what would it look like.’
… It involves going back to the
beginning and inventing a better way of doing work.”[5]
The “better way of doing work” is, of course, a new methodology. How does management encourage the staff to work with a new methodology? By rolling it out in a process management tool. Thus, the cycle is complete — process improvement needs better estimating, better estimating needs meaningful project history, project history needs a standard chart of accounts, a standard chart of accounts must come from a methodology, a methodology needs to be automated with a process management tool, and a process management tool provides the basis for process improvement.
[5 ]Hammer and Champy, p. 31.
BIBLIOGRAPHY
Brown, D. “Understanding and Using Function Points.” Software Engineering Strategies, 1, no. 5, 1993.
Release 3.4. Westerville OH: International Function Point Users Group, 1992.
NOTES
1. C. Jones, Applied Software Measurement, New York: McGraw-Hill, 1991.
2. Jones, pp. 127–128.
3. M. Hammer and J. Champy, Re-engineering the Corporation, New York: HarperCollins, 1993.
4. K.D. Saracelli and K.F. Bandat, “Process Automation in Software Application Development,” IBM Systems Journal, 32, no. 3, 1993.
5. Hammer and Champy, p. 31
Chapter 8: Project Meetings: A Communication and Coordination Tool
Ulla Merz
OVERVIEW
Good coordination is an important factor in project success. In turn, coordination success is based on interpersonal networks and informed project members, as reported in the survey study “Coordination in Software Development” by Robert E.
Kraut and Lynn A. Streeter.[1]
Data from that same survey of 65 software projects suggests that personal communication is important for successful coordination in software development projects. The drawbacks are the high cost of one-on-one interaction and the lack of tangible results. The same survey also found that project members do not find formal impersonal communication, such as written requirements documents, source code, and data dictionaries, very valuable.
Project meetings are an opportunity to combine the benefits from personal communication and formal impersonal communication. Meetings are a place for personal interactions. Documenting the outcome of a meeting by writing meeting minutes or updating a design document realizes the benefits of the work accomplished in the meeting.
[1 ]Robert E. Kraut and Lynn A. Streeter, “Coordination in Software Development,”
Communication of the ACM, Vol. 38, No. 3, March 1995.
WHAT IS WRONG WITH MEETINGS
Review the following questions and check the ones that can be answered with a
“yes.”
§ Have you attended meetings where you did not get the information you needed?
§ Have you attended meetings where the atmosphere was hostile or abusive?
§ Have you attended meetings where most of the decisions were postponed?
§ Have you attended meetings where the purposes was unclear?
In all the cases where the answer was a yes, the meeting was not an effective coordination tool.
MAKING MEETINGS A VALUABLE COMMUNICATION
TOOL
What do meetings that one experienced as valuable to attend — meetings one keeps going back to — have in common? Here are some responses people gave in a survey for a project post-mortem:
§ The meetings address issues of concern.
§ It is important to get everyone face to face, but also limit the time spent doing so.
§ Everyone gets the same information.
§ Everyone is made aware of the changes.
Personally, the Sunday church meetings and the weekly toastmaster’
s meetings are
meetings the author keeps going back to, because they seem valuable. Effective meetings have several things in common:
1. The needs of each participant are met.
2. Concerns important to the group as a whole are addressed.
3. The purpose is clear.
4. The atmosphere is comfortable.
The following sections discuss what can be done to make meetings an effective communication tool:
§ Identify the purpose of the meeting
§ Define the deliverables or work products of meetings
§ Create the atmosphere/context for success
Define the Purpose of the Meeting
There are mainly three types of meetings:
1. Meetings for exchanging information
2. Meetings for making decisions
3. Meetings for solving problems
Examples for each are (1) the project status meeting, which has the purpose of exchanging information; (2) scope/issue meetings, which have the purpose of making decisions; and (3) design meetings, which have the purpose of producing a quality product design.
An information exchange meeting achieves its purpose if all team members get the information they need to proceed with their work. Information exchange meetings are the place to disseminate product requirement changes, raise technical issues, announce changes in the lives of project team members, and report on risks that have either increased or decreased. Information exchange meetings are great forums for team members to use each other as sounding boards for their upcoming decisions.
An important part of a decision- making meeting is to provide participants with the facts they need to make decisions. A decision- making meeting does not achieve its purpose if the decisions are postponed. The purpose is to arrive at decisions that all participants agree to and can support.
The purpose of a problem-solving meeting is not only to develop a solution, but also to formulate jointly a common problem definition. It is important that all meeting participants have a chance to make a contribution. Just as with decision- making meetings, the purpose of problem-solving meetings is to decide on a solution.
Once the purpose in general has been defined, the next step is to prepare a specific agenda. An agenda is an outline of the content for the meeting. What needs to be on the agenda depends on the task at hand. For example, the agenda for a change control board meeting will list the specific cases to be discussed. It also may contain a discussion and vote on procedural changes and an announcement of a personnel appointment. An agenda for a status meeting will list important milestones, such as the documentation freeze, the beta release, and the version of the upcoming software build.
When preparing a meeting agenda, ask questions that will help identify the topics to be addressed. For example, when preparing an agenda for a status meeting, ask the following questions:
§ Which information is needed to begin work on upcoming tasks and who needs it?
§ Which external information and decisions have an effect on the project?
§ Which deliverables require coordination between several team members?
§ Are there any concerns that were brought up?
§ Which activities and tasks have been worked on?
Define the Work Products That Result from Meetings
No matter what the kind of meeting, it is necessary to record the information shared and the outcome of the meeting in meeting minutes. Without meeting minutes, all work accomplished in the meeting is lost. Having a person record the information shared, the decisions made, and the problems solved relieves other participants from keeping records themselves and allows them to participate in the meeting.