Lovely day at The Shard!
best practiceI went to a fascinating talk by Adam Hoyle, Managing Director, Tradax Group Ltd, on Corporate Best Practice in Public Sector Bidding. I thought there were a number of lessons that apply more generally to running all kinds of projects that would be worth sharing.

Seven best practice tips

  • Don’t start projects unless they align with your overall strategy
Obvious, but I’ve often seen it ignored in the heat of the moment, too!
  • Make sure you have thought through exactly what decision-making authority each person involved should have, and that this has been clearly communicated and understood
In my experience the latter are frequently neglected, even if the former is not. Too many people think governance is boring, so don’t bother. It should provide the rock that success is built on
  • Give everyone involved a clear written briefing pack at the start, providing them with all the basic information about the project that they will require
Saves a lot of repetition, and makes sure everyone has a single reference point they can go back to, so things are more likely to join up later. It saves you time in the long run
  • Standardise what you can – but everything that is standardised needs an owner who takes their ownership seriously
We all know how fast most of the stuff on our intranets goes out of date, but still sits there. The corollary may also be true: what you can’t find an owner for, you probably won’t be able to standardise effectively
  • Think hard about what information would really make a difference to your performance if you had it, and work creatively (legally of course) to get it – for example using FoI requests
I think the key is identifying what information would lead to specific and worthwhile improvement actions if you had it. Too often, people ask for information without having thought about what they would do with it. When they get the answer, they realise it is interesting, but not actionable
  • Use the information you have intelligently – there is probably much more that you can learn than is immediately obvious, if you put it all together
E.g. draw graphs of trends across projects, and work out what they are telling you. And don’t ignore what you see because you don’t like the message, as people often do!
  • Transitions between teams – for example on winning a bid, or starting to operate an asset – are high-risk boundaries, which need careful planning to make sure they go smoothly
I recommend running readiness reviews for these. It is not the review that counts – by then it may be too late – but the knowledge that that discipline will happen Do go and listen to Adam talk and hear his views on best practice first-hand, if you get the chance! He’s an inspiring speaker.
Read More >>

Wake up!
As a consultant, I have many discussions with people who might be future clients. I never quite know at the start of the conversation where it will go – I’m there to listen for the opportunity, to understand what the client needs (perhaps before they do), and to help them to decide whether I might be an effective part of the answer, whatever it might be. Until they explain their situation, I can’t tell where we may finish up. Even so, I was taken aback recently when I was told quite out of the blue at the start of a client meeting that I thought was going to be the usual consultant’s exploratory discussion, that it was effectively an interview for a senior role in their team (I’ll talk about miscommunications another time!). My immediate reaction was to express my surprise at this turn of events, while inwardly panicking slightly and trying to think very fast about what this role would involve, what experience I would therefore need to tell them about, and whether I even thought I could do it. Afterwards I realised that although I had gone into the meeting with my flexible ‘I’m a consultant, just tell me what the problem is’ hat on, the hat was not that flexible. It took me a few minutes to adjust to the new situation, and to feel comfortable again. We all put ourselves in boxes – even ones with somewhat flexible walls, or room to rattle about in – all the time. The walls of the boxes are safe and comforting. Outside the walls lies danger (at least that’s how it feels) – but also opportunity. How hard it is to allow ourselves to be born into that new world of wider opportunity – but like birth, how essential it is if we are to grow!
Read More >>

Who’s marking your homework?
For the last few weeks I have been posting about general principles of governance. Let’s turn to a practical example: How do those principles apply to programme management? There is of course no one ‘right way’ – it depends on the context. However, there definitely are ‘wrong’ ways, and they are all too common! Most programmes have a Programme Director, and most have a Programme Board. What are their roles, and how should they be related?

Programme Board

The Programme Board should be a fundamental part of the governance structure. There would be no point in it being there unless it makes decisions. To do that, it must be given authority by some other body, which must itself have the authority to do that. Programme Boards typically have as part of their role resolving cross-functional issues for the programme. Consequently, they will normally be set up to report to a committee within the governance structure which itself has cross-functional representation. If the Programme Board is unable to resolve an issue which comes to it, normally its parent will need to. If a Programme Board were to report to an individual, it would be hard to see how that individual could more effectively resolve any cross-functional issue that had to be escalated.

Programme Director

The Programme Director’s role will vary in detail between programmes, but fundamentally he or she is the person accountable for making sure that the expected outcomes of the programme are delivered within the constraints agreed. That leads us to two further points. First, if they are accountable, who will hold them to account? That is another part of the role of the Programme Board. The Programme Director will present progress reports, papers for decision, etc to the Programme Board, to enable them to do that. A corollary is that the Programme Director should be appointed, or at least confirmed, by the Programme Board, which will also delegate authority. If things are not going well, it is the Programme Board that must decide whether a change of Programme Director is required. Second, what is the nature of the relationship between the Programme Director and the Programme Board? Essentially it is like a contract. The Programme Board is the customer for the programme, approving the programme requirements. The Programme Director represents the delivery team - the contractor, if you will - and needs to make sure that sufficient time and resources are allocated to the programme to deliver the requirements. Clearly making the two join up may require negotiation. If there are subsequent changes to requirements, agreeing how to accommodate these – extra resource, recognising more risk, delay or reduced quality – will require a further negotiation. Remember, accountability and authority need to go together. Just as with the CEO and a company Board, it is clear that the Programme Director has a fundamentally different role to that of the Programme Board, and to blur these distinctions will introduce conflicts of interest. Of course the Programme Director will normally attend Programme Boards, although that does not mean that they have to be a member (and the different roles are clearer if they are not). Either way, though, they should never be the Chair: they would have a clear conflict of interest. At best they would be tempted to steer the agenda away from certain issues, and it would become impossible for the Board to be effective in holding them to account. No-one should be asked to mark their own homework! It follows that the members of the Programme Board should not normally be junior to the Programme Director, and certainly should not be his or her direct reports. Of course there is a place for meetings of the Programme Team – but those are progress meetings, not Programme Boards. Do your Programme Boards follow these rules?
Read More >>

15 principles for internal governance
So, seven articles later, where does that leave us? We have talked about 15 principles for designing your internal governance, and I have listed them all together for you below for convenience. However, I do want to re-emphasise one thing I said at the beginning: “What good governance is NOT about is bureaucracy, box-ticking and delays. It requires finding balances – between control and practical delivery; between the risks of delegation and the cost of control; between wide ownership of decisions and strong accountability for them; between a simple structure and efficient decision-making; between minimum overhead and an effective audit trail – which provide the optimum basis for success. Every organisation has different arrangements because the optimum trade-offs depend on the context.” The principles for internal governance are just the things you should have in mind when you design your system. That does not mean that the result has to be complicated. It should be ONLY as complicated as you need it to be in your particular circumstances. If you are a large public sector organisation, it may be necessary to be at the high-control end of the spectrum. If you are a small development company, you probably need something much lighter-weight and more flexible – but that is not a reason for not thinking about it. Some principles are good-practice rules which are likely to apply everywhere. Others are choices you need to make. The important thing is that the choices you make should be deliberate, and should be consistent. By deciding exactly what principles for internal governance you are going to work to before you start, you give yourself the best chance of success.

15 Principles for Internal Governance

  1. Authority and accountability must go together.
  2. No-one will have authority to ‘mark their own homework’ (i.e. conflicts of interest will be avoided).
  3. Collective and Individual Authority are different. What will their respective roles and interfaces be in the structure you will create?
  4. The governance structure should be strictly hierarchical. All bodies which have Collective Authority must have a place within that hierarchy.
  5. Individual Authority is delegated through the line management arrangements, but it forms part of the overall governance structure and must join up seamlessly with the rest of it.
  6. The design should start by establishing those areas where the Board should make delegations (starting by noting the matters already reserved to the Board), and how they should be grouped.
  7. What (if any) dual-key approval arrangements are desirable?
  8. The authority grid should include qualitative as well as quantitative delegation limits, and should not be restricted to areas where a financial limit can be set.
  9. Escalation levels will be set to provide an appropriate volume of requirements to escalate, decided on the basis of business need and practical delivery.
  10. Decisions about committee membership should be made in the light of the delegation levels set, not the other way round.
  11. The list of staff (or roles) to be included as members of the Collective Authority bodies will balance the need for ownership of decisions with minimum meeting membership.
  12. Clear rules for meeting attendance will be agreed and maintained.
  13. What formal documentation (e.g. Terms of Reference, Letters of Appointment) will be mandated?
  14. In what circumstances will formal authorisation and/or acceptance of documentation be mandated?
  15. How widely will the arrangements be communicated?
The full articles in this series can be found at these links:
  1. The Midas Touch - what is Governance for?
  2. The Midas Touch again - Starting to build Internal Governance
  3. The Midas Touch again - Authority and Accountability in Internal Governance
  4. How many ways can you design a tree? - Hierarchy in Internal Governance
  5. Snakes and Ladders - Delegation and Escalation in Internal Governance
  6. Why are YOU here? Choosing members of Internal Governance Meetings
  7. What's in a word? Documentation for Governance
Read More >>

What’s in a word? Documentation for governance
This is article 7 in my series on designing internal governance. As we discussed at the start of these articles, the need for governance arises because we want to be able to exercise the degree of control we need over our organisation. In the previous six articles, the structures we may establish to provide this have been discussed at some length. However, we might as well not bother unless we communicate clearly and effectively what we have set up, why, and how it helps everyone! This article considers what documentation is required in order to support good internal governance. Talking people through the way the governance is intended to work is always a good idea. People listen when you tell them stories – and I know I often stop listening when there isn’t some kind of story – because story is how we make sense of things. Talking about how it should work allows you to weave in stories about why it is the way it is, as I have tried to do in these articles, which may maintain interest and help people to see the benefits as well as the irritations.

Documentation for governance

However, talking alone is not enough. The story people hear is not always exactly the one you told. If it was not written down, who is to say whose memory is right? Documentation is there to make sure that there is a definitive reference point to go back to when disagreements arise. There is a good reason why, although verbal contracts are legally binding, people generally prefer the written sort!

Governance as a contract

Think of governance as a form of contract: we specify what authority we are giving, to whom and under what circumstances, and what accountability we are getting in return. The documentation records the terms of the contract, shows that it was agreed, and provides evidence that it was complied with. The documentation required for governance should balance the need to avoid unnecessary bureaucracy with the need for documents which can resolve later differences of opinion, provide traceability and auditability, and also (depending on circumstances) meet the need for transparency. Authorities delegated should be clearly set out in Letters of Appointment (Individual) or in Terms of Reference (Collective), signed as issued by an authorised person, and signed as accepted by the person being authorised. You don’t want to hear "I never received that", or "that's not what I understood". Where Collective authority is granted, as a minimum there must be a written record of all decisions made, and of those present at the time (to demonstrate that the quorum was present, so that the terms of the delegation were satisfied).

Words matter!

Documentation is about communication, not just about record keeping. The language used matters. This is difficult: clearly where important decisions are made, accuracy is essential, but it must not be at the expense of intelligibility by all. Old-fashioned legalese may have been very precise in its meaning, provided you understood the code, but was almost as unintelligible as a foreign language to most people. If you want people to stick to what you meant to authorise them to do, and to accept accountability for what you expect, there is no room for ambiguity. Woolly or opaque language makes it easy for people to say “Oh, that’s not what I thought you meant”. Use plain English, short sentences, simple constructions, and not convoluted prose, as far as you can. Don’t use several words when one will do! Even better, use diagrams where appropriate. But however hard that is, write it down somehow: however it is written, it is always better than nothing!

Principles to be established:

  • What formal documentation (e.g. Terms of Reference, Letters of Appointment) is appropriate
  • The circumstances where formal authorisation and/or acceptance of documentation will be required
  • How widely the arrangements will be communicated
Read More >>