Making the Design Authority more effective

Share this post:

Making the Smart Meter Programme Design Authority more effective

I think it is safe to say that the use of a Design Authority in cross functional programmes like Smart Metering has been an accepted best practice for some time now.

But why are some DAs more effective than others?

During the nine years that I’ve been working on Smart Metering and Meter Data Management System (MDMS) projects I’ve collected some “themes” that I think answer this question.

Start with an Executive Sponsor or “Champion”

Newly formed Design Authorities always need a senior executive sponsor or champion who can coach them on how to be effective within the organisation and help them put their recommendations into practice. Much as we’d all like to go from Novice to Revered Authority in one step – we can’t. It takes hard work, dedication and sustained delivery excellence to build up organisational influence and a reputation for good advice and decisions. The same is true for each new DA.

The executive sponsor also provides much needed organisational legitimacy or “clout” to the new DA. The need for this role should decline as the DA builds its own reputation and organisational influence.

Frequent escalations or appeals to the executive sponsor can be an early warning sign that the DA is struggling to establish itself. On the other hand, evidence that project teams actively seek out the advice and counsel of the DA is an early indicator that the DA is succeeding.

Define “effective”

The stakeholders in cross functional programmes like smart metering will have widely divergent perspectives on what makes a DA effective. For example:

  • IT managers will look to the DA to make and enforce standards across projects;
  • Technical architects will look to the DA to resolve (possibly through arbitration) the answer to complex technical issues and cross project infrastructure conflicts; and
  • Business sponsors will look to the DA to protect committed business benefits

Each of these perspectives could be a full time job and left to its own, a newly formed DA will struggle to adequately server all stakeholders.

Choosing a realistic mix of priorities and putting measurements in place to support them will accomplish two very important things:

  • Focus the limited time and resources of the DA effectively:
    • A common challenge that a new DA must deal with is a barrage of topics and / or disputes. An agreed set of priorities will help in establishing the order in which topics are dealt with and allay stakeholder concern that they are note getting an appropriate share of the DA’s attention.
  • Quantify the benefits of the DA:
    • Measurements will allow the DA, and more importantly the stakeholders paying for the DA, to taken an objective view of the DA’s accomplishments;
    • A common criticism of a new DA that does not have clear measurements is that it only ever has meetings – it never makes decisions or recommendations.

Establish process early and document decisions

The DA should be an exemplar of architecture best practices including the use of artefacts like the Architecture Decisions document. This document and the process that goes with it will serve two very important purposes. First it will communicate DA decisions outward to stakeholders and affected parties. Second it will serve as a record of the thinking and evaluation that went into specific decisions that can be reviewed whenever debate on a given topic comes up again.

The process followed by a DA should have a degree of formalism to it such that people new to the DA can understand how it functions and how they can successfully engage with it.

 

DA process

 

Evolve the DA as it gains credibility and influence

The structure of the DA needs to reflect the size of the project or programme that it has been established to work on. Based on the programme size and scope the DA can have any of the following shapes.

DA shapes

Successful DAs that I have worked with tend to be those that have started small with a direct link to a specific project and have then evolved as they have been given greater scope and responsibility.

Restrict membership

Ever been to a working group that fills a room and is still effective? Me neither.

One of the big challenges with any DA is keeping the number of participants to a workable number while still providing required coverage for complex topics and multiple stakeholder organisations.

A technique that can help with this challenge is to establish different categories of participation. This approach starts with a core decision making membership at the centre that then builds outward to include extended team members brought in to address specific domains or represent specific stakeholders. A third tier could include external subject matter experts who provide needed depth in areas where the DA membership may not have sufficient experience.

DA membership

There is no “silver bullet”

Every DA I have been involved with has had to evolve from its starting point and address the points above to work within organisational structure and realities.


Special thanks to my colleagues in IBM Canada Delivery Excellence: Tom Bridge; and Sharon Hartung for their work on Design Authorities and from whom I’ve plagiarised shamelessly!


The posts on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.

Solution Architect

More stories

Risks to Machine Learning in Solution Architecture

In this blog post I had planned to cover the way that our agile group dealt with an unexpected major change to our cloud service provider and its implications for Solution Architects. Stay tuned for that one! In its place I’d like to share a discussion about the challenges faced by Solution Architects when it comes […]

Continue reading

It is all about the end state!

Every Meter Data Management System (MDMS) project that I’ve worked on has started out as a small technology proof of concept or vendor selection exercise that has grown over time to become a full production infrastructure – often supporting millions of meter end points. Given that solution architects often have to live with the incremental […]

Continue reading

The “mentoring dilemma” after a year

I has been a year since I wrote a blog post (The Mentoring Dilemma) on how to make the mentoring process more “real”. In that year the IOS mobile app project that we started has come a long way so let’s step back and discuss some of the outcomes. Apple App Store availability! The app […]

Continue reading