IPMA Home | IPMA News

Association of Data Processing Managers

Meeting Agenda

Arnold's Restaurant
May 6, 1982
12:00 Noon

1. Introduction of Guests
   
   
2. Presentation of Guest Speaker
   Mrs. Karen Paxson, National Plan Co-Ordinators
   * "Washington State Deferred Compensation Program"
   
   
3. Approval of Minutes
   
   
4. Treasurers Report
   
   
5. ADPM Board Report
   
   
6. DPA Announcements
   
   
7. Old Business
   
   • Personnel Liaison
   • Office Automation
   
   
8. New Business
   
   • Election
   
   
9. Correspondence
   
   
10. Other Comments
    
    
11. Adjourn

* Represents a potential supplement to Social Security and is a tax shelter.

ASSOCIATION MINUTES OF DATA PROCESSING MANAGERS
APRIL 8, 1982

1. Call to order - John Aiken.
   
   
2. Introduction of guests:
   Ray DeBuse, Washington Library Network
   
   
3. Joe Coogan introduced our guest speaker for the day. The guest speaker was Mr. Benjamin Knowles. Ben Knowles is president of BSI, a data processing training firm. He has been active in the DP industry since he joined IBM in 1961. His activities include practica1experience as an IBM Systems Engineer and manager; he has taught at IBM, Georgia Tech, and BSI. He was a member of the professional staff of the Federal Reserve Board and now he heads a nation wide training operation which specializes in systems development and project management workshops. BSI stands for Brandon Systems Institute.
   
   TRAGEDIES AND REMEDIES IN PROJECT MANAGEMENT
   
   Prelude to Tragedies -- From the beginning, projects have been late! Everyone wants their system to work right and to be on time -- users, analysts and systems managers. Yet, with all of this motivation, projects still fail -- it's a tragedy. But perhaps the biggest part of the tragedy is that there are reasons for project failure and there are remedies. The tragic reasons for failure fall in two areas -- technical ones and people ones.
   
   Technical Tragedies
   
   "Forgot the Third Act" -- Planners focus a lot of time on estimation. It is a difficult task, but most project plans are doomed before the estimation process begins. There are two tasks which are frequently forgotten! The first of these seems so innocent. Plans are prepared without enough user reviews. User reviews during the problem definition and requirements definition phases are intended to catch misunderstandings and to assure completeness in the design of the system. Without them there will be a tragic increase in the number of changes required late in the project cycle. Changes make projects late.
   
   But this is only one of the key tasks that are left out. The second missing task is blindness! Yes, blindness! All of our lives we have told war stories about program testing. Debugging newly written software is one of the most frustrating and demanding parts of the programmer's work. Despite this experience -- shared by almost everyone in a DP department, there is a persistent belief that the next program will "run the first time" or that patches will "only take a minute". The truth is that testing takes almost half the whole development cycle! One respectable estimate of the time schedule for a typical project is:
   
   1/3 Planning
   
   1/6 programming
   
   1/4 Program and Integrated Testing
   
   1/4 User Acceptance Testing
   
   Certainly many projects vary from this pattern, but the generalization about testing still is relevant. Testing doesn't take "just a minute".
   
   "Blind Hope" -- A second problem in estimation is the assumption that a project member will work at top efficiency. How many times have you looked at a job and said, "I can do that in two weeks". You may have done the job once in two weeks, but it is probable that you remember your "best time". Note that even a champion runner can't duplicate his best time every time! So the estimates based on "best times" are usually wildly optimistic. On short jobs, you can "make up time" at night or on weekends. That's a tragedy -- but there is no way you can finish a longer project on time that way.
   
   People Tragedies
   
   "Teams of Individual Players" -- The first "people" tragedy in project planning is simply lack of teamwork! Most data processing people learn to work alone and don't develop the social skills necessary for effective teamwork. Each person wants his/her own work and wants to do the work his/her own way. Many disputes in DP department are over style, not critical issues. Project teams are put together with little consideration for the compatibility of the members, and rarely are the individuals or the team trained to contribute and compromise. Projects look like four people paddling a canoe, each in his own way! It shouldn't be a surprise that the work is uneven in quality and that the integrated test is a nightmare. . . and the project late.
   
   "The Missing Persons Mystery" -- A project leader will develop a plan based on certain people, but when the time comes to start the project, the people are not free. There are many reasons, but managers frequently won't release some people promised to the project team. Of course, the new project can start shorthanded and "train" the late member(s) or the project can wander until the team is assembled. But, many people, including the user will expect the project to be finished on time and within budget. For the project leader, this is a tragedy, but it can be anticipated in most installations -- so there is a remedy we'll discuss remedies a little later.
   
   "Flashback Teams" -- Most software people have a history of projects they worked on before. When a change, correction or addition is needed, there is a natural tendency to use the one who has experience with the system. This tendency has led to the condition where some managers still work on their own old systems. The obvious problem with a project team "moonlighting" is that you lose the time and attention of your team and the loss is unscheduled (but probably at the worst possible time). Project members work in a frustrated mood because the next phone call may be for them. Any severe problem will make it impossible for the team to get the new system built on time. That is a tragedy.
   
   Project Management Remedies
   
   "Master Task List" -- All project plans depend on a task list, an estimating scheme and some policies/assumptions covering resource utilization. A bad estimate for completing a task will lead to finishing it in a little longer time than planned, but missing a task always means you will miss every deadline. It is critical that a project be planned based on a sound task list. Task lists can force user reviews and adequate testing -- both system testing and user acceptance test. Each installation will need a tailored series of tasks -- this will dramatically reduce the number of naive project schedules.
   
   "User Walk-Throughs" -- Lack of adequate reviews tend to hide problems and omissions as they occur in system development. The walk-through has become the most accepted tool for improving the quality of systems work. Users will add, change and correct statements of requirements. So planning walk-throughs should also include planning time to revise the product. User walk-throughs are a form of preventive medicine that looks for repairs early in the project rather than risking major revision in the late stages.
   
   "Availability Factor" -- Each installation needs to establish an "availability factor" . . . a percentage of time a person will be available when they are dedicated to a project. Rationally this should be the result of record keeping which indicates what percentage of a person's time will actually be available for a new project -- admitting that other activities will distract from the assigned task. In fact, this factor is seldom a policy but rather an experience factor. If no experience is available, a project planner should look at current practices in the installation. Low levels of interruption may allow a factor of 80 percent (meaning that 80 percent of a person's time on a Monday is actually available for a project task). If people are pulled from projects everyday, the "productivity factor" may be 50 percent. Fifty percent is a tragedy, but not planning the interruption makes project planning a joke. There are enough challenges in developing systems without-trying to do it with "phantom" team members.
   
   "Build Aggressive Project Leaders" -- Most project leaders are not leaders. Most see the position as a step promotion, not a change in career. A project leader will frequently plan a project as though it is a "projection" rather than a "plan". When the work doesn't meet the schedule, the project leader simply reports that things are late. This lack of responsibility for deadl1nes is easy to understand. Most data process1ng people tend to work alone and tend to be passive in group situations -- a naturally passive person is a weak leader.
   
   A big reason leaders are passive is that most project leaders have very little control over their work environment. When users don't follow rules and managers are beyond influence, a project leader is pretty weak -- not helpless, but weak. If we want better projects, we have to select aggressive, bright people for the job -- not just a person who deserves a promotion. We can train a person in the use of project management tools and we can coach a person to improve skill, but the desire to lead has to come from w1th1n the individual.
   
   Finally, most of the problems we have discussed require judgment on the part of project leaders. It appears that some project planners never learn the realities of planning -- because so many DP managers still don't know what guidance to give their project leaders in order to be more effective. Solution: Training! An effective project management course should discuss task lists, schedules and budgets, but also realistic problems and solutions. The effective course must stress leadership, the Kind of gutsy, aggressive actions that are essential to make a project succeed in such an unstructured environment as exists in most DP departments. Sometimes several courses or a refresher session will be needed to make the project management process effective and practical.
   
   From the Beginning
   
   It has been clear that many people want systems projects to be completed on time. The project leader has a big job to do, but training and experience (or if not experience, good guidelines and a healthy dose of realism) can lead to a realistic plan and some techniques for dealing with the people problems. Project management need not be a tragedy.
   
   The presentation was followed by a brief question and answer period.
   
   
4. Approval of Minutes - There were no objections or corrections to the minutes. They were approved as distributed.
   
   
5. Treasurers Report - Starting cash: $1,144.91. We received interest of $6.56 and one Forum Vendor fee of $200, bringing our cash to $1,351.47.
   
   Expenditures: $6.00 for speakers lunch. Leaving a cash balance of $1,345.47.
   
   
6. ADPM Board Report - John Aikan gave the report on the Board meeting that was held last week.
   
   
   1. The Board discussed the election of new board members and officers for the ensuing year. This will be discussed further under new business.
      
      
   2. The Board discussed an honorary membership for data processors not employed by the state. It was discovered that the bylaws do provide a category for such people and it is called an honorary membership. The Secretary/Treasurer was directed to submit an invoice to Thurston County Central Services for the dues of the honorary member, Mr. Schmidtke.
      
      
   3. The Board discussed the status of the OIS bill, and it was indicated that when the dust settles from the current Legislative session that the Association should consider seriously the issues which led up to the writing of the OIS bill. It is felt that the Board and the Association should try to pick up the ball on some of the issues which were being addressed by the OIS bill.
      
      
   4. The next Board meeting will be April 19, 1982. If any of the members have any thoughts on issues that should be considered by the Board, John would appreciate hearing from you.
      
      
   5. The Board went on to discuss the fact that their responsibilities include the development of Goals and Objectives for the Association. The Board will therefore be taking up issues such as the OIS questions which were alluded to earlier, another item is that of the Personnel Payroll rules procedures and yet another is how to establish greater participation of members of the Association in its activities as well as to determine why people don't seem to be attending the meetings.
      
      
   6. And finally the Board discussed a letter from Don Brown on the computer systems analyst issues and procedures regarding personnel activities. The Board has asked Don to attend the next Board meeting and discuss these issues with them.
      
      
7. DPA Announcements - There was no meeting so there was no report. The next meeting of the DPA is Wednesday, May 5, 1982.
   
   
8. Old Business:
   
   
   1. Don Brown reported for the Personnel Liaison Committee.
      
      
      1. Involved in the salary survey benchmark finalization.
         
         
      2. Continuing to work on the CSA examining procedure.
         
         
      3. Have had an inquiry to get started on the CSS examining procedure.
         
         
   2. Tom Bennett reported for the Office Automation Committee.
      
      
      1. The Committee has come up with a draft of guidelines to help agencies in their development of their orders for purchasing office automation equipment. These guidelines have been sent to Purchasing for them to review. If you have any desire to review the material that has been prepared, you can contact Mr. Hal Lloyd at Division of Purchasing, Department of G. A.
         
         
      2. John Devereaux provided a briefing to the Committee on communications protocol.
         
         
9. New Business - Mr. Aiken indicated that it was time for the Association to start its annual election procedure. There will be three Board members positions up for election. They are the positions held by Twila Perry, Dennis Jones, and Sam Mayo. As well as the three Board members there will be the position of Program Chairman presently held by Joe Coogan, the position of Secretary/Treasurer presently held by Emory Kramer, and the Newsletter Editor presently held by Barry U'Ren. Mr. Aiken went on to nominate Mr. Applestone and Mr. Wolf to serve on the nominating committee and opened it up to volunteers for the third member of the nominating committee. Emory Kramer volunteered. Mr. Applestone will chair the committee.
   
   Dr. Marti observed that there is a great deal of training activity in the month of June. The reason being that those resources to provide the training seem to have all become available in June. It was also pointed out that the seminar on project management is already filled to capacity and those of us who are interested in participating in this particular training will have to wait for the next scheduled class.
   
   
10. Correspondence - There was no correspondence.
    
    
11. Comments - There were no further comments.
    
    
12. Mr. John Aiken adjourned the meeting.