1. Putting Attenuation in the right place
This is probably the easiest step, and one that many projects get right. Methodologies like DSDM Atern1 consciously recognise that you can’t always identify everything that needs to be done up front and that actually it is OK to introduce additional requirements so long as they are effectively prioritised; but also that you can’t allow things to be added uncontrolled2. At a higher level, one also sees the idea of a prioritisation funnel or filter being used for portfolio management3. So the idea of having an input attenuator is firmly embedded in project management, but perhaps needs greater prominence in the various methodologies and bodies of knowledge. I would like to see them adopting a diagram similar to the one I used in part 1 of this series (based on Beer’s work) because it clearly shows the importance of this step. The diagram below focuses on the attenuator in order to highlight where it should occur for projects.There are multiple input paths into a project, but they can be broken down into the following key stages:
- Project set-up: includes mandate, brief and business case
- Project approval
- Change control during project implementation
- Formal monitoring throughout project lifecycle (plan, budget, risk, etc.)
The four stages listed above can be further summarised as “Project approval” and “Project implementation”, and we need attenuators for each of them. Stafford Beer’s Viable Systems Model provides the mechanism by which we can see where these attenuators should be placed because Project approval is a management function and sits with VSM’s system 4, whilst implementation is operational so sits in system 1.
 |
| Viable Systems Model (Stafford Beer) |
Case study example
For illustration, we shall use the simple example of purchasing an IT system to enable a customer-facing reception desk to log calls (a mini-CRM). The system will also provide analysis and reporting so that the staffing levels on the reception desk can be planned more effectively and intelligence about the kinds of issues that customers raise will be gained. This will be referred to throughout as the Reception System Project.Variety in the environment and system 4
At the stage where approval for the Reception System Project is being sought, the key tool is the Business Case. So this document needs to successfully attenuate in order that requisite variety is provided. This is the System 4 role: and projects need effective analysis of their environments whereby the unnecessary “noise” is filtered out, but also changes are noted so that the filtering can be adjusted if necessary.Filter 1: Business Case
The Business Case for Reception System Project needs to include the normal why, what, when and how information, and in order to obtain this an analysis of the environment is needed (among other things). For example the why might include benefits such as better information about customer needs and better workforce planning. A typical tool to use here is benefit mapping4, as this helps focus on what the project aims to achieve, and thus automatically provides the filtering (attenuation) that is required. Similarly part of the how will be a cost analysis, and the business case only needs enough financial information to determine cost and affordability (cost-benefit analysis) – it doesn’t need a very detailed project budget breakdown. These, and other typical Business Case tools (e.g. PESTLE and SWOT analysis) are all attenuation tools.System 4 is one of the roles of the Project Board, but one that in my experience is seldom understood or done effectively. The Board’s role in this respect is to filter out unnecessary environmental noise so that the project can concentrate on the key inputs. The vehicle for this is the Business Case, but too often it is not written with the full engagement of the Board. My personal experience is that usually the Project Manager writes the Business Case and there is little or no input from the Board other than to sign it off.
Filter 2: Business Case review
The environment will change over time. All good project methodologies mention that the Business Case should be reviewed throughout a project: how often does this take place in reality? Very rarely in my experience. A second role of the Project Board, therefore, is to review the Business Case both in terms of internal project delivery (I will return to this in a later post) and to see whether things have changed to the extent that the scope needs revisiting. The Project Board is responsible for continued review of the Business Case to ensure that relevant changes to the environment are spotted and taken into account.In Reception System Project we might find that customers start to prefer to contact us online rather than in person (this should come out of the system 4 environment scanning role). This will alter the justification for the system – for example we might decide to close our reception altogether and set up a virtual online reception instead. Again, in my experience, such reviews of the Business Case seldom take place, and projects that are either no longer needed or that need to change their scope, drift on regardless.
Variety in the environment and system 1
The focus of system 4 is on the larger environment, and how that might impact the goals of the project. The focus of system 1 is on the immediate environment and how that might impact the delivery of those goals. The key players here are the project teams and team leaders.In the Reception System Project example where customer contact preferences change, this could manifest itself locally, at system 1 level, as well as at system 4 level. If system 4 is working well, we might be able to see the change before it hits us. However, if this is not identified, then system 1 will feel the impact through the changed patterns of contact. This should be fed back into the internal information flows (which will be the subject of the next post).
Smaller environmental issues will also be detected at system 1 level (which may not impact the project as a whole). For example we might discover that customers are finding it hard to park (in order to visit the reception) and a small change in operations (e.g. reserving customer spaces) can fix this.
Filter 3: Business Change Manager / Project Manager
In both cases there needs to be a mechanism for effectively capturing the information that matters so it can be dealt with, but typically projects do not have such mechanisms in place. The closest I have seen is in the Managing Successful Programmes methodology5, where there is the suggestion that there is the role of Business Change Manager (which, incidentally, comes from the Benefit Realisation Management approach4).Since most projects will lack this role, it will normally be the project manager who fulfils the role. In Beer’s VSM the project manager is part of system 2, and in fact this works well because the system 2 role is around regulating the information flows between the operations (system 1) and management (systems 3 and above).
So the good news is that project management has reasonable structure in place to carry out effective attenuation of incoming information. The weaknesses are that:
- The Project Board often does not fulfil its role effectively;
- Attenuation during implementation is perhaps not explicit enough in terms of the project manager’s role.
The next post in this series will look at information flow within the project (system) and where attenuation/amplification fits in.
References
1) DSDM Consortium (2010) Agile Project Management Handbook2) McKinlay, M. (2007) ‘Managing Requirements’ in Gower Handbook of Project Management (Turner, R. ed), 4th ed., pp. 261-273
3) Thiry, M. (2007) ‘Managing Portfolios of Projects’, in Gower Handbook of Project Management (Turner, R. ed), 4th ed., pp. 58-68
4) Bradley, G. (2010) Benefit Realisation Management (2nd Edition)
5) Office of Government Commerce (2007) Managing Successful Programmes
No comments:
Post a Comment