Category: Programme and Project Management

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.

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?

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

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.

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.”