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?
