SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Here are just three definitions. They don’t contradict but neither do they quite agree. With a bit of research, I’m sure you could find several more quite easily. Again, they wouldn’t quite agree, and wouldn’t quite contradict. Add to this the more colloquial use of the term to describe a particular activity in a particular organisation (e.g. intrusive project reviews), and it is easy to see how people can end up talking at cross purposes. One person’s “assurance” is another person’s “audit”. When one says “assurance”, another hears “trust”. The answer is to adopt a very broad understanding. In that way the risk of missing an important aspect is minimised. Adopting a broad definition brings another challenge, though: that of understanding their interactions. For some projects, this challenge is a major one, even to the extent that satisfying all aspects of the assurance animal actually and ironically threatens project success. If we take a theoretical project, or project-based organisation, one can identify all of the various providers of assurance. Doing this can be rather alarming and eye-opening. But it is an essential start to developing an integrated approach. &lt;CLICK&gt;
Right, returning to the topic, one of the difficulties when talking about assurance is that people mean different things by the term. People know that they want assurance but what that actually means to each individual, depending on their role – or stake in the project – can differ appreciably. In essence, they are all really asking the same question: is the project going to successful? But they need the answer articulated and focussed in a way that is specific to them. For some, the technical and performance aspects of the project is all that they are interested in. For others, it is how much it is all going to cost that is paramount. They are all right, of course, and approaches to assurance need to make sure that all their needs are catered for. To use a much overused term, assurance provision needs to be done holistically. The trouble is, different assurance mechanisms tend to be set up to meet one specific group of stakeholders’ needs, like: engineering assurance looking at technical aspects; cost assurance looking at value for money; finance functions looking at financial controls; and operational assurance looking at fitness for purpose. All of these tend to work in silos, ignoring inefficient overlaps, and sometimes even conflicting with each other. There is generally very little that is holistic about it. What’s needed is some form of integration, led by a party that has no allegiance to any particular flavour of assurance. PMOs have a role to play in this, I think. In my experience, there is no standard way to achieve this integration. It will depend upon size of organisation, complexity of projects, characteristics of stakeholders, and many other factors. What’s needed is not a standard solution but a standard approach to developing tailored solutions. Before we can develop a solution, though, we need to fully understand the assurance picture. Let’s start with the word “assurance” itself. &lt;CLICK&gt;
All of these you will probably recognise. Some of them are obviously involved in projects. But some of them are less so. For example, where does Internal Audit fit in? What has control self assurance got to do with projects? Furthermore, do processes provide assurance? And systems? Already the picture we are building is starting to get quite complex. Now, if we overlay on that the customers of assurance…&lt;CLICK&gt;
…and the picture becomes even more complex. Add to that that some of these customers are themselves providers of assurance to others, and a nightmare picture can quickly emerge. A convenient example to reflect on is that of delivering the London2012 Games. According to the then Head of Risk assurance at LOCOG, there were 44 distinct bodies in the most independent area of their assurance map! Unless a way can be found to organise all this, &lt;CLICK&gt; the result is likely to be somewhat frustrating to anyone whose job it is to actually deliver stuff! Someone needs to take responsibility for doing that coordination, or at least for making sure that it happens. In most project organisations, an obvious contender would be the PMO, and I’d like now to present some thoughts on that to you. &lt;CLICK&gt;
Sometimes referred to as The Integrated Assurance Strategy I don’t have time to go through the whole of this, so I will just pick on what I think is the single most important element: Principles and standards. &lt;CLICK&gt; Be doing this, we set some rules by which relationships between different providers could be defined. Assurance types could be compared and contrasted, and importantly a common standard for the quality of assurance could be achieved. This paved the way for aligning assurance planning and reporting. These are the principles and standards. &lt;CLICK&gt;
The model goes like this. An organisation undertakes activities and by doing so is subject to a number of risks. &lt;CLICK&gt; In order to control those risks, the organisation’s management introduce ‘controls’, such as management systems, polices & procedures, and standards, to try to ensure that things are done in a particular way. &lt;CLICK&gt; This is known as the organisation’s First Line of Defence against the risks. Having introduced these controls, management needs to ensure that people are following them properly. For this it introduces compliance functions, like Quality Assurance, Risk Management and PMOs. &lt;CLICK&gt; This is know as the organisation’s Second Line of Defence. There are usually then other functions that are imposed on management, such as Internal and External Audit, and in the case of Transport for London the Independent Investment Programme Advisory Group that I mentioned earlier. &lt;CLICK&gt; This the Third Line of Defence. Whereas the first two lines are sequential, the third line tends to oversee the whole picture of risks, control and management assurance. This is, I am sure you would agree!, an interesting model but in itself it does not help much. It is very important in helping us to understand the relationships between assurance providers, and where a particular function ‘fits in’ but something else is needed for it to be of practical use. That ‘something else’ is ‘assurance mapping’. &lt;CLICK&gt;
Assurance maps are really very simple tools. They are just two-by-two matrices, showing areas where assurance is needed (e.g. an organisation’s risks) down the left, and sources of assurance (i.e. assurance providers) that exist within the organisation. Where rows and columns cross, information is included about the extent to which assurance is available. The template I am showing you here is one that I have prepared by sanitising a real one. Maps can be produced for a complete organisation or for parts of it. The parts could be organisational (e.g. a specific project or department) or for an activity (e.g. project management). Whatever the entity that the map needs to cover, the risk areas (or risk-related activities) associated with that entity are listed down the left. Next, the organisation’s sources of assurance are listed along the top, grouped into the three lines of defence. The most ‘first-line’ is at the left, and the most ‘third-line’ are towards the right. Exactly how the relationship between risk or activity and assurance source is shown is not that important. Essentially the purpose is to capture a view of whether assurance exists and the ‘quality’ of that assurance. What can also be shown (although the map starts to get more complicated when you do so) is what the assurance says about the effectiveness of control over risks. I will show you a practical example of one of these maps. &lt;CLICK&gt;
It is important to bear in mind that maps are just a tool. They are no solution to anything on their own. They merely provide a straightforward way of thinking through the relationships between risks and assurance within organisations. Maps can become horribly complicated, and many hours can be spent trying to ‘get them right’, when in reality there probably is rarely if ever a point at which they are ‘right’ from every perspective. The real power of the maps is the analysis that has to be done to produce them, and what is learned from them. One is looking for overlaps and gaps; opportunities to enhance or reduce assurance; and areas where assurance could be provided at a more appropriate level. This example is one that was produced for ‘Project Assurance’ within Transport for London, which is the responsibility of one a part of the TfL PMO. &lt;CLICK&gt; Along the top are the sources of assurance over project activity. In the first line we have such things as ‘Management Reporting’ and ‘Programme Boards’. At the right we have third line providers such as Internal Audit and IIPAG. &lt;CLICK&gt; Down the left we have a list of ‘Lines of Enquiry’, which, like the 10 criteria in the ‘Assurance Assessment Toolkit’ that I talked about before, are a consistent set of criteria against which projects are assessed in TfL. You may have challenges to some of the content of this map, either from a theoretical point of view, or from a more practical one if you know TfL. But that doesn’t really matter. As I said, there is no such thing as a ‘right’ map, only one that is fit for purpose. It would be very counter-productive to be too purist about their use. &lt;CLICK&gt; Now, looking at the mapping, and without homing in on anywhere in particular, you can see that there are no lines of enquiry that are not covered by at least one provider, there are no providers that are redundant, most assurance provision is of a satisfactory quality (the green squares), but there are a few where provision could be improved. This is not saying anything about whether TfL is managing its projects well, only whether management can be comfortable with what is being told about how well projects are being managed. Overall, this shows a pretty healthy picture, but highlights something to management that they may not have been aware of without such an analysis, i.e. where to focus their attention in future assurance planning. I could speak for a lot longer about this map, and about assurance mapping in general, but I really just wanted to illustrate their use. Like with any tool, sensible use is essential, but used intelligently and honestly, they can be a very powerful means to get the right people talking together about assurance, which after all for many is not the most scintillating of topics! &lt;PAUSE&gt; That brings me to the of my talk, but before I finish and ask for questions, I’d just like to plug the Assurance SIG a bit. &lt;CLICK&gt;
We have four work streams under way. &lt;CLICK&gt; Firstly, is the Integrated Assurance one that I have already mentioned. Following publication of the Guide, we are planning to develop material for training purposes. In particular, we are planning to developing some scenarios to illustrate how Integrated Assurance can be implemented. &lt;CLICK&gt; Secondly, we are developing a Guide to Project Auditing. This will follow on from the guidance that we wrote for the Institute of Internal Auditors. &lt;CLICK&gt; Thirdly, the other Guide I already mentioned was the ‘Assurance assessment toolkit’ , which was provided by the Measures for Assuring Projects work stream. This work stream may continue past publication of the guide (and there are certainly other avenues to explore) but that is uncertain at present. &lt;CLICK&gt; Lastly, we are launching a new work stream on the topic of assuring Agile projects. We held a very successful conference in November on this topic last November, at which a very clear need for some guidance emerged. If anyone here would like to know more about the Assurance SIG, and/or would like to get involved with us, please contact me.
Mark Reilly, Association for Project Management
Project assurance: ensuring the pre-
requisites for success are in place
Mark Reilly M.Eng C.Eng MICE MAPM,
Transport for London, and
APM Specific Interest Group on Assurance
What exactly is assurance?
• assurance n. Emphatic declaration, guarantee; self-confidence,
assertiveness; insurance esp. of life; certainty. (Source: The Pocket
1. the act of assuring
2. the state of being assured; sureness; confidence; certainty
3. something said or done to inspire confidence, as a promise,
positive statement, etc.; guarantee
• P3 assurance The process of providing confidence to
stakeholders that projects, programmes and portfolios will
achieve their scope, time, cost and quality objectives, and
realise their benefits.
What is the Assurer often asked?
18 Oct 06 3
• I need to know that everything is under control?
• Is what I am being told is correct?
• I am going to get what I want?
• Will the project going to finish on time and within
• If things are going horribly wrong and should I can
18 Oct 06 4
18 Oct 06 5
Project Boards / SROs
Integrated Assurance Framework
• Map the assurance communities of interest
• Establish a lead assurance provider for the project
• Provide a comprehensive, shared and consistent
view of risk
• Set out the standards for Assurance
• Map assurance interventions
18 Oct 06 6
18 Oct 06 7
Three Lines of Defence Model for Assurance
The APM Assurance SIG
18 Oct 06
4 work streams currently under way:
– Integrated assurance
• Developing an approach to collaborative working between assurance
– Project Auditing
• Sharing approaches and experiences in project auditing, and developing
best practice guidance
– Measures for Assuring Projects
• Investigating and developing guidance on measures that can be used to
– Assurance of Agile projects
• Development of guidance to applying assurance principles in fast-
moving Agile environments