20 tips to get an architecture project back on track

Establishing an efficient, light, but strict architectural governance framework is vital to keeping enterprise architecture projects on track—and rescuing programs that are already in trouble. Setting up a design authority led by the chief architect to oversee the project is beneficial to establishing and maintaining your governance framework.

Imagine you are assigned to a project that is in the red, where the review report contains a long list of urgent remediation actions, even though you still need to show progress on it. This is a difficult situation for any enterprise architect.

As a chief architect, I have to remediate many of these types of troubled projects and bring them back under control. In these situations, I find a design authority incredibly helpful.

What is a design authority?

"Design authority" is another term for architectural governance. It helps keep project workstreams organized. It is a model for managing the effectiveness of your organizational alignment, including ensuring all the right people are involved and the right resources are being used, aiding a project through the design pipeline. 

A strong ROI is one desired outcome for any chief architect or executive. But often, it's easy for the race to the finish line to overshadow the strategies used to get there. A design authority is a body put in place to manage, track, and fulfill project progress more holistically. The design authority evaluates all elements of a project—cost, skill and resource requirements, potential security concerns, feasibility, and more—from every angle.

[ Download the eBook Culture Matters to learn how to develop an organizational culture that fosters innovation and keeps teams unified. ]

20 tips for establishing a successful design authority

Here are some practical tips I've learned through my experience that I hope will help you successfully maneuver through situations where a project has gone off track.

1. Maintaining good communications across the project is essential. 
2. Your primary focus with troubled projects is to establish transparency and traceability for every decision.
3. Always keep a positive attitude and be respectful in your communications so that everyone feels safe to express their concerns to the leadership team.
4. Ensure you have executive sponsorship to empower the chief architect to make technical decisions alongside the design authority.
5. Know your team of architects and subject-matter experts. Who are the key technical people who were involved in the solution design? Who was making decisions?
6. Understand who the decision makers are at the executive level, both on the client side and internally. Ensure that the key people are in sync with establishing a proper design authority and understand its role and purpose.
7. Nominate the key decision makers as core members of the design authority. Include people from relevant business units and technical domains, but try to limit the core team to five to eight people, and leverage extended teams to clarify business and technical decisions when required.
8. Explain to all stakeholders on the project how the design authority will operate and the role of each core member.
9. Ensure that every action item raised to the design authority is time-bound with clear ownership for proper accountability, and document them in the meeting minutes.
10. Document where the design authority approves key architectural decisions, and share key decisions with the teams in written form so that there is a record of them. 
11. Communicate the decision-making process, actors, organizational chart, and core team to the entire program team.
12. Communicate the technical decision-approval process to all technical and business squads so that everyone is aware of the escalation and approval process, including when to escalate. The design authority should not end up as the bottleneck where every decision is approved. Squad leaders should try to resolve issues as much as possible at their respective levels with the support of the tech lead or architect in their squads before escalating something to the design authority.
13. Ensure that decisions made in the design authority get communicated back to the teams on the ground for awareness and action. The action owner in the design authority is responsible for communicating these decisions to their respective teams. Too often, decisions get made at the management level without being shared with the broader teams, which leads to confusion and miscommunication among teams.
14. Create templates for key architecture work products to be delivered.
15. Keep project documents in a shared folder accessible by the client and internal core team members.
16. Minimize technical documentation as much as possible, and make sure that whatever gets produced is what is being used by teams on the ground.
17. Similarly, establish a simple and clear work product-tracking system in a central repository that is accessible to both client and internal teams.
18. Schedule the regular design authority meetings when the entire core team can attend regularly, but have them designate backups in case they can't attend a meeting in person. Everyone should come to the meeting prepared to be able to decide and take action on specific topics.
19. If you're working with a client, meet regularly with its chief architect (outside of the design authority) to discuss key decisions, roadmap items, and issues in advance of escalations.
20. Establish a regular, weekly squad-leader meeting so that everyone is aware of what's happening and if there is any impact on their scope based on decisions made by other squads.

How to make decisions that are beyond the design authority's scope

When decisions impact financial costs and strategic business decisions, you must bring the program management team into the picture early. This is especially the case with change requests if there is scope creep or gaps in the solution that require additional solutions.

Maintain proper documentation and trace these issues back to the last approved decision or contractual agreement. Present the situation to the executive team with pros, cons, and cost or financial implications before escalating it to the client. Documentation and traceability are critical to minimize time spent in discussions with the client and to keep the discussions factual.

Assign the program management team to communicate with the client and decide how to manage the situation. Normally, a higher-level board above the design authority (at the executive level) should settle such situations with the client's partner or project executive. The role of the chief architect is to ensure the sound technical viability of the solution based on the client's requirements and that the solution aligns with the scope of the contractual agreement.

Get back on track

Establishing proper program governance is the first step in getting an enterprise architecture project back on track when it has gone out of control. While these situations are complex to manage, I hope these tips will make it easier for you to resolve them.