Systems Thinking in Project Management

The term "system" is often used to describe a collection of processes. It is used in the agile literature and other software development and project management descriptions. However, it is not always used in the form defined by Systems Engineers.

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.

This is an INCOSE definition. There are shorter ones. My favorite is

Systems engineering is the development of products and processes as a single effort.

The point of these two definitions is that when someone speaks of "systems," they don't always speak of the processes that go along with the products. Separation of product from process is the basis of some "world views." This is not a system view, however.

Agile Project Management and Systems View

In the search for a definition of Agile Project Management, the Declaration of Interdependence proposed a set of principles. Are these principles compatible with the systems engineering view? We are, in fact, "engineering a system" when we develop software and manage the project that develops the software.

• Realizing successful systems (products) is undoubtedly the goal.
• Focusing on customer needs is essential.
• Defining customer needs is the result of requirements elicitation and management.
• Doing this early in the system's life cycle is critical to meeting those needs through a successful realization.
• Synthesizing the design is an essential activity in any development project. This is what separates operations from development.
• Validating the complete system provides the means to end the project

So why does the Agile Project Management world not yet have a connection to the Systems Engineering worldview? It would seem a natural connection. A much better connection than to the linear, silo-focused set of processes described in PMBOK. In PMBOK, the customer is connected to the process loop at the start and end.

More work needed

Definitions of terms like value, rapid, early, customer, frequent, innovation, performance, effectiveness, and reliability are used by the DoI. When these terms are given "units of measure," and those units of measure are connected to analytical outcomes for the business, Agile Project Management will have moved into the system engineering domain. A domain where the "trade space" of decisions is where management and engineers live every day. Asking questions like:

• How does this action or technology benefit our project in some measurable way?
• What risks are reduced, enhanced, or made visible by this technology or action?

Questions that continually ask, "How do we know that customers will get what they asked for?"

To answer this question, we need to know what done means for decision-makers in meaningful units of measure.

That DONE starts with What Capabilities the project needs to produce to accomplish the Mission or fulfill the Strategy being addressed by the project.

Capabilities-Based Planning

Let's start with an overview of Capabilities-Based Planning in the Project Management domain

Here are some more newsletters on Capabilities-Based Planning

• Capabilities-Based Planning is the Foundation of Project Success
• A Compendium of Blog Posts on Capabilities-Based Planning
• Capabilities-Based Planning: A Full Primer for Better Project Definition
• Capabilities-Based Planning (Wright Brothers)
• Capabilities-Based Planning (Part 2)
• Capabilities-Based Planning (Part 3)