
Kahua implementations rarely fail in Phase 1. Discovery feels productive. Stakeholders show up. Mockups get reviewed. Optimism is high. The wheels come off in Phase 3, when the integration build is supposed to be wrapping up and dashboards are supposed to be coming online. That is when the rework starts, the timeline slips, and the client starts asking uncomfortable questions.
We have walked into enough mid-flight Kahua programs to see the same pattern repeat. The stall is almost never a tooling problem. It is a sequencing problem that traces back to four specific decisions made earlier in the project.
Decision 1: Treating Discovery as a Workshop, Not a Specification
Discovery sessions that produce sticky notes and slide decks are not discovery. They are alignment. Real discovery produces a signed configuration specification: roles, permissions, workflow routing, approval thresholds, cost code structure, fund hierarchy, document numbering rules, and integration field mappings. If those decisions are not documented and signed before configuration begins, every workflow built in Phase 2 becomes a draft that gets rebuilt in Phase 3.
Decision 2: Starting Cost Configuration Before Sources of Funds Is Locked
On bond-funded programs, Sources of Funds is the spine. Cost Management hangs off it. If the fund structure changes after Cost Management is configured, every budget, commitment, and pay application needs to be reworked. We treat Sources of Funds as the first cost-side decision, not the last.
Decision 3: Underestimating the ERP Integration
kConnect is capable. The ERP on the other side is the variable. Banner, Oracle, SAP, and Lawson each have their own quirks around encumbrances, commitments, and journal entries. Field mapping looks simple in a workshop and turns out to be specific in production. If the integration scope is set in Phase 1 with a placeholder estimate and never revisited, Phase 3 becomes a renegotiation instead of a build.
Decision 4: Building Dashboards Before the Data Model Is Stable
Power BI dashboards are the most visible deliverable on a Kahua program. They are also the most fragile. If the cost data model is still moving, every dashboard is a moving target. We do not start dashboard builds until the cost structure, fund structure, and integration data shapes are locked. Anything earlier is throwaway work.
The Pattern
All four of these decisions look like Phase 1 decisions. They get made under time pressure, without enough technical depth in the room, and they go unrevisited until Phase 3 forces the conversation. The fix is not faster Phase 3 work. It is a more disciplined Phase 1.
We run dedicated technical discovery sessions in parallel with the program manager's stakeholder interviews so the configuration specification is grounded in the actual integration landscape, not a wishlist. It is the cheapest insurance you can buy on a Kahua program.
Planning a Kahua implementation?
Join hundreds of AEC teams already saving hours every week.