Reconciliation: one view of a job's true costs

Bring financial reconciliation into Sphere, so finance and the divisions could track each job's actual costs from a single source of truth.

Reconciliation is where a job's plan meets the field. Each job begins with an estimate: materials, which nearby warehouse has them, and quoted labor hours for each task, such as trenching versus laying cable, or repairing a pole versus replacing it. Crews then encounter what the survey couldn't show, such as a new building, no road access, missing easement rights, or permit issues, and return with change orders, revised estimates, new materials lists, and permit updates.

• No dedicated tool. Teams downloaded data from the Salesforce app and built their own pivot tables.
• Error-prone workflows. Approving a single work order took 24 screen changes, and about 80% of reconciliation errors traced back to browser tabs falling out of sync.
• Differing priorities. Finance and the divisions had different views on how the process should work.
• Feedback focused on process. Users spoke about workflow and behavior rather than the underlying systems, so the design needed to respond in those terms.

• One workspace per job. Views for invoices, material estimates, labor estimates, and change orders, each with an escalation map, plus a combined view. Finance could compare invoiced costs with estimates over time, and see how each change affected the estimated construction completion date (ECCD) that their projections depended on.
• Building alignment. Live demos with finance leadership, followed by guided tours that walked users through reconciliation step by step.
• QA focused on the user's experience. A front-end QA process that tested workflow and behavior, the areas users cared about most.
• Supporting a distributed team. Workshops for developers and QA, and participation in sprint planning, helped the team focus its effort where it mattered most.
• A rotating front-end pod. A small group, including a QA developer, a product owner, the project manager, and a front-end developer who rotated each sprint, set aside time every sprint to close gaps between shipped screens and approved designs.

Releases more closely matched approved designs, and developers became increasingly engaged with interaction design, which strengthened the partnership between design and engineering.

Progress was slower than it should have been. With finance, three divisions, and several product owners involved, decisions took time. Focusing on smaller wins, involving developers more directly, and holding focus groups helped, particularly with the West division, whose early support encouraged the other divisions to follow.

People judge software by how it behaves. When developers hear that feedback firsthand, it shapes what they build.