|
Booklet:
Development
and Acquisition Section: Project Management Subsection: Project Management Standards |
|||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||
Organizations
should establish project management standards. 
Institutions
that routinely complete multiple projects should establish project management
offices to coordinate project activities.
Standards
should be in place to address general project activities such as project
request, review, and approval processes, project management methodology
selections, and project reporting and documentation requirements. Standards
should also address the specific requirements of individual projects.
For example, standards relating to software development projects should
include, among other things, application design, programming, and testing
requirements.
Project
management standards should be commensurate with organizational and project
characteristics and risks. The standards should be sufficiently detailed
to ensure team members can identify project objectives and expectations.
Clearly defined expectations are a prerequisite for successfully completing
projects and obtaining buy-in throughout an organization. The standards
should require representatives from all departments involved in, or affected
by, a project to assist in defining functional requirements and project
deliverables.
Organizations that need to coordinate multiple projects should establish
standards for coordinating and managing the projects from an organization-wide
perspective. The standards should include procedures for project prioritizing,
resource coordination, progress reporting, stale project resolution, etc.
PROJECT PLANNING STANDARDS
Organizations should establish appropriate project planning standards.
The standards should require management to develop project plans that
are detailed in proportion to a project’s characteristics and risks.
Management should develop well-defined plans for all projects.
Project plans should describe existing system benefits and weaknesses,
explain project goals, and identify user, information, system, and network
requirements. Such explanations and descriptions enhance team members’
abilities to understand project objectives and develop systems that meet
organizational needs. Project plans should identify quality assurance
procedures; risk management procedures, including security features which
will be needed; testing procedures; and documentation procedures. Additionally,
project plans should detail cost, staffing, resource, and training requirements.
CONFIGURATION
MANAGEMENT STANDARDS
Organizations should establish configuration management standards. Configuration
management involves controlling project component changes in order to
minimize project disruptions and ensure original objectives are addressed.
Configuration management standards should require the identification of
baseline configurations (original versions) of hardware, software, services,
documentation, and project management plans. Standards should also be
in place to ensure all changes to baseline versions are evaluated, approved,
documented, and disseminated. Refer to the “Maintenance” section
for additional configuration management details.
QUALITY ASSURANCE STANDARDS
Quality assurance is a critical part of well-managed development and acquisition
projects. Comprehensive quality assurance, risk management, and testing
standards provide the best means to manage project risks and ensure software
includes expected functionality, security, and operability. Quality assurance
procedures should be applied to internally and externally developed programs.
Management should establish quality assurance standards that address:
|
|
Commitment
– Successful projects require commitment from all involved parties.
Senior managers should adequately support and promote projects throughout
an organization to enhance organizational acceptance of a project.
End users should assist in defining and testing functional requirements
and project teams should efficiently complete tasks. All parties should
clearly define their expectations and effectively communicate throughout
a project. Management’s failure to implement or support quality assurance programs decreases an organization’s ability to detect project weaknesses and programming errors quickly. The later weaknesses and errors are detected, the more difficult and costly they are to correct. |
|
|
Completeness – Each phase within a project life cycle includes procedures to follow and items to deliver. Therefore, quality assurance programs should parallel all phases of the life cycle. For example, the project initiation phase includes the presentation of a business case, the request for desired functional requirements, and the identification of interconnected system components. Quality assurance personnel should verify the justification for a project, the necessity of requested functional features, and the accuracy of system connections before projects move into the project planning phase. Audit and compliance employees should assist quality assurance personnel verify compliance with internal and external project requirements. |
|
|
Scalability – Projects vary in size and complexity. Quality assurance standards should match project characteristics and risks. |
|
|
Measurability – Organizations cannot evaluate a project’s success accurately unless they assess results against defined expectations. Therefore, quality assurance personnel should assess the quality of products and processes against measurable standards, metrics, and expectations. |
|
|
Tracking – Project personnel should properly record, report, and monitor problems to ensure effective problem resolution. |
|
|
Independence – Audit and quality assurance personnel should be independent of the project they are reviewing. |
RISK
MANAGEMENT STANDARDS
Organizations should establish risk management standards and procedures
for all complex or mission-critical projects. Risk management activities,
which are sometimes included within quality assurance programs, should
include procedures for identifying and managing internal and external
project risks.
The procedures should be designed to ensure internal and external project
risks are identified and assessed, reported and monitored, and appropriately
managed. Managing identified risks requires organizations to develop strategies
regarding risk acceptance, mitigation, transfer, or a combination of these.
For example, a mitigation strategy to address risks involved with initiating
projects having a high number of functional requirements might be to review
the project scope and eliminate any unnecessary functional requirements.
Transferring an identified risk, such as natural disasters, might be accomplished
by acquiring insurance policies.
Structured project management techniques provide ways to reduce project
risks. However, project management differs from risk management. Project
management focuses on controlling project activities as opposed to project
risks. For example, project management procedures (in a software development
project) involve scheduling programmers to script programs; risk management
procedures would involve establishing contingency plans in case several
programmers quit in the middle of a project. Similarly, project management
procedures (in an acquisition project) involve assessing a vendor’s
financial stability; risk management procedures would involve reviewing
the accuracy of the assessment and establishing contingency plans in case
the vendor fails to meet its obligations.
TESTING STANDARDS
Management should establish testing standards that require the use of
predefined, comprehensive test plans, end-user involvement, and documented
test results. Additionally, testing standards should prohibit testing
in production environments or with live data. If copies of live (customer)
data are used during tests management should ensure that appropriate standards
exist to protect the confidentiality of that data. Management can use
test data generators, which are software applications that generate representative
testing data based upon predefined parameters, to develop appropriate
testing data. Numerous automated applications are also available that
test program logic, functional operability, and network interoperability.
DOCUMENTATION STANDARDS
Organizations should establish appropriate documentation standards. Documentation
consists of detailed descriptions and explanations of technology applications,
systems, and procedures. Documentation enhances a user’s ability
to use, review, or modify the applications, systems, and procedures. Management
should maintain documentation for all technology resources, including
nontechnical policy and procedural guidance, and technical information
such as hardware and software configurations, and system and application
source codes. The quality and quantity of the documentation should be
commensurate with the characteristics and risks of the associated resource.
For example, high risk applications should be more formally documented
than applications that are considered low risk by the organization.
Development and acquisition project documentation should include project
requests, feasibility studies, project plans, testing plans, etc. System
documentation, which focuses on system analysis and design, should include
system concept narratives, data flow charts, and database specifications.
Application documentation should include application descriptions, programming
flowcharts, and operations and user instructions.