Chapter 6: Governing Design Decisions

A month into the build, the call came for Fiona.

Nadia Petrov was direct. "We have a problem. The employer integration module is behind schedule. The data mapping is more complex than anyone estimated. Tom Beaulieu's spreadsheets contain fifteen years of employer relationships stored in formats that do not map cleanly to any standard data model. If we keep the employer integration in scope for this phase, we push the advising platform launch by three months. I want to descope it."

Ravi Kapoor had a proposal. "I can simplify the architecture. Instead of full employer integration, we build a basic employer directory. Name, contact, industry. No relationship history, no placement tracking, no cross-faculty matching. We can add the full integration later. It gets us back on schedule."

Fiona listened. Both were being responsible. Nadia was protecting the timeline. Ravi was solving a technical problem. Neither was wrong about the facts.

But Fiona knew something neither of them was weighing. The employer integration was not a feature. It was the mechanism through which Lakeshore would extend Tom Beaulieu's employer partnership model from Health Sciences to all faculties. The architecture had identified student-employer connection as one of three critical capabilities. Ravi's simplified directory would give the institution a list of employers. It would not give it a capability. Tom's fifteen years of relationship data, the placement outcomes, the cross-referencing of student skills to employer needs: that was the capability. A contact list was not a substitute. It was a placeholder that would never be revisited because the team would move on to the next initiative.

This chapter is about the unplanned decisions of delivery: the ones that arise when the build team hits rock where plans assumed soil, and someone proposes a change that looks reasonable but quietly erodes the strategic intent the architecture was designed to protect.