CHAPTER 9: GOVERNANCE OF LEAN PROJECTS
Overview
The Association for Project Management (APM) defines governance as follows:
‘ … the set of policies, regulations, functions, processes, procedures and responsibilities that define the establishment, management and control of projects … ’ (see http://knowledge.apm.org.uk/bok/governance)
From this we can see that governance is about control – i.e. the reduction or management of risk. It also involves stated principles, processes, clearly defined roles and responsibilities, and some ongoing independent review or audit. We will consider each of these themes in this chapter, together with the challenge of maintaining security, governance and control, whilst at the same time reducing waste and delivering what customers want.
Lean projects and activities also require governance to demonstrate how risks have been identified, monitored and controlled.
Governance risks for lean
PRINCE2 defines a risk as:
‘An uncertain event or set of events that, should it occur, will have an effect on the achievement of the objectives.’
We measure risk by assigning a likelihood or probability that it will occur and a potential impact if it does.
Like all projects, the main risks could lead to issues associated with:
• cost overruns
• time overruns
• failure to meet agreed objectives (including controls and expected quality levels).
Also, given the experimental and changing nature of lean projects, there is a higher risk from unknown/difficult to predict issues.
Individual risks can be expressed in terms of an event, trigger and consequence. For example:
The lean project may be delayed (event) because the main sponsor leaves (trigger), resulting in failure to achieve predicted savings in the medium term (consequence).
Additional costs may be incurred, because the main supplier takes legal action to delay early closure of the contract, leading to delays in achieving savings and bad publicity.
There are a number of techniques to identify and assess risks for a lean project:
1. Review of the strategic risks of the organisation to identify those relevant to the project (e.g. relating to competitor activity, compliance, cost constraints).
2. Workshops with project representatives and senior stakeholders to brainstorm likely risk areas, to create risk heat maps and suggest mitigations.
3. Review of lessons learnt from previous similar projects, including the ability to realise benefits from similar projects, causes of delays or cost overruns.
4. The maturity of the organisation in undertaking this type of project.
5. SWOT analysis (strengths, weaknesses, opportunities and threats).
6. Root cause analysis to ensure that the underlying cause of a risk is documented and assessed rather than just a symptom or consequence.
Once the risks have been identified and assessed they should be logged and recorded so that governance reporting can show how they are being mitigated, whether new risks arise, and to show where the risk results in an actual issue.
Governance principles and organisation
The stated principles (in the form of guidelines, standards and procedures), an organisational structure, and culture of an organisation, will set the context for the way that governance operates. They help to communicate the level of empowerment and authority within the organisation. In particular, how the strategic objectives set by senior management and the Board are translated into operational and tactical management at other levels.
Lean governance is based more on delegation and enabling teams so they are motivated to achieve their required objectives for their projects or other areas of responsibility. This is different to the more traditional approach on projects based upon centralised command and control, with project management offices and steering boards often providing very detailed levels of control, dictating standardised reporting and ways of working, and defining priorities sometimes to quite a low level of detail. Agile and lean encourage greater autonomy within teams. For example, in Agile Scrum each team will often set its own charter defining the working ‘rules’ for the team. It is based on the principle that teams are composed of mature professionals.
I once worked for an organisation where there was a moratorium on leave in January and February each year as these were busy months. But our team’s busy period was May and June. So we could book as much leave as we wanted in June but not in January! Lean recognises the need for flexibility. It is not only in the interests of the team but of the organisation and its customers.
This requires a pragmatic approach from those responsible for governance in an organisation. This relinquishing of control can make them feel uncomfortable and insecure, and the risk is that as soon as something goes wrong they will revert to a more traditional command and control structure. Given the experimental nature of lean, there is an increased likelihood of such events. However, a good, pragmatic, lean governing body will be aware of this and take steps to:
1. Ensure the impact is minimalised, for example by use of pilot projects and planned release based on risk.
2. Have a contingency plan to consider how they will react in certain situations.
3. Clearly state the reasons for the rules they set, rather than just stating that they should be followed.
4. Create an empowered environment where people are aware of the risks they can take and any limitations.
5. Ensure that everyone has the resources required to deliver what is expected of them, on budget and on time. For example, this may mean the provision of tools and processes that are non-standard for an organisation but will allow better interaction with third parties or collaborative working within the team.
6. Be supportive, providing recognition for achievements and support, rather than apportionment of blame and recrimination when things go wrong.
The above will demonstrate that the Board are aiming for high-level strategic governance rather than detailed micro-management. These steps should be communicated and affirmed by visible actions and behaviours. Where teams know they are trusted and have some control over how they manage themselves, they are less likely to ignore and rebel against the rules. Governance then becomes embedded in the process, rather than being seen as a wasteful muda overhead.
Imagine a scenario where a lean project has delivered the expected small benefits and now could be expanded across the whole organisation, with a very high return for low cost. This should not be a problem – you would expect most organisations to say ‘go ahead, get on with it’. However, in my experience a number of organisations have such rigid controls over projects that the roll out would be stopped, as there is not the budget to pay for it – the budget is already committed to other projects, some of which may have a lower forecasted rate of return. One organisation I know of expects a return on investment within one year, even though they capitalise project expenditure over three years.
A lean organisation has a more customer driven approach to project pipeline management. For example, by providing a fast track for projects that can demonstrate immediate strategic benefits. This will be based on a scorecard system to demonstrate the value to the customer.
Governance processes and metrics
Good governance relies on a framework of processes and metrics to enable informed decisions to be made. The main practices associated with lean hence have an impact on how governance is achieved and monitored. Especially:
• The use of delivery in smaller iterations.
• Flexible milestones relating to risk and benefit rather than pre-determined stage gates.
• The project approach itself changing based on learnings as the work progresses to achieve continuous learning.
• Compliance and control embedded into the process, rather than added on as an afterthought.
• Focusing on the best metrics, rather than ones that encourage the wrong behaviours.
The use of delivery within specified shorter time boxes needs quicker and slicker decision making. In a time box of 28 days, if an issue arises it needs to be resolved immediately – it is no good deferring to the next steering board which may be in two months’ time. Also, if the new process is to be released within the next 30 days, the mind is more focused than it is two years away. Governance needs to consider the implications of this – also the impact of team fatigue, when in effect you can have a go live every 28 days. The release procedures of some organisations may be too inflexible to allow the releases to happen at the optimal time for the lean or agile project, causing delays in achieving identified benefits and a risk that competitors may get there first.
The pressure to make a release can, however, be a risk itself. There still needs to be go/no go type decision taken independently so that all of the potential risks are identified and resolved. This could be based on leaner testing and more emphasis on customer value – for example the product or service may meet the requirements (MVP – or minimum viable product) but will it fully meet the customers’ expectations for look and feel (MLP – minimum loveable product)? This could be just as important to the success of the product with customers or other users.
I worked on a hybrid agile/lean/waterfall project where we demonstrated the application to senior management prior to release. They agreed that we had met the brief but asked for some refinements to make it more easy to use and with a more attractive user interface. Go live was put back by about one month whilst we made these changes. Those from a waterfall background considered this as a failure. Those of us from a more agile mindset, however, considered this to be a success. The final version was improved and customer feedback was very encouraging. The real metric of importance was not around time to release – it was about whether customers could and would use the tool and have an enjoyable experience in the process. We also developed specific KPIs to monitor the process post go live, to identify any potential issues. These were just temporary metrics and in the longer term different metrics were required.
Project approaches used need to be adaptable to fit the nature of a lean project. Every project is different with different risks, compliance and security requirements, team members and extent of agility/lean required. However, most organisations stick with a fixed, rigid style of governance – this can cause a tremendous overhead on smaller iteration projects, offsetting some of the achieved benefits. Greater flexibility can provide improved team productivity, leading to a more efficient, effective and economic process – with better continuous learning and improvement. This is also more rewarding for the teams concerned, especially where they can see their suggestions and comments being acted upon promptly, which was not always the case on ‘lessons learnt’ sessions for waterfall projects I have attended in the past.
By embedding or automating lean governance, it becomes easier to comply than to not comply! If, however, the effort required is large, teams will consider it as waste and focus instead on what they see as being more important. This could become a risk, particularly if there are regulatory or reporting requirements (e.g. for compliance with Sarbanes-Oxley Act), as these views may not be those of the senior stakeholders. Some human judgement will still be required but often lean principles can be applied to simplify and automate the process for data gathering, wherever possible using metrics and tools that the team use for their management to summarise key points for upward reporting. Getting governance/compliance right first time is surely a lean principle worth adhering to – reducing waste later in the process or elsewhere in the organisation.
To achieve this, metrics need to be relevant and simple to obtain, especially as lean projects are likely to be subject to continuous monitoring, as the regular cycles may be too long to identify any issues during the life of the shorter project. To be relevant, lean metrics need to be related to the key drivers of waste and customer benefit. The lean project should be run in a lean way. There needs to be some way of taking the management metrics for the project and converting them into the governance metrics required by the organisation. Data for metrics should be accurate, timely, consistent over reporting periods, and capable of being repeatable – i.e. results over different projects will be compatible with similar assumptions and timelines.
Governance responsibilities and roles
Policies, processes and measures are important components of governance. However, to be fully effective governance also requires commitment from people. As a contractor, I have worked in many organisations and they all start with a health and safety induction. All of these emphasise values, such as ensuring everyone gets home safely and speaking up. Yet my attitude in a risk situation will depend more on the culture and my feelings than it will on checklists and procedures. Indeed, some say that the procedures go too far (phrases, such as ‘health and safety gone mad’). So policies, such as not taking phone calls whilst driving, or what to do when the fire alarm goes, are important – but more important is ‘do I feel empowered to challenge when I see these policies being broken’? Am I able to challenge the individual and make them aware of the risks they are taking? This depends on the culture of the organisation and its attitude to risk. The same principles apply to lean project teams and how empowered they feel they are. Good lean governance relies on this feeling of empowerment, as underpinned by promotion of self-organising teams and the alignment of policies to lean values.
The term self-organising is often confused with self-managing teams. The lean project team is still part of the organisation – there to provide value to customers and reduce waste. Self-organisation in a lean context means lean teams/individuals have greater control over:
• The work performed – however this selection needs to be within the strategic framework and priorities of the organisation.
• How they commit to and perform work, including just in time planning.
• The application of the 5Ss.
The team leaders are still accountable and need to ensure adequate communication of the plan, progress, risks and issues, both within the team and to senior stakeholders.
The alignment of HR policies to lean objectives is to ensure that people are treated as mature professionals, and talent is retained and motivated to be innovative as well as productive. Some organisations seem to stifle innovation – it is a greater risk to someone’s career to try a new idea that partly fails than to not make the suggestion in the first place. Innovative organisations I have worked in take a different approach – making it acceptable to fail, as even if the first three out of four ideas fail, the fourth may be a cracker!
Arrangements for personal development, performance measurement and reward need to reflect the desire for collaboration and team working. For example, the contribution of a good mentor can be more effective in ensuring customer value and reducing waste than the direct benefit achieved from a single individual’s delivery. One way to measure this is to place greater importance on 360o feedback from peers rather than just relying on feedback from often remote management. The emphasis should be on encouraging the innovative/entrepreneurial behaviours required to drive customer value and reduce waste.
In 1968 Melvin Conway submitted a paper ‘How Do Committees Invent?’ to Datamation, the major IT magazine at that time. The basis has become known as Conway’s Law and can be summarised as follows:
‘Any organization that designs a system …. will produce a design whose structure is a copy of the organisation’s communication structure.’2
To put it another way, innovative solutions require innovative organisations and governance. I cannot imagine Facebook being created from within an organisation, such as the large computer companies in the 1970s, or in a government department. Likewise, modern developers may struggle to create the highly defined, structured and compliant software often associated with these organisations.
Lean also relies on quality – and this too needs to be embedded within the team ethos and HR policies. But it needs to be defined in a lean way – quality is often taken as being about ticking the right boxes, however as we have seen, lean puts the emphasis on customer value and so it is this that is the real measure. I have been in call centres when all of a sudden there is a loud whoop of joy and round of applause. This is because one of the operators has received a perfect score on the customer feedback process – this leads to instant recognition and reward. For project teams this is rare. On some projects the team has been rewarded with anything from doughnuts to a team night out. On other projects, however, despite the success of the project there were insufficient funds to fund such a reward.
Challenge of maintaining security and control whilst reducing waste
Governance is still necessary for lean projects but it needs to be seen in a context of encouraging the right behaviours and coming from the team up, rather than being dictated as a series of restrictive policies dictated from the top.
There can be a trade-off between control and the need to be lean. For example, a review may identify an area as potential muda which actually has an indirect impact on governance or compliance across the organisation, or on the ability of the organisation to maintain reasonable levels of IT security. I have also come across the converse though where control was increased following a lean change. In this case, monthly reporting activities had been transferred to a centralised offshore team. There was supposed to be a significant saving, however, this was not realised as the onshore teams continued to do some of the control activities, duplicating what was being done offshore. The monitoring of controls had not been updated to reflect the current process.
Audits of lean governance
An independent audit of a lean project or assurance exercise will ensure that:
• The governance process is appropriate for the project.
• Benefits obtained are real and are directly attributable to the project.
• Monitoring is in place to identify any small changes required to the process, etc. to eliminate any additional waste.
• There is sufficient visibility of the importance of the project.
• Stakeholders can be given independent assurance on the effectiveness, economy and efficiency of the project process and assurance that any issues discovered will be avoided in future projects.
The following questions could be included in a review of lean project governance:
1. Have the governing body the right level of control over the governance of the project, without too much involvement in day-to-day project management?
2. Are all team members aware of their governance responsibilities?
3. Is there evidence of ongoing monitoring and review throughout the life of the project?
4. How can it be demonstrated that the project has met its objectives and achieved the benefits?
5. What steps (e.g. independent review) have been take to identify any additional benefits?
Summary
The governance of lean projects and other lean activities is important to ensure that key stakeholders have the comfort and assurance that their key objectives will be achieved. It is also important to ensure that there is ongoing activity to maintain continuous improvement, and to identify and communicate areas of best practice (and areas for development).
_________________________