In my last post, I stated that a “systems engineering” approach is needed during the initiating and planning phase of a program to make order out of chaos. The main problem is that a “program” has not been defined as an “entity” in the same way that systems engineering defines a “system”. For example, a “program” is defined in paragraph 1.6.1 of the PMBoK as follows:
“1.6.1 Programs and Program Management
A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program. For example:
- A new car model program can be broken up into projects for the design and upgrades of each major component (for example, transmission, engine, interior, exterior) while the ongoing manufacturing occurs on the assembly line
- Many electronics firms have program managers who are responsible for both individual product releases (projects) and the coordination of multiple releases over a period of time (an ongoing operation).
Programs also involve a series of repetitive or cyclical undertakings. For example:
- Utilities often speak of an annual “construction program,” a series of projects built on previous efforts
- Many nonprofit organizations have a “fundraising program,” to obtain financial support involving a series of discrete projects, such as a membership drive or an auction
- Publishing a newspaper or magazine is also a program with each individual issue managed as a project. This is an example of where general operations can become “management by projects” (Section 1.3).
In contrast with project management, program management is the centralized, coordinated management of a group of projects to achieve the program's strategic objectives and benefits”
Any one of:
- A portfolio of projects selected and planned in a coordinated way so as to achieve a set of defined objectives, giving effect to various (and often overlapping) initiatives and/or implementing a strategy.
- A single, large or very complex project, or
- A set of otherwise unrelated projects bounded by a business cycle.”
The above definition of a “program” above does not constitute a “construct or collection of different elements that together produce results not obtainable by the elements alone”. Consequently, the SE process (SIMILAR) is not applicable. However, I do not think that these definitions adequately describe the effort that it takes to develop a complex product or system in a “program” environment. There is, however, a concept that I have evolved over couple of years for the definition of a “program” that does satisfy the definition of a “system”. In this concept, a “program” has four elements, which I will call segments so that they do not conflict with definition for “system”. They are as follows:
- Sponsors/Users/Processes
- Product and Process Development
- Program Management
- Infrastructure
A “program” in this context is the application of a collection of these four segments that together produce a unique “system” or a unique service. Accordingly, a “program” defined in this way has the following advantages:
- A unique “model” for each program can be developed—a “program breakdown” similar to a WBS except that it includes ALL people, processes, systems, facilities, equipment, documentation and special interests, etc, utilized to produce the desired results, not just the work elements required on a contract.
- Complex interactions/interfaces/interdependencies between elements on a program introduce a huge amount of risk to program. Most of these are unknown when the program is initiated and planned and therefore, risks are not mitigated. This provides a systematic way of analyzing and mitigating program risks and reducing the uncertainty. All interfaces within and between the segments and their lower level breakdowns can be analyzed for risk and uncertainty so that risks can be mitigated.
- The SE “SIMILAR” process can be utilized during the initiating and planning phase of the program. This does not require all new procedures to apply it to a program.
- It provides a way to “integrate” baseline documentation to enable more efficient changes (more on this later)
On the flip side, there are some problems with acceptance and implementation of this concept:
Recognition of the problem: The life blood of a program is the integration and interaction of people, process, tools and documentation, etc, on a program. However, the current literaturedoes not recognize it as an issue. The PMBoK definition of integration is very weak so, recognition of this is foremost. I submit that major delays to the A380 and 787 were caused by interface/interaction issues that could have been mitigated with systematic analysis of the program interfaces.
Nobody wants to be first: During my career, I proposed several new methods and tools to programs and functional organizations. In all cases, the responsible managers asked if or where these methods or tools were being used. It seems that no one wants to be the first user of something new. To be clear, the above proposed redefinition of a “program” is not in use by anyone. However, the breakdown into segments and to their lower levels of detail is very similar to a product tree. Analyses of this structure utilizes current SE methods--risk, interfaces and interactions of the elements on the tree are analyzed and managed using interface and configuration management processes. Furthermore, two colleagues and I have verified that this concept works by applying it to similar product breakdowns.
Responsibility/Authority/Accountability (RAA): Currently, no one has the responsibility for integration of the program elements. It is generally delegated to teams and functional organizations that do not have the RAA for the total program.
Do you agree or disagree? Please comment on any or all of the above!!
In the next postings, I will provide the next lower level description of these of the segments followed methodologies that can be used to develop and analyze such a model.