Most systems engineers and project managers don’t seem to be insane, but many of them seem to be either ignorant or incompetent.

One reason for systems engineers and project managers repeating the same activities and expecting different results pointed out by Niels Malotaux pointed out in his LinkedIn comment was, “ignorance or incompetence” (Malotaux, 2021).  Actually, this observation is not new. Almost 30 years ago, Deming stated that 94% of the problems belong to the system (i.e., were the responsibility of management) (Deming, 1993). Juran, as quoted by Harrington stated that management causes 80 – 85% of all organizational problems (Harrington, 1995) and Cobb’s Paradox stated, “We know why projects fail, we know how to prevent their failure, so why do they still fail?”  (Voyages, 1996).

So, for nearly 30 years even though universities have taught courses in systems engineering and project management as part of degrees and continuing education; many private trainers have offered similar training and professional societies have certified the competency of their practitioners, projects have continued to fail.

The focus on process in systems engineering in accordance with US DoD 5000 Guidebook 4.1.1, which states “The successful implementation of proven, disciplined system engineering processes results in a total system solution that is -Robust to changing technical, production, and operating environments; Adaptive to the needs of the user; and balanced among the multiple requirements, design considerations, design constraints, and program budgets”. The focus is on conforming to the process and not on providing an understanding of the context and the ability to tailor the process as was called out in MIL-STD-499 (MIL-STD-499, 1969).

It seems to me that we are not providing the students with the capability they need in the workplace. As but one example, A 2003 US DoD report on the acquisition of national security space programs stated that, “Inadequate systems engineering in the early design and definition stages of a project has historically been the cause of major program technical, cost, and schedule problems”. The Standards for systems engineering, which form the basis for many process-focused courses (Mil-STD-499 (and subsequent versions A, B and the draft for C) (MIL-STD-499, 1969; MIL-STD-499A,1974; MIL-STD-499B, 1992; MIL-STD-499C,1993) the American National Standards Institute (ANSI)/Electronic Industries Alliance (EIA)-632 (EIA-632,1994) and the IEEE 1220 (IEEE 1220, 1998) Standard do not cover the front end of “the early design and definition stages of a project”.

While DoD 5000 does call out the ‘analysis of possible alternatives’ subset of activities, those activities take place before the DoD 5000.2-R systems engineering process begins (DOD 5000.2-R, 2002).

In my experience, my projects succeeded when I did not (blindly) follow the process, but focused on creating the system the customer needed.

For example, when I first joined academia and had to create a postgraduate course on systems engineering, my systems engineering experience prompted me to ask for the requirements for the course. I was astonished to find out that there weren’t any. However, courses existed and were being delivered, but I had no reference against which to test the knowledge component. I began researching this situation more than 20 years ago, and found only two institutions had a set of requirements delivering bespoke courses to specific customers. The research actually produced a set of requirements based on the literature, workplace scenarios and, while teaching postgraduate courses in systems and software, the experiential knowledge I was teaching when I heard myself telling students that “you won’t find this [knowledge] in the textbooks. engineering and project management. During this research, I also noticed that:

1. Master’s degrees in systems engineering seemed to have a course on the systems engineering process, one on requirements, one on architectures and another on testing, and the rest of the courses offered seemed to be what the academic staff could teach. Although in the last few years a course on Model Based Systems Engineering has been added.
2. Text books covered a similar set of common and different knowledge.
3. Several of the systems engineering academics I knew personally did not seem to understand what they were teaching and taught the book.
4. Courses in project management focused on planning and setting up the project and contained very little about how to actually manage the project once it had begun.

The educational system may be thought of as comprising of a body of knowledge, a delivery system for transferring the body of knowledge to the student, and the remaining support systems to ensure the body of knowledge is current, the learning experience is maximised and the resources needed to provide the education and training are available.

Since projects continue to fail, the educational system has failed which means that the body of knowledge may not be correct (one failure), or there may be something wrong with the delivery mode and the students are not learning what they are being taught (second failure), or both systems have failed.

More than 20 years of research has identified some of the failures in each system and ways to mitigate them.

In the meantime, if you took a course in systems engineering or project management between five and two years ago, thinking back on your experience in the workplace since the course ended, please answer one or more of these four questions.

1. What were the most useful thing(s) you learnt?
2. What were the least useful thing(s) you were taught?
3. What do wish the course had taught you?
4. What years did the course cover?

References

EIA 632, “EIA 632 Standard: Processes for engineering a system“, 1994.

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

DOD 5000.2-R, Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs, US Department of Defense, 2002.

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

IEEE 1220, “Standard 1220 IEEE Standard for Application and Management of the Systems Engineering Process,” 1998.

N. Malotaux, LinkedIN comment, Dec 10, 2021, https://www.linkedin.com/feed/update/urn:li:ugcPost:6874807283222761472?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A6874807283222761472%2C6874809823079211008%29

MIL-STD-499, Mil-STD-499 Systems Engineering Management, United States Department of Defense (USAF), 1969.

MIL-STD-499A, Mil-STD-499A Engineering Management, United States Department of Defense (USAF), 1974.

MIL-STD-499B, Mil-STD-499B Systems Engineering, United States Department of Defense, 1992.

MIL-STD-499C, Draft MIL-STD-499C, Systems Engineering, United States Department of Defense, 1993.

VOYAGES, Unfinished Voyages, A follow up to the CHAOS Report, 1996, http://www.pm2go.com/sample_research/unfinished_voyages_1.asp, last accessed January 21, 2002.