Section 11.7. Solutions Fast Track

11.7. Solutions Fast Track

11.7.1.

11.7.1.1. Technical Tracking Tools

Earned value analysis (EVA) is a method of assessing project progress using calculations involving planned and actual work progress metrics.

Planned Value (PV) is defined as the planned percent complete times the total project budget.

Earned Value (EV) is defined as the actual percent complete times the total project budget.

The Cost Variance (CV) is defined as the earned value minus the actual cost.

The Schedule Variance (SV) is defined as the earned value minus the planned value.

The Schedule Performance Index (SPI) is calculated by dividing earned value by planned value (PV).

The Cost Performance Index (CPI) is calculated by dividing the earned value by the actual cost.

The Estimate At Completion (EAC) is determined by dividing the total project budget by the cost performance index.

The Critical Ratio (CR) is calculated by multiplying the SPI by the CPI.

An SPI value of greater than 1 indicates your project is ahead of schedule. A value of less than of 1 indicates your project is behind schedule.

If your schedule gets off track, you may choose to carry the deficit (or surplus) forward or use your schedule reserve.

A CPI value of greater than 1 indicates your project is under budget. A value of less than of 1 indicates your project is over budget.

If your cost gets off track, you may choose to carry the deficit (or surplus) forward or use your budget reserve.

Estimate At Completion uses the cost performance index and the total project budget to determine a new estimate for the real cost of the project at completion.

EAC can be used to determine whether or what a project should (or can) go forward. A project estimated to be too far over budget at completion may be cancelled.

The Critical Ratio can be used to gain an overall understanding of project progress and can be used to effectively communicate progress with upper management.

11.7.1.2. Testing Project Deliverables

Unit testing is often performed on project deliverables as soon as they are ready. Integration testing tests the performance of multiple project deliverables to determine how (and if ) they work together in an integrated fashion.

The person performing the work should perform some type of unit testing as part of the task to ensure the scope and quality requirements are met.

Usability testing is typically performed in a controlled environment to ensure the project results are usable from a customer/user perspective.

Acceptance testing is used to determine whether or not the user will accept project deliverables. The functional specifications are typically tested in acceptance testing.

Beta testing occurs when the product is in the final stages and is close to release. Beta testing can turn up major (show stopper) and minor (revision) errors and defects.

Beta testing may include some form of user testing in their environment to test functionality.

Regression testing is performed after errors and defects have been identified and reworked. Regression testing is done to ensure that no new errors or defects have been created as a result of addressing earlier errors.

Performance testing can include stress, load, reliability, and stability testing to ensure the project's deliverables can work in real-world conditions.

Benchmark testing tests hardware and software against defined standards.

Security testing ensures the project's deliverables meet security requirements. One element of security testing is to make sure that if attacked, the project's deliverables respond appropriately to avoid providing additional information to intruders.

Security testing is often outsourced to get a fresh set of expert eyes looking for security weaknesses.

11.7.1.3. Preparing for Implementation, Deployment and Operational Transfer

An implementation plan describes steps to be taken to install or implement the project's deliverables.

A deployment plan describes steps to be taken to deploy the solution across the enterprise.

In some cases, the implementation and deployment plans are one and the same.

Both implementation and deployment plans should include rollback plans in case things go wrong. The original state should be defined so rollback can occur.

Operational transfer is the process of permanently handing off operations of the project's deliverables.

A well written operational transfer plan will follow the same steps as an IT project plan to avoid errors and omissions.

Training, support documents, users guides, release notes, and Service Level Agreements should all be defined within the operational transfer plan.

11.7.1.4. Resolving Common Project Problems

Problems with scope include vague scope, scope not feasible, errors in approach, and scope creep.

Problems with quality include initial results failing to meet quality standards, work delivered outside the scope of the project, fixing the wrong problems, problems that reappear, and problems that cannot be resolved.

Problems with schedule include late start, missed deadline or deliverable, everything on the critical path, and nothing on the critical path.

Problems with budget include funds expended up front, assets moved off project, too many approval points, and shrinkage.

Problems with staff include confusion over who's in charge of project staff, whiners, big biters, belt and suspenders, and interpersonal conflict.

Problems with the project sponsor include lengthy reporting requirements, rehashing previous decisions, inability to schedule project review meetings, and pressure to complete the project faster, for less money or with more scope.

Problems with vendors include late delivery, unacceptable quality, and poor communications.

Problems with customers/users/stakeholders include users not being pleased with project results, changing user requirements, picking and choosing among deliverables, and setting impossible demands.