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

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

Summary of the Agile Manifesto

The agile manifesto is about presence over past:

  1. Interactions/individuals are now – processes/tools originate from past decisions.
  2. Working software works now – comprehensive documentation is (mostly) out of date
  3. In customer collaboration you know his current requirement – a contract manifests past decisions
  4. A change is happening now – a plan is (mostly) out of date.
Summary of the Agile Manifesto

Being Agile at Organizational Scale

There are many books and posts about agile teams. Doing Scrum or Kanban is a state-of-the-art in software development. But, how does it scale in big organizations? How can agile methods cross department boarders?

I’ve found some answers on the web. In upcoming blogs I’ll go into more details.

Here’s my list of the methods with links to further reading:

Please give me some feedback, if I missed some relevant approaches.

Mirko Blüming

 

Being Agile at Organizational Scale

How the Agile Manifesto translates into Scrum

„Agile“ has evolved into a best practice for software development and has been described by the values described by the Agile manifesto(http://www.agilemanifesto.org/ ):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In the following Blog I’ll describe how these values translate into the Scrum artifacts. Scrum artifacts are underlined.

Individuals and interactions over processes and tools

In Scrum the team size and sprint length is limited, such that the team can manage their tasks on their own. From a project management point of view the teams works as a whole.

All necessary organization and rules originate from the interactions within the team. The team decides about responsibilities and will manage (external) disturbances collaboratively. The Scrum master helps the team to resolve impediments and assures the (self given) rules are obeyed.

Interactions are amplified by reducing the usage of tools. That’s why Scrum teams prefer Scrum boards with paper cards for task planning and tracking over than (electronic) tools.

Working software over comprehensive documentation

The second value reminds you that the first goal is to create working software that brings value to the customer. Since the subject of the documentation often changes faster than comprehensive documentation can be created too much documentation is just a waste of resources. Agile teams favor delivering software early and often (ideally using continuous integration) to ensure requirements can be validated.

However, documentation is important for further development and maintenance – the challenge is to find the right balance between the necessary documentation and the creation of paper that is never read again. The retrospective after each sprint helps to consider also long term consequences.

Customer collaboration over contract negotiation

The customer is represented by the Product Owner, a role define in Scrum. The product owner understands the customer and has profound business expertise. He is available to the team at any time such that interaction is the main source for alignments.

To avoid any kind of negotiation, the backlog (= open task list) is sorted by the product owner according to the customer priorities, so the customer gets always first what he needs most.

However, this requires a thoughtful and reliable product owner.

Responding to change over following a plan

In Scrum the development is done in sprints, i.e. time boxed. Each sprint is a kind of a small project with a planning, implementation, and review phase. After each sprint the team is re-aligned to the customer needs when they take the topmost items from the backlog.

As most of the project plans are outdated as soon as they are published, it’s just consistent to abolish traditional project plans – only the time of the next sprint is considered. This is counter to traditional project management goals of controlling change and keeping to a plan.

The burn down chart visualizes development speed and progress. In doing so unnecessary work is avoided and the risk of failure is controlled.

How the Agile Manifesto translates into Scrum

My personal introduction to Scrum

When you are completely new in Scrum, it’s a good idea to read an introductory book or browse through Wikipedia. When you’ve learned about the Scrum roles and artifacts, it’s also a good idea just to start with what you’ve just learned. My experience was that the really interesting questions only arise when you actually do Scrum. I’ve done the same and like to share my three Scrum lessons with you:

Implement a process for continuous improvements. Scrum does this trick by strictly “time boxing”: Define some fixed repeating time frame and call it “sprint”. If you run into delay or failure, do not expand the sprint length. After the fixed time period, ask yourself what you’ve achieved and think about how to become better next time. Think about how you can measure your progress. The Scrum artifact for measurement is the burn down chart. If you’re a manager, do not look on it as a new fancy tool to control your team. It’s rather tool for the team to measure their progress and become transparent in what they’re achieving every day. Derive a target what you want to achieve in the next sprint. Find a person who’s responsible that the Scrum rules are obeyed, and call him Scrum master. He/she should do his/her job once a day in the daily Scrum, and you’ve done your first Scrum lesson.

Second lesson is to achieve a team’s commitment. In classical project management there is some project manager who’s going to plan the project. This requires making assumptions about uncertain information and forecasting the team activities. Who is the most able to do this? It’s the team who’s most able to do the detailed planning. Again “time boxing” will do the trick: The sprint length should be small enough that the forecast becomes more certain and the team becomes confident in their plan. If the team becomes committed to the sprint target, you’ve done your second Scrum lesson.

The third lesson is to introduce a Product backlog. The product backlog is an ordered list of all requirements – both functional and technical. Call these entries “stories”. Find the Product owner who owns the product backlog, i.e. has the authority to decide on the stories. At every sprint start, the team selects the top stories from the backlog, plans activities and chooses which part they can commit. This is called “pull principle”. The team should do the decisions late, such that the product owner can decide to rearrange the product backlog as long as possible. This makes the Scrum agile and completes the final lesson.

My personal introduction to Scrum