Complexity management?

 

“…it does appear that the way that uncertainty is managed in projects (through risk and opportunity management) could be broadened to complexity management. Uncertainty is only one type of complexity, and there are well-developed approaches for this. Beyond simply assessing and understanding the complexity of a project, the active management of complexity is worth exploring. An assessment of the complexities could result in some of the indicators being actively managed.”

Geraldi, Joana, Harvey Maylor, and Terry Williams. “Now, let’s make it really complex (complicated): a systematic review of the complexities of projects.”International Journal of Operations & Production Management 31.9 (2011): 966-990.

PPM model updated

In earlier postings, most recently here, I have used a model to explore the concepts of programme and project management. It appears simple but has hidden depths. Discussions with Richard Watson and with my tutor group suggest that we should adapt the model by including (a) the concept of ‘benefit’ as something that can be delivered through programme ‘outcomes’ and (b) the idea that, over time, benefits will impact the wider environment. For example a variety of project outputs enable the outcome of a school that is educating local children. That outcome gives rise to the benefit that better-educated people are entering adult society. Over time that benefit has an impact on economic and other conditions in that society.

PPM-framework_revised

MSP under scrutiny: the meaning of capability

MSP section 2.2 lists seven principles that underpin a successful programme. One of these is “designing and delivering a coherent capability”. That fits nicely with systems thinking: a system provides some sort of capability to its users.The system engineer wants to know what is the boundary of the system, what is the nature of the capability it is required to provide and who are the users of that capability?

MSP goes on to define the term ‘capability’ as being: “The completed set of project outputs required to deliver an outcome; this exists prior to transition. It is a service, function or operation that enables the organization to exploit opportunities.” In other words, MSP sees the capability as a set of project outputs. How does that square with systems thinking, where a capability is more than the sum of its parts? Those parts – the project outputs – are integrated to create a system that is capable of performing functions which the project outputs alone cannot. These functions perform to a certain standard which must be specified at system-level. That is to say, the capability needs to have system-level specifications of functionality, performance and other non-functional requirements. Typical non-functional requirements are usability, availability, reliability, maintainability, adaptability and enhanceability but there will often be others.

MSP’s take on this (see section 7.1) is that “… projects create outputs, which build capabilities, which transition into outcomes that serve the purpose of realizing benefits.”

  • An outcome is defined to be “The result of change, normally affecting real-world behaviour or circumstances. Outcomes are desired when a change is conceived. Outcomes are achieved as a result of the activities undertaken to effect the change; they are the manifestation of part or all of the new state conceived in the blueprint.
  • A benefit is defined to be “the measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders, which contributes towards one or more organizational objectives.

MSP tries to clarify these somewhat confusing statements by using the V-diagram and the flow diagram shown below. How do these stand up to scrutiny when compared with the engineering V-diagram and its underlying concepts?

Strategic context of benefits management within a programme

Path to benefits realization and corporate objectives

A project-product lifecycle management approach

Sharon et al (2008) have written an interesting paper about “three intertwined domains: the product, the project and the enterprise“.

system-engineering-mgt-scope

Their figure, above, shows how the “program management” overlaps in a number of issues with the product’s “systems engineering” process. The paper goes on to explain how “the combined Project-Product Lifecycle Management (PPLM) approach is intended to help the
system engineering manager to properly tailor the specific product to be delivered by its specific project within a specific enterprise“. It’s a bit geeky but there are some thought provoking ideas.

Reference
Sharon, Amira, Valeria Perelman, and Dov Dori. “A project-product lifecycle management approach for improved systems engineering practices.” Proc 18th Annu INCOSE Conf, Utrecht, The Netherlands. 2008.

Systems engineering management

The Guide to the Systems Engineering Body of Knowledge contains a section on Systems Engineering Management. This is about “managing the resources and assets allocated to perform systems engineering, often in the context of a project or a service, but sometimes in the context of a less well-defined activity. Systems engineering management is distinguished from general project management by its focus on the technical or engineering aspects of a project.

 

The bigger picture

PPM-frameworkIn an earlier posting I used the figure at right to show one view of the bigger picture in programme and project management. The idea is that project outputs combine to enable the programme outcome(s) and these, over time, bring about a strategic impact. Different types of stakeholder seek different forms of value at different points in the model.
lifecycle-of-systemAnother useful view is that of the system lifecycle (see figure at right). This shows the outputs from one or more projects being used to deliver a system. The system is operated, maintained and repaired. It can be adapted and enhanced to satisfy changing needs. Eventually it is decommissioned and its component parts recycled or otherwise disposed of. Note that the system can comprise humans as well as physical artefacts; for example it might be a school. In that case one of the project outputs might need to be trained teachers.

If we now look at the bigger picture through a sustainability lens, what other views or insights can we generate and what can these tell us about the meaning of ‘sustainable project management’?

Projects integrating Sustainable Methods

PRiSM™ (Projects integrating Sustainable Methods)

One of the most significant of PRISM’s features is the concept of the Sustainability Management Plan. This is a set of controls that govern aspects of a project to consider five measurable elements (People, Planet, Profit, Process, and Product) and how they relate to the delivery of projects. Each of these elements are measured individually and in total to give a 360 degree perspective.

Another important aspect of PRiSM is the method of analyzing the impacts of a project. This is a new method for calculating risk as it measures the impact on five levels (as opposed to the traditional “three triple constraints”) and takes into account the output of the project from cradle to grave rather than from initiation/pre-project to close/hand-off.