Project case studies

The problem

The blocker was not technical. Scope had never been firmly agreed, the original delivery plan no longer reflected reality, and resource and budget assumptions had gone unvalidated.

• Equipment had been ordered before the design was finalized.
• Work had started before requirements and dependencies were validated.
• Client users faced continued disruption while the $85K stayed tied up.

Outcome

• Implementation delivered within six weeks of takeover.
• Stakeholder confidence restored; the project moved from at-risk to delivered.
• Budget preserved, and no further delay added to the schedule.

What I did

1. Redefined scope. Established what was actually in and out, and secured agreement from each stakeholder group before restarting work.
2. Rebuilt the delivery plan. Replaced the obsolete schedule with a plan built around genuine capacity and real dependencies.
3. Resequenced workstreams. Ordered the work so the highest-risk dependencies were confronted first rather than deferred.
4. Validated resource and budget assumptions. Confirmed what was truly available instead of inheriting the original estimates.
5. Escalated blockers deliberately. Surfaced the issues that would not resolve on their own, with a clear ask attached to each.
6. Coordinated vendor inputs. Worked the network vendor and the ISP to secure firm delivery dates and confirmed configuration.

The problem

At this volume the risk is not any single project failing. It is losing the ability to see which one is about to. Without a consistent reporting structure, status becomes anecdotal, resource conflicts surface too late, and the loudest project consumes attention regardless of actual risk.

Outcome

• All nine projects tracked through planning, execution, delivery, go-live support, and closeout with consistent status visibility.
• At-risk timelines, scope changes, and resource constraints identified early enough to course-correct rather than absorb.
• Eight of the nine projects delivered on or ahead of target.
• Leadership adopted the reporting format for ongoing reviews.

What I built

1. A single tracking layer. Project schedules, dashboards, and action item trackers maintained in Smartsheet, Jira, SharePoint, and Excel, so every project reported in the same shape.
2. RAID and decision logs. Risks, assumptions, issues, dependencies, and decisions captured in writing so context survived staff changes and time gaps.
3. A predictable reporting cadence. Regular project reviews and stakeholder meetings with documented decisions and clearly elevated concerns.
4. Change and closeout discipline. Change documentation and closeout summaries produced consistently rather than only when a project went badly.
5. A clear escalation threshold. I escalated blockers that threatened a milestone or required a decision outside the team, and absorbed the rest rather than spending attention I would need later.

The problem

• Handoffs between people varied depending on who was involved.
• Roles and responsibilities were understood informally rather than defined.
• Priorities, blockers, and capacity constraints were not visible until they became urgent.
• Missed handoffs were causing repeat follow-ups and delaying completion of routine tasks.

Outcome

• 15% improvement in workflow efficiency, measured by weekly throughput and average turnaround time.
• Fewer repeat errors, and fewer payroll and timecard corrections after rollout.
• Reduced rework and clearer accountability across the team.
• Procedures and templates continued in use beyond the initial rollout.

What I did

1. Standardized handoffs. Defined how work transferred between people so quality did not depend on who was on shift.
2. Clarified roles and responsibilities. Made ownership explicit and documented, eliminating the assumption gaps that caused rework.
3. Built repeatable tracking. Introduced consistent processes, templates, and communication routines the team could actually sustain.
4. Increased visibility. Surfaced priorities, blockers, risks, capacity needs, and performance metrics on a regular rhythm.
5. Closed the loop on recurring issues. Documented root causes, recommended improvements, and reinforced consistent use of the new procedures.

The problem

On a decommission, the record is a deliverable in its own right. Photographs accumulate fast and are easily treated as proof that a control was performed. They are not. An image establishes a condition at a moment. It does not establish that a circuit was isolated, that an asset was logged, that removal was authorised, or when any of it happened.

A photo set presented as a process record invites exactly that mistake, and the cost lands at closeout, when someone asks for evidence the record was never able to provide.

Where the record stands

• Interim revision issued to the project team under controlled distribution, not released to the client.
• Every open item written down as a specific question against the site log and asset register, so closing the record is a task list rather than a judgement call.
• Stages with no photographic evidence stated in the document itself, so the set cannot be mistaken for complete.

What I did

1. Separated observation from inference. Each entry describes only what is visible in the frame. Authorisations, isolation records, asset logging, dates, and location references are excluded from that field by rule.
2. Made every unknown explicit. Each photograph carries its own verification checklist: aisle and row identifier, capture date and shift, isolation record, the approved decommission list authorising removal.
3. Flagged conflicts instead of smoothing them. Where rack type, overhead structure, and wall finish showed a second environment, the entry says so and holds a provisional area reference rather than assuming one site.
4. Stated the coverage gaps up front. Baseline condition, power-down and isolation, asset tagging at point of removal, data destruction, custody transfer to the recycler, and frame removal are listed as unevidenced.
5. Sequenced by work stage, not capture time. Capture dates were not recorded on this revision, so the ordering rests on stage and the site team account, and the document says exactly that.
6. Set a close-out standard. The record cannot be restated as verified or issued for client walkthrough until every verification item is resolved and certificates of data destruction and recycling are attached.