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

Advertisements
System Dynamics in Project Management

Taxonomy for emergent programming languages

As explained in Wikipedia (http://en.wikipedia.org/wiki/Programming_language) there are different classification schemes for current programming languages:

  • by inheritance (result in language families, mostly related to syntax)
  • by programming paradigm (How to use?)
  • by domain usage (What’s it for?)
  • by generation (related to the history of languages)
  • by language elements (Syntax, static/dynamic semantics, type system, libraries)
  • by tools (e.g. shipped with Eclipse)

You can find more details in Wikipedia using the following keywords

  • Programming paradigms
  • Programming language
  • Programming language generations

All the presented classification schemes are matching exactly the known existing programming languages.

A prospective taxonomy should already contain some white spots for emergent languages.

Here are some ideas for emergent languages not covered by the above classification schemas:

  • support for situated applications
  • supporting build and deployment processes
  • more generic language elements (e.g. patterns)
  • configuration and versioning
  • collaborative programming
  • stochastic semantics
  • interaction with project management / reporting / controlling
  • support for software design / demand management
  • Supporting versioning and code migration
  • Profiling and refactoring support

I’ll explain in detail what I understand by these topics in later posts.

Taxonomy for emergent programming languages

No progress in programming languages

Nearly 30 years without fundamental progress in programming languages shows that we’ve reached a trashold to a completely new domain of programming languages. Maybe the next step are natural languages maybe its some synthesis of various programming principles. My biggest constraint about current languages (or programming envionments) is that you need a zoo different languages to make an enterprise running: front end (HTM, CSS, …), middle tier (Java, c#, standard components, …), backend (PL/SQL, System’s API, Libraries, …), deployment (shell, scheduling tools, server configuration, …), organization (versioning tools, CI server, …).

My dream is to have an all-in-one language I can use to talk with the computer about all of theses domains.

Inspired by post http://tagide.com/blog/2012/03/research-in-programming-languages/#comment-123

Paul Graham wrote an interesting post about how difficult it is to convince a programmer to chnge the language – even if it was a more powerful one:  http://paulgraham.com/avg.html

No progress in programming languages