Progress Tracking Dashboard¶

Real-time visibility into POC completion across all 6 days. Update daily; identify delays early.

Daily progress template¶

Update this every day at 17:00 (during the daily standup email to BRAC).

Sample — Day 1 end-of-day¶

Date: 2026-04-25 · Time: 17:00

Phase 1 — Foundation & Infrastructure (target: EOD Day 2)¶

Overall: 30% complete (1 day done, 1 day to go)

Issue	Status	%	Done so far	Next	Owner	Blocker
#1 OpenShift cluster	🟢 In progress	60%	Provisioning complete · ODF storage configured · kubeconfig exported	Ready for Phase 2 validation (ETA: EOD Day 1)	Infrastructure Lead	None
#2 Kafka KRaft	🟢 In progress	80%	3 brokers running · topics created · Schema Registry deployed	Load test (ETA: tomorrow morning)	Platform Lead	None
#3 Redis Sentinel HA	🟢 In progress	70%	Deployment done · master elected · replication working	Failover test (ETA: tomorrow)	Platform Lead	None
#4 GitLab + Jenkins HA	🟢 In progress	50%	GitLab console accessible · Jenkins plugins installed · monorepo initialized	Sample pipeline trigger (ETA: tomorrow)	DevOps Lead	None

Phase 2 — Kubernetes Components (target: Days 3-5)¶

Overall: 0% complete — starts Day 2.

Phase 3 — Supporting Components (target: Days 5-6)¶

Overall: 0% complete — starts Day 5.

Timeline status¶

Metric	Value
Target	Phase 1 done by EOD Day 2 ✅
Actual	On track (30% of Day 1 complete as expected)
Slack	0h used · 6h available
Risk	🟢 None — ahead of schedule

Blockers & escalations¶

Blockers: None. Escalations: None.

Team status¶

Role	Focus	Notes
Infrastructure Lead	100%	Engaged
Platform Lead	100%	Engaged
DevOps Lead	80%	Helped with GitLab setup
Morale	High	Celebrating progress
Burnout risk	Low	—

Notes¶

All four Phase 1 issues progressing well
No major blockers identified
Team communication excellent
Ready to move to Phase 2 tomorrow

Next 24 hours — priorities¶

✅ Finish OpenShift validation
✅ Test Kafka load (100k msgs/sec)
✅ Failover-test Redis
✅ Trigger sample GitLab CI pipeline
🔄 Start Phase 2 (Compliance + OTel)

Weekly burndown¶

Velocity target: all 13 issues done by EOD Day 6.

Day	Target cumulative	Actual	Status
Day 1	4 issues in progress	4 🟢, 0 ✅	On track
Day 2	8 issues touched, 4 done	pending	—
Day 3	10 issues touched	pending	—
Day 4	10 (catch-up day)	pending	—
Day 5	12 issues done	pending	—
Day 6	13 issues done + demo	pending	—

gantt
    title Velocity target (cumulative issues completed)
    dateFormat YYYY-MM-DD
    axisFormat %a

    section Target
    4 by EOD Day 1          :milestone, 2026-04-25, 0d
    8 by EOD Day 2          :milestone, 2026-04-26, 0d
    10 by EOD Day 3         :milestone, 2026-04-27, 0d
    12 by EOD Day 5         :milestone, 2026-04-29, 0d
    13 by EOD Day 6         :milestone, 2026-04-30, 0d

Daily metrics (5 min to collect)¶

Completion¶

Metric	Value
Issues completed	0 / 13 (0%)
Issues in progress	4 / 13 (31%)
Issues blocked	0 / 13
Issues not started	9 / 13 (69%)

Timeline¶

Metric	Value
Hours elapsed	8h (12.5% of 64h)
Hours remaining	56h
Velocity	0.5 issues/day (need 2.2/day to finish)
On schedule?	✅ Yes
Buffer used	0h (12–15h available)

Team¶

Metric	Value
Team size	3 people
Avg hours/person/day	8h
Blocked team members	0
Morale (1-5)	4.5
Burnout risk	Low

Quality¶

Metric	Value
Issues with blockers	0
Issues with scope changes	0
Code-review turnaround (avg)	2h
Rework required	0%

If we're behind schedule¶

Behind by 4-6 hours (example: Day 2 noon)¶

Email template — subject: POC Timeline — Status Update

``` We're 4 hours behind schedule.

REASON: OTel stack integration more complex than estimated.

IMPACT: Phase 2 finish : EOD Day 3 (was Day 2) — 1 day slip Phase 3 : still on track (independent) Overall demo day : still Day 6

MITIGATION: - Cut non-critical features: skip Nexus demo (lower priority) - Keep Phase 3 parallel (recover 2 hours) - Extend Day 5 work to Night 5 (4 more hours)

NEW TIMELINE: Phase 1 : EOD Day 2 ✅ Phase 2 : EOD Day 3 (was Day 2) Phase 3 : Days 5–6 (unchanged) Demo : Day 6 (on time)

Approve, or discuss alternatives? ```

Behind by 8+ hours (example: Day 3 noon) — escalate¶

Call BRAC Bank

Present three options clearly:

Option A — extend timeline to Day 7-8 (all components)
Option B — cut Phase 3 (focus on Phase 1-2 only)
Option C — add more resources (bring in help)

State your recommendation. Let BRAC pick.

Success criteria per day¶

Day	✅ Done if…
Day 1	OpenShift 3 nodes Ready · ODF storage accessible · Kafka brokers responding · Redis running · GitLab/Jenkins consoles accessible
Day 2	Compliance scan completed · OTel traces flowing into SigNoz · SigNoz dashboards showing data · WSO2 APIM deployed, API responding · all Phase 1 components stable
Day 3	Middleware routing traffic · NGINX load balancing working · all Phase 2 components stable · Phase 3 pre-staged
Day 5	Trivy dashboard accessible · ArgoCD managing apps · Nexus repos working · JBoss domain deployed
Day 6	Demo completed · validation report generated · all code in GitHub · all docs complete · BRAC sign-off obtained

Slack-time allocation¶

Total slack: ~12-15 hours across the 6 days. Use it strategically.

Day	Slack	Intended use
Day 1	6h	2h troubleshooting · 2h documenting setup · 2h held in reserve
Day 2	2h ⚠️	1h troubleshooting (OTel is tight) · 1h held in reserve
Day 3	2h	1h troubleshooting · 1h held for Days 5-6
Days 5-6	1h ⚠️	0.5h emergency fixes · 0.5h demo buffer

Slack is a one-way door

Don't burn slack unless already behind schedule. Once it's used, you're on the critical path.

Red flags — escalate immediately¶

🚨 Critical¶

OpenShift not provisioning (Day 1, > 2h)
OTel losing traces (Day 2, any data loss)
Cluster memory > 90% (any day)
Component won't deploy due to quotas/permissions
BRAC requests major scope addition

⚠️ High¶

Component > 1h behind schedule
Team member stuck > 30 min
Code-review backlog > 3 PRs
Any data loss or security issue
Team morale dropping

📋 Medium¶

Component > 2h behind but can catch up
Documentation significantly behind
Demo prep not started by Day 5 noon
Resource usage trending high

Created: 2026-04-24 · Owner: Project Lead · Update cadence: daily at 17:00