May 1989
May 4, 1989 12:00 Noon
LUNCHEON BUFFET
$5.50
We want your input!
The IPMA Newsletter staff is looking for articles of specific interest to our State information processing community.
Send your drafts to:
IPMA Newsletter Editor
P.O. Box 915
Olympia, WA 98507-0915
AGENDA May 4, 1989
The IPMA Newsletter is published monthly except during August.
Please submit materials for inclusion in the next month's Newsletter no later than the second Friday of the preceding month.
Articles concerning both Information Processing and Management, and announcements of interest to the general membership are accepted in the following formats:
Microsoft WORD
WORDPERFECT
ASCII text
Contact the Newsletter Editor for additional format options:
IPMA Newsletter Editor
P.O. Box 915
Olympia, WA 98507-0915
The IPMA membership has elected the following to serve on the IPMA Board of Directors:
Bob Edwards, Natural Resources
Darrel Rffc, Revenue
Kathy Marston, DIS
Debbie Meach, Personnel
Jim Andersen, OFM
Warren Netherland, L&I
Dale Putnam, DOC
Bob Marlatt, State Patrol
Knowing when to pull the plug
Nine months ago you accepted responsibility for a $500,000 application development project. You saw it as an opportunity for your career when the director of your agency asked you to take on the assignment. Now your staff is telling you that it will take another $300,000 to "turn things around." Without the additional funding there is little hope.
As managers we face these types situations regularly. Additional investment may remedy the problem or create greater loss. If you are like me you often ask yourself: "Am I able to see the situation objectively or am I too close to it to "see" what is really happening?"
Some managers would say, "persevere and get the job done." Others would say, "going forward will only escalate the risk of failure." So what do you do in such a situation?
We all, at one time or another, make the mistake of sticking to a decision until it is proven beyond a doubt we should have reconsidered much earlier. I have heard managers say "I’m paid to get the job done, not ask questions that might scuttle the project. Hell, that would be disloyal to the people working on the project. Besides, I can’t admit I made wrong decisions. I couldn’t live it down." The trap project. expected of is a bit different with each Sometimes setbacks are and when they happen they reinforce us to proceed because they were part of the plan. Other times the "salvage value and closing costs will impede withdrawal." More importantly, managers’ past experience will influence their decisions about a project. If a manager has been a successful risk taker he/she tends to take more risks. If the positive reinforcement pattern was present then, all the more likely the decision will be to persevere. And, of course, it is difficult to see the faults of our own children — it is only natural that we cannot see the faults of our own decisions. Even if we do recognize the errors of our ways, it is hard to admit personal failure.
Add to these "the need to justify one’s actions to others and to appear strong as a leader..." Never mind the pressures that come from those who anxiously await the promised product.
Back off, mate. Step back periodically and "look at the project from an outsider’s perspective." Ask yourself, "If I took over this job for the first time today and found this project going on, would I support it or get rid of it?" If your answer to this question is to get rid of it, then you know it is time to pull the plug.
N.A. "Butch" Stussy, May, 1989
by Don Smith, DSHS
Frequent cost and schedule overruns, high maintenance costs, questionable reliability, and the failure to create programs to specifications have long afflicted large software projects. All of these problems can be trace to difficulties in communication, which are often caused by a lack of discipline in software design and documentation maintenance.
Most present-day structured methodologies encourage drawing diagrams and charts with pencils and erasers. Since human persistence is weak, the diagrams often contain numerous errors, inconsistencies and omissions, and these deficiencies increase exponentially as the complexity of the system increases. Diagrams are slow to draw, cumbersome to revise, and they inhibit experimentation with design changes. As a result, we tend to design into a system errors and poor performance which must be corrected throughout its life cycle.
But then, we know that! It’s been happening for years. Just as soon as the hand-drawn diagrams are considered good enough," we re-draw them with a Mac or PC for readability, file them into binders, and shelve them along with other forgotten documentation volumes. Whatever accuracy that was present in the documentation at filing time is quickly lost due to obsolescence because we will not allocate enough time to maintain them. Instead, our time will always be focused on more visible activities, such as fixing and enhancing software.
One thing is clear: if documentation is not maintained, its value declines rapidly. Documentation must be planned with ease of maintenance in mind. Otherwise, technicians will not willingly maintain it, especially if they perceive it as a waste of time or in conflict with other scheduled activities.
Consultants have made fortunes with new methodologies that promise to solve the documentation dilemma. I suspect, however, that their methodologies simply will not support complex projects like COSMOS. As an example, keeping hundreds of bubbles in data flow diagrams current with an eraser and Page 4 pencil is ludicrous. If good quality documentation is important (and I believe it is), we must reduce our reliance on manual techniques and automate as much of the documentation as we can.
Studies have shown that the proper use of CASE tools can result in a marked improvement in software design and long- term improvement in communication and documentation maintenance. CASE will not design a system, but it can be used to capture a design. It is not a panacea for every software development problem, but it can introduce a systemization and control to the system development and maintenance process.
CASE is not simple a productivity tool. In fact, short-term productivity may suffer because the use of CASE will require more effort to be put into the requirements definition, the analysis, and the design of the application. CASE will have a long- term productivity effect, however, because the principal advantage of the use of CASE is in quality improvement.
Quality is an ambiguous term. We can recognize quality when we see it, but it is difficult to describe it in words. Quality increases as the number of defects decrease. Accurate diagrams have quality. Quality is present if diagrams can serve as an essential communication tool when several people are involved on a project. Diagrams that are an aid to clear thinking and that enforce consistency among the work of all project participants have quality. Quality diagrams can aid technicians to understand how changes will affect upstream or downstream processes. Managers can use quality diagrams to follow project progress and users can communicate their needs more effectively if diagrams are clear and concise. In short, quality is present if diagrams are correct, consistent, complete, and coherent.
Like all tools, CASE requires a commitment and a cooperative effort on the part of management and staff, an investment in time for training and experimentation, and an accepted control structure. The payoff can be significant when compared to typical development projects which sort-cut the analysis and design phases, force premature results early in the life cycle, and require continuous repair throughout the system’s existence.
In summary, although the use of CASE will require effort early in the systems development life cycle, this effort has been shown to improve the quality of the products that are produced and to reduce maintenance requirements later in the life cycle. Perhaps Allen Hershey of Arthur Young said it best:
"CASE will be used if there are:
1. People who emphasize diagrammatic approaches to analysis and design, characterized by products that run on a PC and allow users to draw diagrams that were typically done by hand.
2. People who want to automate as much of the software life cycle as possible, with emphasis on design and construction.
3. People who put an emphasis on work breakdown, or project planning, using CASE to boost the traditional methods of training and support."
Finally, CASE already has a sizeable foothold in our community, and is being used successfully in several agencies. A CASE Users Group meets monthly, usually the second Wednesday of the month. Group members endorse several CASE packages and provide technical assistance to the uninformed. Becoming a member of this group is a good place to start.
April, 1989
by Tom Reslock, IPMA Secretary
1. Call to order at 11:50 a.m. on April 19, 1989.
Attending were Butch Stussy, Kathy Marston, Gary Longmire, Darrel Rffe, Phil Coates, Jim Andersen, Marjorie Shavlik, Will Wolf, and Tom Reslock.
2. While no motions were presented, there was general discussion on the following topics:
Project Manager Series Mailing list availability By-Laws Committee Reports
3. Meeting adjourned at 1:00 p.m.
FORUM ‘89 will take place at the Thee Hotel in Olympia on October 31 & November 1, 1989. This year’s theme will be: NEW AGE TRENDS: The Next Decade.
This year’s committee members are:
Carol Geddes, U&T
Adrenne Sanders, L&I
Rebecca Stumpf, DIS
Tamara Ward, Fisheries
Louis Orlando, IPMA/DIS
R.W. "Skip" Grover, DSHS/OIS
Ruben Maham, DIS
Javad Naini, DIS
Don Smith, DSHS/COSMOS
Greg Swarts, OAC
Dr. Ruben Marti, ED&TD, Chair
Approach your committee member with a new idea for the FORUM!!
March 23, 1989 ISB Excerpts courtesy of Bob Payne
The ISB at their March 23 meeting accepted recommendations from their subcommittees and PPD staff dealing with human resources issues, data resources, and acquisitions.
The Human Resources Subcommittee, chaired by Joe Dear, presented recommendations calling for DIS to work with the Information Processing Managers Association (IPMA) and the Department of Personnel to refine and implement a classification structure for information processing managers and to evaluate manager salaries.
The Data Resource policy was approved per the recommendation of the Data Resource committee, chaired by Mary McQueen. However, it will not be implemented until the ISB has approved standards and implementing procedures. There will be a status report at the May 25 meeting. The standards and implementing procedures will be presented at the July meeting. PPD staff will be working with the Data Resource Management Advisory Committee and ISB subcommittee to develop these standards and implementation procedures. The PPD staff proposed acquisition policies were approved by the members with the contingency that they be implemented following more extensive review of the proposed procedures by agencies and vendors.
The new policies will implement a revised delegation of acquisition authority level and process. Staff will present the implementing procedures at the May meeting with an opportunity for vendors and agencies to provide comment.
In other business, the PPD staff presented a brief summary of the lessons learned from the feasibility study process and a work plan to refine the feasibility study procedure.
Please contact PPD staff if you would like additional information on any of these issues.
(this space reserved for member-submitted discussion of management topics, and review of technical advances)