As I stated in the last posting, the definition of a “system” seems to be a fitting description for a complex program also (more on this at a later date).  However, the “program plan” or “execution plan” is in reality a “process”. It is a logical sequence of stakeholder tasks with their durations that produce products and on a schedule required by the ‘statement of work”. This logic network/schedule is developed and maintained in PM software using the “critical path method” (CPM). It is a very painful process requiring abundant resources, skills and time.  Individual networks for dozens of teams and suppliers at varying levels of detail and different development cycles must be integrated into an executable plan that all stakeholders can agree upon.  “Integration” or interaction of tasks (aka sequencing) is the key effort for the plan to executable and efficient. Current best-practices utilize “rule of thumb”, past experience, and best-guess methods and in some cases, process flows are provided by individual teams. Consequently, the end result is a less-than efficient program plan.  This effort could benefit from the true process development/re-engineering methods described below.

1. The sheer size and complexity of the product and process development is difficult to document, assimilate, organize, analyze, and plan. Hundreds of people, including a prime contractor and a multitude of suppliers, are involved in a program that spans multiple years. A recommendation will be made at a later date. 
2. The definition of the system/product being developed is incomplete for “initiating” and “planning” purposes. In addition, the definition of the processes to be used to develop and produce the system is not complete (e.g., operations, maintenance, and training).   The technology has to be mature enough to proceed to full-scale development but the system design itself may only be at the Systems Design Review level or less. There is a tremendous amount of information to be discovered and documented before Final Design is achieved. In addition, competition between contractors forces ground rules and assumptions to be made to reduce cost and shorten the schedule which cannot be maintained, causing change after contract award. All of this leads to an incomplete/inadequate program definition and frequent changes in the product and process baseline definitions.  
3. Product/process and program definition/baseline documents  are created in separate files and applications that makes configuration and contract change difficult, expensive and time consuming. A recommendation regarding more efficient management of change will be provided at a later date.
4. Adequate planning takes dedicated resources, adequate time, and sufficient information to accomplish. The constraints of time during the acquisition process forces compromises for adequate planning. The people who are going to execute the program must provide their plans and estimates for accomplishment. These are the same engineers and managers who are also dedicated to defining the product and processes, so their time is limited. Also, suppliers are not always selected and available to provide their inputs. In addition, critical definition and planning information is unavailable early in the life cycle. All of these issues cause extensive ground rules and assumptions established as a basis for the plan(s) and estimate(s). A recommendation will be made at a later date.
5. Program management’s responsibilities are de-centralized so that no one is responsible for making sure everything works as required and works together efficiently.   Current best-practice initiating and planning documents do not define a methodology for integrating everything on a program, and a function equivalent to Systems Engineering within Program Management does not exist. So, integration of the program as a whole (if performed) is a function of the statement of work and organization structure primarily consisting of Integrated Product Teams. In addition, the integration of the prime contract with the suppliers is often delegated to a separate procurement organization. A recommendation will be made at a later date.
6. PM tools are inadequate for the initiating and planning processes. Most new programs start up with limited skilled personnel, and a limited toolset. I worked on several large-scale proposals where the only tools available are MS Project and MS Office. If or when the contract is awarded, larger scale systems are setup and more people are assigned. I am going to expand this topic at a later time.
7. Best-practice risk management methods require too much specific information than is available early in the life cycle and levels of uncertainty are generally not considered. Systematic analyses of all aspects of the program and its execution is needed. There will be more on this topic also at a later date.

So, the bottom line is the same as stated previously—there must be better ways to initiate and plan under uncertain conditions, better ways to identify and manage interactions/interfaces, better ways to manage the identified and unidentified risks, and better ways to manage changes to the baselines. I think a methodology that utilizes “systems engineering” processes is needed.

 

Andrew,
I have been following your blog, so there is someone out there paying attention.
I work for the Australian DoD, and we have been working through a major business process re-engineering exercise in relation to the management of our major programs. This has been directed by Government, as a result of concerns with many of the issues you are citing.
Your blog attracted my attention because I too believe that the initiating and up-front planning stage are critical for any project. And I have an adage that should be applied at that stage: "Start with the end in mind!".
As part of our business process re-engineering, we are finalising a redeveloped Defence Capabilility Development Handbook to replace the 2006 manual. While an Interim edition has been approved for internal use by practitioners, a public version should be out before mid year 2010. It focusses on the Needs and Requirements phases of the lifecycle of what we term a "Capability System".
Our porcesses are indeed a necessary fusion of PM and what I would charaterise as "systems engineering writ large"; in this case the system being a Capability System, very much in-line with the INCOSE definition you have cited.
I intent to track and contribute to this important blog.
By the way, have a look at:
http://en.wikipedia.org/wiki/Capability_management
for some additional information on Capability Management.

Thank you very much for your comments and support for this effort!! I am somewhat familiar with Capability Management from an assignment I had before retirement. Although my perspective and experience is from the contractor point of view, a robust initiating and planning process could be applied at any stage in the life cycle. The term "system" is defined in such broad terms by the SE community that it can be applied to practically any entity that performs some sort of work and I may use it in a way that is confusing. Since this is uncharted territory, I would appreciate comments and suggestions to make the concepts more understandable and acceptable. I hope that the direction I am going with this will help you. Please keep in touch. Thanks, Andy