System Dynamics (SD) and Design Structure Matrix (DSM)

    There is a very clever theory that was developed at MIT and put to use by Lockheed Martin and similar firms. This is the Design Structure Matrix concept.
    The other concept is System Dynamics. System dynamics is an approach to understanding the behavior of complex systems over time. It deals with internal feedback loops and time delays that affect the behavior of the entire system.
    There are some claiming this is the next big thing in project management. But like all great academic ideas there is a big dose of truth, and the bigger dose of "a simple matter of engineering to make it work." Not that there aren't brilliant minds working the problem. Tyson Browning is one. Tyson worked at Lockheed Martin, went to MIT and developed some very useful concepts around DSM and project scheduling.
    The SD folks have many good ideas as well. But there is still much work to be done. Here's why:

• The concepts of feedback and rework in SD are not represented on the current scheduling paradigms. In fact rework is not allowed to be budgeted in the same work package as development. This may seem illogical to the SD folks. But "them's the rules."
• The DSM optimization processes are powerfully useful for small projects. The free tools from the DSM site - done in excel - can handle a dozen or so dependencies. Our typical program has several 1,000 activities. While we work very hard to minimize the dependencies, there are still 100's 

What needs to happen on the DSM side, is to turn the tool Latix into a project planning tool. It is a wonderful system architecture tool. Focused on software development. This is their sweet spot market of course. They could probably care less about us planners here in the field. There seems to be a tool - PlanWeaver - that fits the bill, but they seem to have moved on to other products and don't answer the mail regarding their product. I saw a demo a few years back and it was very interesting. Just what a planner would want.
    The SD folks need to do the same industrial scaling up.
    I've used both tools and the paradigms around them to advantage for "test projects." Which brings me to my favorite Yogi quote

In theory there is no difference between theory and practice. In practice there is - Yogi Berra

So when the academics and the theorist DSM and SD to the practice program planning and controls in the same way Latix did for software development we'll be on to something unique and powerful.
    Take a look at these concepts. They will trigger new thoughts:

• What are the interdependencies between tasks or deliverables?
• How can these dependencies be reduced. In the software world this is called "reducing coupling" and "increasing cohesion." This is a software architecture paradigm, that is directly transferable to "program architecture."
• The feedback loops and dynamics behavior of SD is a useful paradigm for production. But for discrete development projects this is a bit more problematical since the core planning tools don't support loops.

It's worth the effort to look further, if only to broaden your horizon. But challenge the academics for sure - those with PhD's behind their names - with the question

Have you applied these concepts to working programs. Program with 1,000's possibly 10's or 1,000's of activities and did it improve the end result in any measurable way?

    The academic approach is critically important. It is necessary before any engineering processes can be generally deployed. So we might be able to answer the question above in the affirmative in the future, but for now us poor slobs in the trenches are still working the Work Package sequence tonight to move the deliverables to the left. We could use some help to get our program on baseline by Friday COB. ;>)