Category Archives: Design Authority

Major UK water utility – Architecture and design assurance

As in the last few articles, we are still keeping it real by talking about track record which illustrates and reinforces our blog topics.

This week we discuss an architecture and design assurance, the process of ensuring that what is designed matches what gets built. We discuss this process in “Adding confidence and transparency through a Design Authority. A design authority is the group or person responsible for ensuring a solution meets goals, needs and specifications. A design authority defines and employs technical strategies, architecture standards and design methodologies.”

This client invests between $40 and $60 MM a year in IT projects.  However, these projects had a history of time and capital overruns, troubled implementation, and failed benefit delivery.  One of the fundamental causes of erratic project delivery was allowing the architectural vision to be driven by IT suppliers and not business requirements or technical standards.

What we found?

  • Fragmented solutions that were almost beyond the leading-edge of technology.
  • This resulted in high-risk implementations and increasing project and operational costs

What we did

PA helped the client change the nature of projects to remove these problems—more specifically:

  • They chose to implement a central architecture and design assurance function in order to instill controls that would ensure project delivery across the organization.
  • A small team assessed the existing estate, portfolio of projects, and IS strategy as well as defined an architectural blueprint and associated key technology policies. 

What was achieved?

  • The implementation of a business-driven architectural vision and strategy that would simplify the project solutions and remove operational risk. 
  • Implementing proactive control – implementing the vision required control of individual projects and programs of work.  The next stage was to ensure that projects did not deviate from the strategy.
  • Communicating and embedding the process and maintaining the improvement of project performance was essential to ensure that the design assurance mechanisms became part of the normal routine. 

A discrete Design Authority function, working in conjunction with project teams, is a well-proven way to be confident that you will get what you set out to achieve.  The Design Authority function takes an end-to-end view of the design and, using a business focused perspective, ensures that the program will deliver business value.  The image above illustrates how tracing each level of the solution to the original vision validates that what is being built will provide what is required.  While this approach exists in all Design Authority functions, it may take different forms depending on the program.  

John Hall – PA Consulting Group


Design Authority – Architecture and Design Standards

In a previous post Become a Master of Your Domain I talked about the four major domains of the Design Authority (DA) V-model and how together they help ensure that our systems are designed as architected, and that the systems are implemented as designed. In this post we will start sharing some key ideas around the first domain: Architecture and Design Standards.

 In this domain, the DA develops the early-stage design methodologies.  The DA leads stakeholders to agreement on architecture standards and high level design blueprints for applications, information, infrastructure, service management and security.

Throughout the program lifecycle, the DA conducts reviews, mediates design negotiations and communicates design decisions to ensure that the designs meet business goals and minimize late-stage changes to product requirements.

Below is a sample list of DA responsibilities around Architecture and Design Standards.

  • The DA is responsible for ensuring the quality of all program architectural, design and business deliverables prior to signoff. The DA has ownership of any periodic audits of the documentation.
  • The DA performs architecture analysis and communicates the direction of the program’s architectural and business views with regard to process, deliverables and timelines.
  • The DA interfaces between all program solution design architects (including vendors) and co-ordination with business analysts and stakeholders.
  • The DA verifies that the entrance criteria are met before work streams move into each stage gate review. If not, the DA documents the increased risk due to non-approved architectural design or other issues. The DA provides risk mitigation suggestions for the program.
  • The DA verifies that the exit criteria are met before the project moves to the Implementation phase. If not, the DA documents the increased risk due to non-approved design or other issues. The DA provides risk mitigation suggestions for the program.
  • The DA owns the development of architectural and business work plans, coordinating between program work stream leads and analyzing the consolidated plan to ensure the program is leveraging each individual work stream appropriately (e.g., no duplication and adequate coverage for each work stream)
  • The DA identifies, plans and coordinates successive, continuous streams of potential work for the program given an understanding of next set of domain capabilities
  • The DA establishes and enforces “best fit” development methodology and design standards for the program.
  • The DA aligns project work with domain level design to validate against logical target architecture.
  • The DA contributes to technical design trade off analysis, threat and risk reviews (Architecture and design review)
  • The DA aligns lifecycle processes across all program work streams.
  • The DA identifies any design/implementation risks relevant to each phase of development and determines which require mitigation plans.
  • The DA evaluates previous design/implementation risks to identify those that no longer apply or that have changed priority based on changes in probability or impact.
  • The DA checks that preventive measures and/or contingency plans exist for all identified design risk items and that the risk, with mitigations in place, is acceptable for moving to the Implementation phase.

On the next post, I will discuss Requirements Engineering. Thank you for reading.

Andre Michel Vargas

PA Consulting Group

Design Authority – Mitigating the dynamic impacts of rework on complex programs

In my last post “Traceability enables optimal design decisions for your program” I discussed how traceability is a great tool for the Design Authority for managing design decisions in a program across multiple work streams. In this post, I want to introduce some system dynamics around program management and how understanding the secondary effects of our decisions impact program risks and delivery efficiency. There are many versions of this system dynamics model and perhaps too complex and spaghetti-like to have an image of here. I will just discuss the key relevant ideas for Design Authority.

Complex systems are not easy for humans to understand completely. When things work well in a complex system and we can’t explain how and why, we say it is explained by “emergence” or the “invisible hand”. Complex programs have these qualities, human heroics make things happen. But, these human heroics suffer from our limited understanding of the secondary effects of our actions, sometimes causing unintended consequences and undesired outcomes that ultimately have negative impacts on the program in terms of costs overruns, missed time deadlines, lowered team morale, quality etc. In system dynamics terms, the most used models discuss the role of “undiscovered rework” as the cause that kicks off these negative dynamics.

A few of these negative dynamics below:

  • Too big to manage –  The bigger the project the more complex communications and coordination impacts productivity
  • Burnout  – When we fall behind on schedule, we sometimes kick off a death march which burns out the team, and more issues appear downstream causing more rework.
  • Haste makes waste – Cracking the whip to speed up will introduce errors which then impact downstream efforts. And if you like Lean, waste is your enemy.
  • Experience dilution – Hiring and staffing up to cope with the work load dilutes team experience, adds training overhead and negatively impacts productivity.
  • Haste creates out-of-sequence work – All this extra rework, that is introduced through these dynamics, must be addressed, and based on the prioritization culture, these typically end up creating out of sequence work.
  • Errors create more work – An obvious one, all undiscovered errors are extra work, and I am sure we did not plan for them very well.
  • Hopelessness – Morale decreases as all these issues and pressures pile up.
  • Product owners often change scope or requirements – People hate change, change does not care. The impacts of change ripple throughout the program.
  • Poor schedule performance – slipping deadlines, causes project sponsors to lose confidence in delivery.
  • Reduced product owner confidence – Lower confidence means less trust and a tightening of controls and maybe a requirement to start a death march, so it all starts over again.

What can we do to reduce the impacts of change and rework in our programs and adopt the right program behaviors that proactively mitigate these risks?

Your Design Authority (DA) is in a great position to help your program mitigate these dynamics. In addition to improving behavior through management of the rework cycle, the DA can significantly improve program performance through efforts to manage ripple and knock-on effects by

  • Acknowledge that these dynamics exist and plan for them.
  • Ensuring the right design standards are adhered to, and ensuring the architecture is adaptable to change. This means that sometimes the right approach is to slow down and do work right the first time.
  • Evangelizing proper requirements management (user stories management). Adopting traceability practices to reduce the risk that design trade-offs will cause rework downstream.
  • Ensuring robust prioritization and optimal sequencing of work. Undiscovered rework can be reduced, for example, by prioritizing rework detection and correction over starting new work.
  • Ensuring testing to discover problems rather than testing to pass tests to also reduce rework cycle consequences. You can adopt test driven development and continuous integration to move the discovery of rework upstream and reduce the cost of rework (which includes all the secondary impacts of rework).
  • Use integrated product teams, which improve quality and rework discovery at the expense of reduced productivity from greater communications overheads.

The DA must manage this behavioral change carefully because the implementation of mitigation activities like the ones described here initiate a “worse before better” behavior. The DA by effectively demonstrating any worse-before-better improvements and the eventual benefits of implementation, it will greatly help the program stakeholders stick with implementation. For example, allocating more resources to QA reduces “perceived progress” while actually increasing “real progress”. Such actions may be difficult to stick with unless the DA helps managers have confidence that the “better” will occur after the “worse”.

Ok, so now, after introducing the DA V-model and domains, and discussed traceability and dynamics of undiscovered rework, we are ready to dive into each of the activities the DA can perform to increase complex program delivery confidence.

Andre Michel Vargas

%d bloggers like this: