Every manager of large complex programs will quickly tell you there are a number of critical tasks or steps that must be properly accomplished throughout various stages of the program for it to be successful. There are no substitutes or shortcuts for these critical tasks. This article is the first in a series that will discuss the critical tasks required for a successful program.
These critical program management tasks must be done correctly and in the proper sequence. Ironically, an unsuccessful Program Manager may be more attuned to what he did wrong after it is too late than a Program Manager who successfully executed a program. A Program Manager who has been extensively trained on how to correctly manage a program may not fully appreciate the problems and grief that can and will likely result from failing to accomplish the required critical tasks at the right time.
This falls in line with the old adage that “sometimes the most important life lessons (or project management experiences) are the ones we end up learning the hard way.” The moral to this is that there are some tasks that a Program Manager can circumvent or tailor – but some tasks are mandatory if you want to be successful. It is very crucial to know which tasks must be done “by the book” and which tasks have some flexibility.
The first critical task that must be performed properly is the establishment of the requirements for the program. If the program requirements are not properly identified at the start, there is zero chance that the Program Manager and the program will be successful. It is virtually impossible to deliver a program within the cost and schedule allocated to it if the “performance requirements” and other key program elements are not properly identified at the start of the program.
There are also normally numerous “users” or “stakeholders” for every major program, and for each user or stakeholder the odds of fielding a successful program decrease because each one usually has unique needs and requirements. Every major system or service always has many different requirements and questions that must be addressed at the start of the program, such as:
- What is going to be procured – a system or service?
- What functions or applications must the system or service provide?
- What are the performance requirements of the system or service?
- When is it required?
- What is the projected service life of it?
- Must the use of the system or service be mandated or is it optional?
- Who will use it and how (i.e., people and organizations)?
- What type of hardware and software must or should be used?
- Will the system or service be leased or purchased?*
- Will it be “developed” or commercial-off-the-shelf (COTS) or a combination of the two design types?*
- Should “full technical data rights” be purchased for the system or service?*
- What contract documents are required?*
- What are the estimated design, development, production and life cycle costs of it?*
- Should earned value management (EVM) or some other similar performance monitoring process be used to monitor the cost and schedule status of the program?*
- What types of tests will be used to evaluate it before it goes into production and operation?*
- What are the near term and long term benefits of it (i.e., return on investment)?*
*Note: Government agencies do not all use the same “acquisition management process” and acquisition documents, so these program elements may be addressed in other critical acquisition documents. These acquisition elements will be discussed in more detail in the following articles in this series.
Most government agencies prepare a “requirements” document at the start of a project to ensure that the major requirements of the system or service are identified. There are many different names for this requirements document such as mission need statement (MNS), critical requirements document (CRD), and other similar titles, but each of them typically address the types of requirements listed above.
Other key elements that should be addressed by a requirements document include:
Stakeholders or users. All stakeholders or users who are involved in or will use the system or service must participate in the development of the requirements document. This is mandatory in order to ensure that the system or service will accomplish all required functions and that the program cost and schedule estimates can be accurately and completely developed. All stakeholders should sign/approve the requirements document and agree to support the program as it progresses through the design, development, test, production, and implementation phases. This document sets the first “high level baseline” for the requirements of the program. All future program changes that affect the cost, schedule and performance baseline must be strictly controlled and properly implemented. Signing of the requirements document by the stakeholders is crucial so all stakeholder organizations will support the program.
Requirements identification. The minimum acceptable performance levels for each of the high level system or service requirements must be identified in the requirements document. All requirements must be complete, accurate, achievable (i.e., realistic), testable and measureable. The requirements should never be gold-plated – or higher than the minimum required for the operation of the system or service. This obviously is directly related to procuring the most cost effective system or service. If the procuring agency or company desires higher performance levels but cannot accurately estimate the additional cost and/or schedule impacts of the higher goals, then they may elect to invoke the minimum acceptable levels of performance as a contract “threshold” and add higher levels of performance as a “goal” on an “incentive” type of contract. Key points of the requirements identification are:
- All major requirements must be identified in order to prepare complete and accurate system specifications, costs, and schedules for the program. This is one of the first problems that produce “unsuccessful” programs if the requirements are not properly identified at the start of the program.
- All performance requirements must be reasonably achievable or realistic. This is a close second for problems that produce “unsuccessful” programs when something is required but cannot be achieved. This will cause disagreements with the prime system contractor concerning whether or not all of the contract requirements have been met. It will also cause problems within the procuring agency when it is not possible to accomplish all of the projected benefits of the program.
- All performance requirements and functions must be testable. If they are not, then it is impossible to determine if the system or service is “successful.” This discrepancy will also likely produce the same disagreement between the prime contractor and the procuring agency concerning whether or not the system or service has met the contract requirements. This discrepancy is more common than one might think it is. A good rule of thumb is that there must be a test specified in the contract to validate every “shall” statement in the contract specification.
- All performance requirements and functions must be measurable. If the program has been approved on a benefit-to-cost basis, then it is impossible to determine if the program is successful if you cannot measure the “benefits” of the program.
This brief article discussing the proper development of “requirements” for a program is only intended to provide a high level “overview” of the efforts involved in the first critical task for a successful program.
We’ll post further discussions of the other critical tasks required for a successful program in this space. Meanwhile, contact North Star Group if you have questions concerning the development of “requirements documents” or other program acquisition documents.
