So what should we be teaching systems engineers and project managers?

In my previous blog I pointed out that one of the reasons for project failures was that we were not teaching the right things to systems engineers and project managers.  This leads to the question, what should we be teaching them?

If you ask most systems engineers as to what the system they are developing should do once it is placed into operation, they will tell you to look at the requirements. So when I started teaching systems engineering more than 20 years ago that’s what I did. I didn’t find any requirements for what should be taught, which I thought was ironic since there were a lot of courses being taught. And of course now there are a lot more.

However, a more informed answer might be, “they need to learn how to become successful systems engineers”. Which leads to the next question, what makes a systems engineer successful?

One answer to this question can be found in the latest publication by Prof Howard Eisner, who states the seven attributes of today’s successful systems engineer are taken to be (Eisner, 2021, page 15):

1. synthesizer
2. listener
3. curious/systems thinker
4. manager/leader
5. expert in systems engineering processes
6. expert in domain knowledge
7. perseverer

These answers which are derived from a look at a variety of super systems engineers, what they did and how they did it and what they wrote about what they did, are summarized in his book.

When I read the book, my reaction was, “apart from a short course on the systems engineering process, most courses don’t teach any of the attributes“. This reaction was based on experience and a review of what a small sample of education and training providers posted on their public web sites.

Given that training courses of various breadth and depth aspects of systems engineering might last up to a week, and university courses have about 13 sessions in a semester, and that instructors teach what they (are supposed to) know, it should be no surprise that all the courses contain a wide variety of topics with some degree of overlap as shown by a study in 2013 (Kasser and Arnold, 2013). There is rarely time to teach the soft attributes or share real-world experience in the course. And what’s more, even if the need for solution domain expertise is recognized, the need for expertise and domain knowledge in the problem and implementation domains as well as the solution domain is still generally not recognized.

Most of the books and courses on project management cover the knowledge needed to plan a project. However project managers spend most of their time managing the project to conform to a previously planned cost and schedule which means coping with factors that cause deviations from the plan leading to cost and schedule overruns; factors that may be technical or people related; activities for which they have little if any preparation.

Most systems engineers don’t realize that in general, the courses are based on the “Standards” for systems engineering which include some poor systems engineering practice. So the courses teach and perpetuate poor systems engineering practice. For example, when I audited a well-known instructor’s course back in 2008, I noted he taught his students, that when they received a set of requirements from the customer, requirements analysis meant they would have to work out what the customer really wanted.  Yes, this is often a real-world situation and the students need to learn to deal with it, but they also need to learn how to work with the customer to create good well-written requirements in the first place; something that was not in his course.

When the “Standards” were written, the writers documented what they were doing (“as-is” in BPR terminology). This is why the different “Standards” focus on different aspects of systems engineering. The authors did not stop to think about whether they were doing the correct things. They don’t seem to have created a reference (“to-be”) model of an ideal systems engineering process, or realize that they were following a version of the generic problem-solving process other than those who wrote IEEE 1220 which stated that, “the systems engineering process is a generic problem-solving process” (IEEE 1220, 1998: Section 4.1).

Moreover the often-used Standards for configuration control and other “ilities” seem to have been written by people who were dealing with the outputs of poor systems engineering practice, so they processes that should have been done by systems engineers earlier in the schedule included their Standards. For example, Configuration Management (CM) is defined as, “a field of management that focuses on establishing and maintaining consistency of a system’s or product’s performance and its functional and physical attributes with its requirements, design, and operational information throughout its life” (MIL-HDBK-61A, 2001). Reads like a definition of systems engineering to me. So we now have a situation in which systems produced according to the Standards have built-in process overlaps with other streams of work with the potential for causing turf wars and personnel conflicts as well as institutionalizing poor systems engineering practice.

Having trouble with these statements? Thomas Kuhn wrote that it was difficult for people to unlearn things they knew to be correct (Kuhn, 1970). And, Mark Twain is often reputed to have said, “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so” (O’Tool, 2018).

If you want to be an outstanding systems engineer or a project manager open your eyes, look at the inconsistencies that are glossed over in the current process-focused paradigm. Think about what you need to know and what you have been or are being taught. And start asking questions.

If you are a project manager or a beginning systems engineer and want to learn a little more about systems engineering you could read”

• Pascal Bohulu Mabelo’s latest book, “Managing Engineering Processes in Large Infrastructure Projects” (Mabelo, 2021).  Available in hardcopy only at this time, it’s written in a storytelling style that you might have to get used to, but it contains a literature review of systems engineering and its various processes.
• My book, “Perceptions of Systems Engineering” (Kasser, 2015) written in the traditional textbook format based on applying systems thinking to systems engineering

In fact I recommend you get both books, read them and if you can think about what you read, you ought to be able to ask your instructor or coach some good questions. If you can’t wait for books to be delivered in order to start thinking about the current paradigm for yourself, if you send me an email request I’ll send you a PDF copy of “Perceptions’.

Have a happy and healthy 2022.

Why not join me twice a week live via Zoom on Mondays and Thursdays and let’s talk about what you are reading and thinking.

References

Eisner, H., What makes the systems engineer successful? Various surveys suggest an answer, CRC Press, 2021.

Kasser, J., Perceptions of Systems Engineering, CreateSpace, 2015

Kasser, J. E. and Arnold, E., Benchmarking the Content of Master’s Degrees in Systems Engineering in 2013, proceedings of the 26th International Symposium of the INCOSE, Edinburgh, Scotland, 2016.

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

Kuhn, T. S., The Structure of Scientific Revolutions, The University of Chicago Press, 1970.

O’Tool, G., It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So, Quote Investigator®, https://quoteinvestigator.com/2018/11/18/know-trouble/, accessed January 27, 2022.

Mabelo, P.B., Manufacturing Engineering Processes in Large Infrastructure Projects, Cmbride Scholars Publishing,Newcastle upon Tyne, England, 2021

MIL-HDBK-61A, Military Handbook: Configuration Management Guidance, Department of Defense, 2001.