Project Management Activities

Form the IT project; manage its tasks, and coordinate with other IT projects, as needed.

Introduction Activities Roles and Responsibilities Artifacts Additional Resources

-Project Plans - Project Charter - Plateau Plan - Support Plans - Project or Product Requirements - A-TARS - Waiver Approvals - Status Manage Project and Product Requirements Define Process Plan the Project Monitor the Project Complete the Project - Project Plans - Waiver Requests - Project Archives - Lessons Learned - Status - IT Project Manager - IT Evolution    Management Team - User Representatives - Support Organization - Other Key Stakeholders

Introduction

These activities are responsible for the life-cycle management of fabrication projects. Fabrication projects are the fundamental organizational building blocks by which the HS Agency provides IT products and data to achieve a plateau's goals. The products produced by the projects are integrated into the developmental configuration, which is then released for deployment.

Fabrication projects may implement many approaches to provide these products. These approaches include developing from scratch within the HS Agency, purchasing and adapting existing Agency or commercially available off-the-shelf items, transferring a system from another State, or contracting with an external developer. Maintenance actions are also managed as fabrication projects. The management techniques are specialized to accommodate each approach. The use of the term project implies any form of these fabrication projects.

The lifetime of a project is assumed to be relatively short, as noted in the Technology Fabrication Projects Guide main page. A project may produce products to be used by another project or have those products placed within the developmental configuration, ready for deployment. Fabrication projects are considered complete once their products are accepted and placed under configuration management (see the support activities).

The set of projects, their products, and interproject relationships are documented in the IT Evolution Plan. Project-level plans detail the project's tasks within that context. Projects may be separately managed or managed as a set. The need to organize projects into commonly managed sets can be based on coordination and personnel efficiencies or other aspects, such as:

• Assembling cohesive projects into sets based on the unique skills of developers. This approach may include aggregating Web content development, presentation, business logic, database, networking, security, platform configuration, testing, or acquisition specialties. Individuals on these projects work across many applications in their specialized area.

• Organizing projects into sets based on functional capabilities, such as implementing all parts of an application for an HS Agency program.

• Organizing projects to align with a funding source.

• Implementing shared functionality, where the resultant product's costs are shared across many programs (e.g., a project for a common front end or portal.

• Organizing high-risk tasks as a set that can receive focused attention, especially if they are on the IT Evolution Plan's critical path. This approach could include developing an operational prototype that is used as a basis for other projects.

• Organizing projects to reduce competition for shared resources. This approach may include individuals that work across many projects (specialists or advisory roles) or projects where limited resources must be maintained (developmental  testing environments).

Top

Activities

The basic planning and management activities described in the Planning and Managing the Technical Evolution Guide also apply to the fabrication projects. You may refer to those activities for additional detail. Some management activities applicable to the fabrication projects are described below:

1. Manage Project and Product Requirements. The overall scope of a project is established in the IT Evolution Plan. This scope includes expectations and constraints on the project's product and processes, as well as dependencies between projects. These expectations and constraints form the technical and nontechnical requirements. These requirements are the basis of the detailed planning for the project.

   Example technical (product) requirements include, among others:

   • Functional capabilities
   • Performance, size, reliability, quality, and other intrinsic product attributes
   • Life-cycle maintenance costs
   • Product design and fabrication rules (from the A-TARS)

   Example nontechnical (project) requirements include, among others:

   • Project deadlines (expected or required start and delivery dates)
   • Budget and spending rates
   • Staff availability
   • Coordination with other projects, such as cross-project working groups
   • Methodologies, practices, or tools to be used  (e.g., process constraints, including acquisition rules or engineering practices from the A-TARS)

   You must document and review all requirements allocated to a project. Requirements can be communicated in any convenient form that satisfies the project's need to ensure communication between it and the stakeholders. For example, you can provide a complete and concise requirements document or use a simple list of note cards with capabilities ( Beck 1999; Newkirk and Martin 2001) to communicate requirements. For maintenance activities, a problem report or a change directive may suffice. You can prepare waivers for relief from A-TARS requirements and forward them to the Technical Architecture Team for negotiation and approval.

   Address issues with the requirements' feasibility, clarity, consistency, or verifiability before commitments are made to satisfy them. Manage and control changes to the requirements to ensure that project plans remain consistent with the requirements. Because projects are generally of short duration, once the requirements are accepted, they are generally unchanging until the project completes. New or changed requirements can be applied to projects later in the plateau. One exception is a make-work modification. A make-work modification is a change to the requirements to accept the product when full compliance will cause significant delay or cost. You may define additional projects to rectify the loosening of requirements later during the plateau or on later plateaus. You can manage requirements individually on each project or as a set that is allocated across the projects.

2. Define the Process. These activities complement and further elaborate the plans produced by the Develop the IT Evolution Plan activities. Integrate the management, engineering, acquisition, and support practices for the project into a coherent project process. This includes the methodologies and tools to be used. Identify the appropriate staff skills and training needs to select and prepare staff to competently execute the process. The project practices must conform with the guidelines from the A-TARS. The project's defined process also must be consistent with the project and product requirements allocated to the project.

3. Plan the Project. Detailed plans for the project are based on the project requirements and the processes to be enacted. The project plans must conform to the deadlines and resources allocated to the project, within a reasonable probability of success (cost, schedule, quality). In the IT Evolution Plan, maintain a reserve for managing risks, such as a late deliverable from another project. If reasonable plans cannot be made, you can renegotiate the project or product requirements. Project planning generally involves three major components:

   • Define the project work. Define the final and intermediate work products of the project and the activities to be performed in the project's WBS. The WBS spans the management, engineering, acquisition, and support activities. Products include all life-cycle documentation, as needed to create, maintain, and use the products (e.g., design documentation; program code; test procedures and results; and training, user, and operation manuals, among others). For acquisition-focused projects, the work products reflect the exchange and management of technical and management information with the contractor or vendor.

   • Estimate project costs. Define all cost categories and make estimates for each category. This includes all costs that are project responsibilities (e.g., tools, travel, facilities, consulting, interproject coordination, or labor). For labor-related costs, use one or a combination of the following methods:

     • Analogy. When a similar product has been built or procured, use its costs as a benchmark for comparison with the current project (or set of projects). Use the differences between the benchmark and the new product to establish a cost range. Actual results for completed internal projects should provide the best basis for comparison, although comparison outside the HS Agency may be useful (another State's experiences).

     • Simple estimation relationships. This technique relies on a reasonable estimate of the size of the products, such as expected number of entities from a data model. You can use staff productivity factors to estimate the labor involved. This approach assumes that productivity data is available, and historical information is maintained across the IT Division.

     • Activity-based models. This bottom-up technique combines the estimates for each separate activity performed on the project. This approach works well when experts in each of the activities are available and have expertise in the project domain (the application or technology to be used).

     • Parametric models. These tool-based models consider several parameters, such as expected size of the product ( SLOC), staff experience, use of tools, and overall maturity of the development organization. You need to calibrate these tools to the characteristics of the development organization in order to provide accurate estimates.

   • Schedule tasks. Create the network of project activities. This involves:

     • Identifying internal project task dependencies as well a dependencies, on other projects. This activity will help with sequencing projects within the IT Evolution Plan.
     • Identifying organizational or other global constraints, such as the number and type of  skilled staff or other resources available (testing facilities). Task schedules may need to be adjusted to allow for sharing resources. Staffing plans may need to be to integrated across projects. Responsibilities, especially for inter-project interfaces should be explicitly assigned.
     • Structuring tasks to allow for two measures per individual per month. This approach provides adequate visibility into project schedule status and allows project management to determine progress within a 2-week window (e.g., task duration of 1 to 3 weeks, 1 to 2 individuals per task). Define and objectively state the criteria to indicate task initiation and completion (e.g., event-influenced, not schedule-driven).

   The plan, when completed, will be reviewed and approved by the Project Manager and members of the IT Evolution Team. Record the plan and any assumptions upon which it is based and place them under CM.

4. Monitor the Project. The Project Manager tracks activities against the documented project plan, making adjustments to the plan or the project performance, when necessary. Effort, cost, schedule, technical achievements, and other measures are tracked against estimates. Periodic status reports should be furnished to the IT Evolution Team, the HS Agency's Chief Architect, or other project stakeholders. Reports will communicate status against planned activities, technical or management issues, and expectations for the next reporting period. This may include results of formal reviews with contractors when acquiring products from outside the Agency.

   For these short duration projects (3 to 6 months), management in-process reviews can be performed rather than formal, large-scale reviews. These in-process reviews can be scheduled for roughly 1/3 and 2/3 of the project's elapsed time (or every 2 to 3 months). The reviews should offer timely insight for management to allow midcourse project corrections or adjustment of other dependent projects. Some measures that can be taken and reported are:

   • Task planned/actual start/completion performance
   • Critical path performance
   • Effort planned vs. actual
   • Earned value
   • Technical or management issues requiring higher-level decision making (cross-project dependencies)

   Hold informal project reviews, involving internal project personnel, on a more frequent basis, such as every other week. These reviews make sure that the intraproject dependencies are being met and facilitate making minor midcourse corrections that affect only the project team.

   A formal review, generally near the end-time for the project, authorizes the release of the project's products. These products can then flow formally to other projects through the CM activities or be incorporated into the developmental configuration.

5. Complete the Project. Projects exist until they are cancelled or their products are accepted. Before a project is closed, archive major work products and by-products for later analysis, if needed (e.g., project plans and periodic status). Also, conduct a formal lessons-learned session. You can feedback items from this session into the planning and management of current and future projects. Some areas to explore include:

   • Accounting for differences between actual and estimated values for effort, cost, or schedule. This determination may result in improvements to the planning or other management processes.
   • Accounting for differences between actual and expected product qualities. This determination may result in improvements to the engineering or acquisition processes.
   • Risks that were difficult to mitigate. This determination may result in identifying mitigation strategies that worked well and those that did not.

   Share a report communicating the lessons learned across the projects. This report serves as a basis for improving the IT Division's processes. Incorporate guidance into the A-TARS, as appropriate.

Top

Roles and Responsibilities

The key roles and their responsibilities are as follows:

• IT Project Manager. This individual has primary responsibility for these activities, assisted by the IT Project Team or staff, such an Estimation Analyst or Contract Manager. An IT Project Manager may manage one or more projects simultaneously.
• IT Evolution Management Team. These individuals, specifically the IT Evolution Manager, have oversight responsibility for all projects. The IT Project Team will coordinate with the IT Evolution Management Team when planning and controlling the project.
• User Representatives. These individuals collaborate with the IT Project Team to provide user perspectives, helping to establish product requirements and providing user insight while the product evolves.
• Chief Architect. The Chief Architect represents the Technical Architecture Team when reviewing waivers or the project's technical achievements.
• Support Organization. Individuals with expertise in the QA or CM disciplines provide assistance to the management staff. They participate in the early project planning activities and provide oversight of the project practices and developing products.
• Other Key Stakeholders. These stakeholders may include any group or individual with a vested interest in a project's products (e.g., representatives of IT Project Teams from other interdependent projects). Coordination may take place during cross-project working groups or by other means.

Top

Artifacts

The following information is used or produced by these activities. Templates, examples, and checklists for identifying and documenting items are available through the Additional Resources section at the end of this page.

• IT Project Plans. These work-level plans are the main product of these activities, updating the previous version, if it exists. They are used to guide the execution of all project activities and to report progress.
• Project Charter. The Project Charter sets the scope and authorities of the project management and is the foundation for the management approach.
• Plateau Plan. The appropriate portion of the IT Evolution Plan identifies constraints and expectations for the project with regard to other projects. Project plans must be consistent with it.
• Support Plans. These plans are integrated into the overall project plans.
• Project or Product Requirements. This consolidates all the requirements imposed on the project from all sources: IT Evolution Plan, the HS Program Staff, HS IT Division, the Project Charter (constraints), and others. These requirements are used as a basis of defining and planning the project. Project success is defined by how well the requirements are satisfied.
• A-TARS. The appropriate part of the A-TARS is used to guide technical management decisions for the project, such as the technical practices that can be used or how products are structured.
• Waiver or Design Requests. Projects file waivers to be relieved from mandatory A-TARS requirements.
• Waiver or Design Approvals. Projects receive formal approval when they deviate from the A-TARS.
• Status. Task progress and issues from engineering, acquisition, or support activities is used to manage project tasks. Project status is summarized and provided to the IT Evolution Manager and other oversight authorities on a periodic and event-driven basis.
• Project Archives. Technical and Management data from a project is archived for later analysis.
• Lessons Learned. These are formally captured and disseminated at project completion.

Top

Additional Resources

Resources applicable to this activity are cataloged below. Some items in the Planning and Managing the Technical Evolution resources may also be used to perform the fabrication project management activities. Lists of all available resources may be found in the Resources portion of the IT Planning and Management Guides.

Top