We use cookies and similar technologies to improve your experience on our site. By continuing to browse, you consent to our use of cookies. For more details, see our Privacy Policy. California residents: we do not sell your personal information.

    Back to Blog
    Kahua Implementation

    Why Kahua Implementations Stall in Phase Three

    Why Kahua Implementations Stall in Phase Three

    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.

    Start Free Trial