System Dynamics in Project Management

Project Management Lifecycle
Project Management Lifecycle (Photo credit: IvanWalsh.com)

The following is taken out of the summary of an old PhD thesis from 1984(!) by Abdel-Hamid:

http://dspace.mit.edu/bitstream/handle/1721.1/38235/12536707.pdf

The results come from the modeling of a generic project including interactions with the “outside” e.g. management – based on interviews and a case-study:

  1. Different schedules create a different project. i.e. you cannot decide, if one method is more accurate.
  2. The optimal QA expenditure level is 16% of development days
  3. Brooks’ Law is not universal: adding more persons makes a project more costly, but not necessarily to complete later

Summary of a fruitful LinkedIn discussion

Ref: How Does It Help?

Jay: From a systems thinking perspective, the entire project can be viewed as an integrated “system,” where each of the aspects/elements identified in the framework is a component of the overall system.

Jay:  Linking the simulation activities/effort to the actual project management activities can potentially overburden the PM process with tasks and activities that are not in keeping with the need to manage the project.

T.A.: As project managers begin to think about the goals of the project, they should also think about how the finished product meets customer needs, how it satisfies corporate goals, how it compares to competitive products, and it might be managed so that it motivates co-workers.

Mirko: Good project managers (PM) will intuitively “model” the project as a system while thinking about the plan/risks etc. With System Thinking the PM scope is extended to the “outside” and the “how”.

Jonathan: Projects often coexist with other projects. They may even compete with them for resources. Would it not be beneficial to understand the dynamic that determines how those resources are applied?

Duane: “Setting up” a project is not a PM task. That is more the realm of a business analyst or product manager, with the guidance of an architect. A project manager is typically not even assigned until the project has already been “set up” and approved.

Jay: According to PMI’s structured approach to conducting a project, there are five stages: Initiation, Planning, Execution, Monitoring and Controlling, and Closing. It’s actually in the first stage when a project begins to take shape against the requirements/needs of the business. And it’s at that very beginning point where a Project Manager needs to be present and fully participative… even before a project team is selected. In the context of best practices, the PM would play a key role (working together with a project sponsor and key subject matter experts) in helping to build the case-for-action (aka project justification or business case).

Mirko: In a “traditional” (PMI) setup the PM will lead all roles and takes over the customer/line communication. In alternative setups, e.g. Scrum, these responsibilities may be split between product owner and scrum master.

Duane: I’m a proponent of the focus of ST at the enterprise level (and pre-project level) rather than the project level.

Related articles

System Dynamics in Project Management

Little Man Computer

From WikipediaThe Little Man Computer (LMC) is an instructional model of a computer, created by Dr. Stuart Madnick in 1965.

It’s nice to teach kids computer architecture, however for my 9 years old son, was quite hard to do.

I’ve tried out the following implementations:

Little Man Computer

Code Kata – Compare Haskell and C++

English: The Haskell Logo, a stylized >λ= . Th...
(Photo credit: Wikipedia)

After many years of experience in object oriented programming and just talking about functional programming, I decided to get a hands-on experience by inventing the following code kata:

It’s about simple classes for agents communicating via FIFO stacks (let’s call them pipes).

The topology of the agent communication should be defined separate from the agent implementation.

The outputs are the following examples

My experience was

  • the functional code is more compact
  • it took me much longer to determine the right functional structure (but this might be due to less experience)
  • side effects can be handles much easier in C++: in the example it’s necessary to have all agents in one list. The list can be easily build in the C++ constructors, in Haskell one need to add them separately (agents = [producer, modifier, consumer])
  • C++ is stronger in class polymorphism: defining the parent object (data Agent), all child objects (ProducerModifierConsumer) need already be known at parent definition
  • Code hiding/protection is not possible in Haskell

I do welcome your feedback on both examples! Maybe you have some additional ideas of how to facilitate better some language specialties.

Especially, I am interested in some feedback from an experienced Haskell programmer who might suggest a different approach.

Code Kata – Compare Haskell and C++

My Project for Collaborative Programming

Vision

  • Make programming as easy as writing a Wiki page
  • Allow every user to change the data and the program (restricted only by policy rules)
  • Make heavy use of reused code
  • Provide support for development processes
  • Pf0mp Vision

Example: Task List Example

Principles

  • Every change is automatically versioned and self documented
  • Code and data is interchangeable
  • Data is everything that’s available in memory, on file system or in a database
  • All code fragments are everywhere and every time available
  • Same code (semantics) should exist only once
  • Concurring codes is executed in a Fuzzy way
  • Open interfaces to other systems
  • Implementation is on a central server – no code required on clients
  • Collaborative Programming
  • WikiWords

read more: on MBWiki

My Project for Collaborative Programming

Communities of Practice in Scrum

If you have Scrum on a larger scale in place, you will end up with several cross functional (multi-skilled) teams:

Eg. you will have developers, business analysts, and QA resources in one Scrum team. After a while you’ll need to think about know-how sharing and skill enhancements. I propose to implement communities of practice (CoP, http://en.wikipedia.org/wiki/Community_of_practice) for each skill.

A representative for each skill (horizontal community) is sent to the Scrum of Scrum.

Mirko.

Communities of Practice in Scrum

Classification of Organizational Paradigms

Referring to my blog “Being Agile at Organizational scale”  I’d like to classify the various organizational paradigms.

I propose a two-dimensional matrix with the following axes:

  • Management focused (top-down) vs. Team focused (bottom-up)
  • Dependent (waterfall like) vs. Emergent (agile like)

In this matrix, a command-and-control culture was at the dependent-management edge.  Self-managed teams were at the team-emergent edge.

I’ve started to put the agile organizational pattern into this matrix:

  1. Autocratic (classical stereotype)
    Management focused,  top-down, waterfall-like thinking
  2. Radical Management
    Get rid of top-down communication, enabling self-organizing teams.
  3. Rightshifting
    Do the right thinks, get the best of classical vs. emergent elements. Management as enablers.
  4. Holacracy 
    Based on collective wisdom, dynamical management
  5. Management 3.0
    Requires management to understand emergence in complex systems
Classification of Organizational Paradigms