8.2: Plan of Attack

📘Plan of Attack - Closing the Project Based Only on Weeks 1–6

In this chapter, you will complete a project closing report for the NovaMed Software Project based solely on the work performed during the first six weeks of execution. You will treat Week 6 as the “end” of the project and close it out exactly as a professional PMO would if a project was stopped prematurely.

This approach is realistic: organizations often pause, defer, or terminate projects before completion due to cost, schedule, quality, or vendor performance concerns. When a project stops early, the closeout process is still required—and must be conducted with the same rigor as a standard project closure.

Your job is to close NovaMed responsibly and professionally using only the data, deliverables, and issues uncovered in Weeks 1–6.

🔹 Step 1 – Reconstruct the Project Baseline (Using Weeks 1–6 Only)

Before closing any project—especially one halted mid-stream—you must reconstruct:

• What was expected (from Contract & SOW)

• What was actually delivered (Weeks 1–6)

• What issues and risks were identified

• What performance data is available (SPI, CPI, defects, staffing, reporting quality)

You will use:

• SOW: Expected Milestones 1–4

• Contract: Vendor responsibilities & reporting requirements

• Reporting Guidelines: Required status content

• Memo Sequence (Weeks 1–6): Execution issues

• Earned Value Template: SPI/CPI trends

• Weekly Status Template: Missing or incomplete information

• SRS & HLDD: To confirm design/functional progress

This reconstruction becomes your foundation for the closeout report.

🔹 Step 2 – Conduct a “Partial Project Acceptance Review”

Because the project ended at Week 6, none of the planned SOW milestones were fully completed. However, you must still determine what state the project ended in.

You will evaluate:

1. Work Completed (Week 1–6 Only)

Examples:

• Partial GUI development

• Partial SRS/HLDD updates

• Initial Online Product components (unstable)

• Early integration attempts

• Defect detection and triage

2. Work Not Completed

Examples:

• No completed Release 1

• Not validated documentation

• No integrated features

• No stable build

3. Work Quality Indicators

Using memos & reports:

• HLDD delays

• API mismatches

• DB schema inconsistencies

• Defect spikes (Week 4)

• Staff turnover (Week 5)

• Integration failures (Week 6)

4. Contractual Compliance

You will assess WinSoft’s compliance with:

• Reporting obligations

• Weekly status report completeness

• Staffing rules

• Milestone delivery

• Process quality

This section forms the Acceptance Assessment portion of your closing report.

🔹 Step 3 – Summarize Earned Value Performance (Weeks 1–6)

Using the EVM template:

You will compute:

• PV, EV, AC for Weeks 1–6

• SV, CV

• SPI, CPI

• Trend analysis (degrading performance)

Then interpret:

• Project is behind schedule (SPI < 1.0 from early weeks)

• Project is over cost (CPI < 1.0 from Week 3 onward)

• Trends worsened (Week 6: SPI 0.68, CPI 0.71)

This becomes the Performance Evaluation portion of your closing report.

🔹 Step 4 – Finalize Outstanding Issues & Risks

You will create a partial Defect & Issue Summary, which only includes defects discovered up to Week 6.

This includes:

• 27 defects (Week 4)

• Integration defects (Week 6)

• Architecture inconsistencies

• Unapproved scope suggestion (Week 5)

• Staffing instability (Week 5)

• Reporting non-compliance (Week 1, 3, 6)

You will classify:

• Critical issues

• Open defects

• Issues requiring future attention

• Risks that would affect future work

This becomes the Outstanding Issues & Risks section of the closing report.

🔹 Step 5 – Conduct Preliminary Vendor Performance Evaluation

Although the project did not reach completion, you will still complete a vendor evaluation based on six weeks of behavior.

Evaluate WinSoft on:

• Schedule performance: Late HLDD, missed reporting

• Cost performance: CPI < 1.0

• Quality performance: Defect spikes, unstable builds

• Staffing discipline: Mid-level dev resignation without notice

• Reporting discipline: Missing EV, missing Bulls-Eye charts

• Communication quality: Incomplete explanations, vague updates

This becomes the Vendor Performance Review section.

🔹 Step 6 – Prepare the Project Closeout Report (Core Deliverable)

Your Project Closeout Report will summarize the entire six-week period:

Include:

1. Project Overview (why it stopped at Week 6)

2. Status Summary (scope/schedule/cost/quality/team snapshots)

3. Deliverables Completed vs. Planned

4. Earned Value Summary

5. Open Defects & Issues

6. Vendor Performance Evaluation

7. Contractual Compliance Review

8. Recommendation for Next Steps

   • Continue project with changes?

   • Pause?

   • Terminate the vendor?

   • Revise scope or timeline?

9. Lessons Learned

📁 Final Deliverable Name:
CBay_NovaMed_CloseoutReport_YourName.docx

🔹 Step 7 – Submit the Required Deliverables

For Chapter 6, you will submit:

Required:

• ✔ Project Closeout Report

• ✔ Acceptance Matrix (Partial)

• ✔ Documentation Checklist (Partial)

• ✔ Open Defect Summary

• ✔ Final EVM Summary

• ✔ Vendor Performance Evaluation Form

• ✔ Closeout Reflection

Because project ended at Week 6:

• No Release 1–4 acceptance

• No Final Product

• No system-level testing

Your closing report reflects the reality of stopping early.

🔹 Step 8 – Reflect on What Project Closing Taught You

You will complete a short reflection analyzing:

• What closing a partially completed project taught you

• What you learned about vendor accountability

• How early issues compound over time

• What project signals should have been recognized earlier

• How leadership behaves when projects fail or stall