What Do You Mean You Can’t Tell Me If My Project Is In Trouble?

Part 3

Please note this is the third part of a long article. The article starts at this page.

The Chaos Study

The (Chaos, 1995) study served as a reference. It had identified some major reasons for project failure. The five risk-indicators in this study that were chosen as the most important causes for project failure also appear on the Chaos list of major reasons for project failure. The correlation between this study and the Chaos study is shown below. While “resources are not allocated well” did not show up in the top seven lists of this study, it was fourth in the tally. Thus, this study supports the findings of the Chaos study.

Presence of Risk-Indicators in ISO 9001 and Software-CMM

1. Political considerations outweigh technical factors
2. Unrealistic deadlines - hence schedule slips

Thus, conformance to either or both Quality standards does not ensure mitigating these risks.

Risk

Section 4.x of ISO 9001

Software-CMM

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

1

2

3

4

5

1

x

x

x

x

x

x

x

x

4

x

x

x

x

x

x

x

x

x

x

x

x

5

x

x

x

x

6

x

x

x

x

x

x

x

x

x

x

x

16

x

x

x

x

x

x

25

X

x

29

30

X

x

x

x

x

x

x

x

33




---




The Development of Metrics to Indentify the Presence of These Indicators

The large consensus on the major reasons for project failure seems to show that if we could remove these reasons, projects would have a greater probability of success. The (Chaos, 1995) study showed that projects tended to succeed if the opposite of these risk-indicators were present (e.g., good requirements instead of poor requirements). The (Voyages, 1996) paper stated that the causes were known, but it was unclear if the solutions could be implemented. Thus it seems that the current metrics paradigm is focused on measuring the wrong things and needs to be changed to develop metrics to show the presence or absence of the major risk-indicators identified above and any other known as major causes of project failures (risk management). Consider ways metrics can be developed for the following risk-indicators:

• Poor requirements: Current requirements management tools do not indicate if requirements are defective. That is, if they violate the requirements for writing requirements (Kasser, 1995, 166). This risk can be mitigated by teaching personnel how to write good requirements using techniques such as a “requirements workshop” (Kasser, 1995, 259). Metrics can then be developed to measure the number of defects in requirements documents.
• Failure to communicate with the customer: This activity mitigates the risk of creating poor requirements and failing to cope with changes. This activity can be part of the process and is covered in ISO 9001.
• Lack of, or, poor plans: A project plan was recognized as a critical document as far back as the U.S. Military Standard for Systems Engineering Management (MIL-STD-499A), yet many software projects still either do not have one, or ignore it. Since it must be a living document (Kasser, 1995, 163), metrics need to be developed to monitor the use/updates of the plan during the SDLC.
• Lack of process and standards: These are covered by the Software-CMM the ISO Standards covering the SDLC.
• Lack of management support: This risk is recognized as the prime reason that TQM fails. We need to develop metrics to measure the degree of visible management support.
• Failure to validate original specification and requirements: Having a process and including this activity as a step in the process can mitigate this risk.
• Political considerations outweigh technical factors: Metrics need to be developed for this risk.
• Resources are not allocated well: This risk follows on from the lack of, and use of a plan. Having and using a plan will mitigate this risk.
• Changing requirements and specifications: (Kasser, 1997) presented a simple Categorized Requirements in Process (CRIP) method for monitoring progress and making both progress and changes in requirements readily visible to top management and any other interested parties. The CRIP approach can easily be built into requirements management tools.

However, just changing the metrics paradigm may not be the complete solution. Cobb’s Paradox (Voyages, 1996) states “We know why projects fail, we know how to prevent their failure, so why do they still fail?” Now a paradox is a symptom of a flaw in the underlying paradigm. Perhaps Juran and Deming provided the remedy. Juran as quoted by (Harrington, 1995, 198) stated that management causes 80 to 85% of all organizational problems. (Deming, 1993, 35) stated that 94% of the problems belong to the system (i.e., were the responsibility of management). In this survey, both managers and non managers tended to disagree with the two management risk-indicators (#9 and #10). Several respondents with many years of systems or software engineering experience did not even recognize the term “SDLC.” It is difficult to understand how Information Technology managers can make informed decisions to mitigate technical risks if they don’t understand the implications of their decisions. The resolution of Cobb’s paradox may be to develop a new paradigm for an information age organization which performs the functions of management without managers.

---

Deficiencies in the Study

The following deficiencies are present in the study:

1. The sample size is small.
2. The level of expertise of the respondents is unknown.

---

Conclusions and Recommendations

Except for poor requirements, none of the risk-indicators identified by this study are technical. Thus, the findings support:

• resources spent mitigating technical risks are wasted unless the major risks discussed in this paper are also mitigated. Thus, it is critical to develop and use good metrics for them.
• the need for continual training to provide managers with the skills to become capable of effective technical management.

Areas For Further Study

• which risk-indicators have greater effect on the schedule and budget.
• correlate the general agreement with the risk-indicators to specific ones. For example, did those who agreed with Apolitical considerations outweigh technical factors@ agree with more risk-indicators than those who didn’t agree with it.

About the Authors Dr. Kasser has more than 25 years of award winning experience in management and engineering. He teaches software IV&V and software maintenance at the University of Maryland University College. He is a recipient of NASA’s Manned Space Flight Awareness (Silver Snoopy) Award for quality and technical excellence. He is a Certified Manager and a recipient of the Institute of Certified Professional Manager's 1993 Distinguished Service Award. He is the author of Applying Total Quality Management to Systems Engineering published by Artech House and more than 30 journal articles and conference papers. His current interests lie in the areas of applying systems engineering to organizations and using technology to improve the practice of management. Victoria R. Williams is a Senior Consultant at Keane Federal Systems, Inc. in Rockville, MD. She has 18 years of award winning experience in various aspects of systems engineering. She has received many awards and commendations from employers and customers including Computer Data Systems Inc., the Department of the Navy, Naval Air Systems Command, and the Department of the Army. She has written software in HTML, PowerBuilder, Java, FoxPro and Visual Basic. She has performed object-oriented analysis and design in an effort to reengineer an operational legacy system. Her previous experience includes project management support for the Department of the Navy, systems and software engineering for the U.S. Navy, the Royal Australian Navy, and the U.S. Military Sealift Command. She is also trained at CMM Level 2 and is currently working on her Master of Science Degree in Computer Systems Management in the Graduate School of Management and Technology at the University of Maryland University College in College Park, Maryland.

Contact Information Joseph Kasser, DSc. , CM., CEng. University of Maryland University College University Boulevard at Adelphi Rd. College Park, MD 20742-1614 Phone 301-985-4616, Fax 301-985-4611 E-mail: [email protected] Victoria R. Williams Keane Federal Systems, Inc. 1375 Piccard Drive, Suite 200 Rockville, MD 20850 Phone 301-548-4450, fax 301-548-1047 E-mail: [email protected], [email protected]

---

---

References


Brooks, F.P., The Mythical Man-Month Essays on Software Engineering, Addison-Wesley Publishing Company, Reprinted with corrections, 1982.

Carnegie Mellon University, The Capability Maturity Model: Guidelines for Improving The Software Process, Addison-Wesley, 1995.

Cuppan, C.D., Capability Maturity Model (CMM) Characteristics and Benefits, tutorial presentation at the Defense Mapping Agency, 2 June 1995.

Deming, W.E., The New Economics for Industry, Government and Education, MIT Center for Advanced Engineering Study, 1993.

Drucker, P.F., Management: Tasks, Responsibilities, Practices, New York, Harper & Roe, 1973.

Harrington, H.J., Total Improvement Management the next generation in performance improvement, McGraw-Hill, 1995.

Kasser, J.E., Applying Total Quality Management to Systems Engineering, Artech House,1995.

Kasser, J.E., “What Do You Mean, You Can’t Tell Me How Much of My Project Has Been Completed?”, The International Council on Systems Engineering (INCOSE) 7th International Symposium, Los Angeles, CA., 1997.

The Standish Group, Chaos, http://www.pm2go.com/, accessed March 19, 1998.

The Standish Group, Unfinished Voyages, http://www.pm2go.com/, accessed March 19, 1998.

Ward, P.T., Mellor, S.J., Structured Development for Real-Time Systems, Yourdon Press Computing Series, 1985.