Performance Management for a Complex World

A thought provoking presentation was recently hosted by the Manchester branch of the IET on Performance Management in a Fast Moving World presented by Dr Therese Lawlor-Wright (University of Manchester), Elizabeth Jovanovic (EEF) and Andrew Wright from Dynamic Technologies Ltd.

After a brief introduction in to what performance measurement was (determining the quality of execution, competence and effectiveness of a actor or operation compared against a standard) and how it could be applied to both people (typically in the form of appraisals) and processes and systems (typically in the form of project reviews), the presentation made a few key observations about how performance measurements are currently performed.

• Organisations define performance measurements at the strategic level to see how it can achieve goals, often stated in terms of cost, quality, time and reported against a number of key performance indicators (KPIs). These can then be used to communicate and confirm (or adjust) progress.
• Any KPIs used must be balanced, fair and transparent
• The performance measurements must include indicators of the effectiveness of the organisation (the extent at which the strategic objectives are being met) and the efficiency of the organisation (how economically the resources of the organisation are being used to provide the level of performance).

Whilst the measurements can be useful, there was a word of caution in the unwanted effects of performance management systems (cited by De Bruijn (2002))

• The measurements will take too long to accumulate and will soon be out of date (data lag)
• Competition between teams or business units can result in a tendency to not share valuable data
• The measurements can stifle innovation at the expense of efficiency
• There will be 'game' playing to maximise the 'score'

These effects will dominate in the long term. To counter this, the measurements must be refreshed regularly. This should ideally be every 2 to 3 years, as this gives sufficient time for the data to be used for benchmarking/comparison purposes but short enough to counter the complacency that can arise.

Managing Performance

Having established the measurements to be made, the presentation moved on to the application of the measures in the form of performance management. Performance management needs to be both process-oriented and people-oriented and must be a continuous process (and not just an annual activity which is often the case). By being continuous it helps to clarify expectations, standards and targets and allows for any corrective actions to be addressed as soon as they arise. The most common approach for people-oriented performance management, the appraisal, should link individual targets to organisation targets but must be an opportunity to praise and develop. As expected, the audience was reminded that all objectives must be SMART. However, an alternative method of specifying a target was proposed - 'Positive - Personal - Present' which can be used to change behaviour. It can improve staff morale if done correctly, as it apparently tricks your subconscious mind into acting positively (the targets should be written starting 'I ...'). There was a strong suggestion that contrary to many organisations, performance management must not be linked to remuneration since it results in a warped approach in order to fit in with the inevitable budgetary constraints.

The Complex World

The complex world was defined as fast moving (continual change, increasing hierarchies of complexity) together with increasing challenges (timescales, budgets, mergers, multiple dependencies). These require that performance management is aligned with the business strategy. However, the classical approach to strategic management with a top-down controlling hierarchy was considered unsuitable. For complex systems,a more holistic approach is required with a thoughts being contributed from the bottom upwards.

With a fast changing environment, long-term plans quickly lose touch with reality with inflexible KPIs driving behaviours that fail to respond to the real-world challenges. Inconsistency between the strategy, real-world reality, the KPIs and the objectives inevitably quickly leads to poor performance. Clearly there needs to be an alternative approach to performance measurement which is both flexible and efficient.

Taking some of the ideas from the Agile Manifesto, a more lively and dynamic approach developed by consensus which adapts to the changing environment was proposed. This approach addressed many of the unwanted effects with the traditional performance measurement schemes by being much more efficient and flexible with an empowered organisation with a shared vision. Use of such techniques such as the Balanced Scorecard and the EFQM Excellence Model can clearly help in communicating a comprehensive view of an organisation.

Key Conclusions

• Strategy must become change oriented with a dynamic response in a controlled manner. The route to the strategic vision may change.
• Long-term plans leave companies without direction
• KPIs and objectives must respond to the changing needs
• The measurement process must be flexible and efficient
• Good performance must be encouraged by reducing uncertainty
• Organisations need to move from optimising the 'simple' status quo to optimising 'complex' continuous change

Project Management blogging

From time to time, I anonymously contribute to the BCS ProjectEye Blog on a variety of subjects related to Project Management. Some of my contributions include:

• Open Source Project Management
• Skill Deficits
• The Manchester City Project
• Agile Project Management
• Festive Thoughts
• Ensuring Timely Success
• The Sorcerer's Apprentice

The Power of the Door

I have just read an interesting presentation on the rules of productivity. It presents 8 rules to determine the most productive number of hours per week (40), the type of office environment (team rooms) and how a team should be located (non-siloed - multi-disciplined). In most cases the results are possible counter-intuitive to most management but each of the results are backed up by sound evidence.

It made me think about my experiences on numerous development projects and I would tend to agree with the recommendations outlined in the presentation. I remember when I was working long hours AND studying for a post-graduate degree trying to write some very simple Eiffel code and failing to get it work after 2 hours of staring at a simple logic problem. I simply couldn't solve it at the end of a 15 hour working day. I went home and came back a few days later, refreshed. I solved the problem in 5 minutes. The lesson was clear to me then - you need sleep, not heroes. This was admirably demonstrated in an overnight session to get a demo working and after 8 hours through the night of being in a no better situation than we were when we started!.

As organisations have changed over the years, office space has become at a premium. The 'power of the door' was demonstrated when I was a young engineer doing a major retargetting exercise. I remember we had to convince our manager of the benefit of having our own server to work on this exercise - he agreed provided we could reduce the schedule by 6 months. This we did easily, not just because of having our own server but because we had a large wooden door on our small team office. If it was shut (which it was normally) people just walked past so you didn't get disturbed. I would guess that if we reverted back to small offices, the software industry would be much more productive than it is today. I wonder how many project  managers have the power or insight to challenge the office environment and make the necessary changes that will increase the chance of project success and increase team morale. 

The role of Project Managers in Agile Projects

I recently attended Allan Kelly's presentation on 'Why and How to Become Agile', an event organised by the BCS Project Management Specialist Group. As you would expect from an experienced agile practitioner, Allan provided a good overview of what agile was and why he considered agile to be better.

However, given that the audience was mainly project managers of one sort or another, I was interested in his statements on the role of project managers in agile developments. Mainstream agile methods such as XP, SCRUM or Crystal are very silent about the role of the Project Manager. This doesn't mean that they can be dispensed with, it is just that the various agile developments concentrate on the approach to improving business value with a development rather than the associated management tasks. I know agile promotes self-organising teams (in my experience this is removing a hierarchy of developers, architects and testers) but I know of few organisations that don't allocate a project manager to a development project however small. I therefore advocate that the project manager role remains as critical as ever although the scope of some of his tasks may change.

Regardless of the development approach, all projects need to manage risk, budgets, communications and resources (physical and people). The classic management approach is for these tasks to be allocated to a (often dedicated) project manager so that the workers can get on with serious development work. I don't think there is any need for this approach to significantly change. One task which Allan indicated would change for the project manager was planning as the emphaisis on planning changes in agile developments to be much less formal. This may be appropriate for (small) purely software development projects but the vast majority of projects are multi-disciplined in which the dependencies between the various activities need to be accepted and understood by all parties regardless of the formality of capturing this information. The project manager's role still remains an important factor in the eventual success of the project and the choice of project manager is probably more important than ever. In my experience the best project managers for developments adopting some agile practices are those who are hands-on, are developers who have experienced agile first-hand, understand the project and are empowered to make decisions. It is the last point which mustn't be under-estimated; delays in decision making processes are classic signs of a development that is struggling and agile developments can't afford unnecessary delays.

I note that the latest DSDM version (Atern) now explicitly includes the role of a Project Leader (you can even get a qualification). Does this now recognise that the classic project manager now needs to more formally recognised in agile developments? I would probably say no; it is probably more a reflection on the type of organisations using DSDM who feel comfortable with an explicit role being defined rather a comment on the management of agile developments in general.

Now that agile development approaches have become more accepted as a 'normal' way of performing software developments, it is probably true to say that the role of the project manager has survived relatively intact. However the project manager now has a key role in being much more involved with the development rather than performing a purely managerial overview role; but this is what the best project managers have always done.

Are we nearly there?

The first panel at the SPA2008 Conference addressed the interesting topic 'Is Software Practice Advancing' with particular reference to the last 15 years. In summary, the panel said 'Yes, just!' after considering programming languages, software design and project management.

There hasn't been much advances in programming languages over the last 15 years (new languages such as C#, Javascript were cited) although some languages have become more popular (e.g. Haskell, Ruby) and others are now only used in maintenance tasks rather than new developments. Tooling for languages has improved with such toolsets as Eclipse, Visual Studio and IntelliJ aligned with better compilers although it is debatable if this has produced any significant change (reduction?) in development costs. There is also an increasing number of open source tools which are free which is a noticeable change for development. Programming is still unpredicatble and the risk of things going wrong hasn't changed. While languages haven't changed, there has been some significant improvements in libraries and frameworks which lead to some gains in the development life-cycle.

COMMENT: I would say that there are an increasing number of languages which are now available and supported due to the convergence on to two development platforms (Unix (and all flavours of) , and Microsoft) as the use of proprietary systems has diminished. However, the days of the coder maybe numbered as an increasing number of tools can now auto-generate significant amounts of code.

Software Design also hasn't changed significantly in the last 15 years although the debates about OO notations being finally resolved with the release of UML. Maybe what has changed is the way software is now assembled as there is now acceptance that using open-source components and 'glueing them together' is more than adequate for many applications and demonstrates good software re-use. More complex (and better?) systems are now being produced although the design skill level hasn't changed; it may actually have decreased as design becomes unfashionable as the need to 'write code and get something working' results in formal design processes being side-stepped. The production of software architecture has improved and is recognised as being of value to all developments.

COMMENT: The rise and maturity of the open-source is now having an increasing influence on software developments - the development and adoption of standards has probably helped this. The rise of the web has probably contriubuted to the loss of design fomality. There is still no substitute for expereince when designing systems. The use of tools to support the design process, particularly for large systems which are adopting model-driven developments, could lead to some changes in the perception of design and result in changes in effort profiles for software developments as the emphaisis changes to design and integration rather than coding.

The final section of interest covered project management where it was remarked that some techniques have improved, the practice is still poor. Projects have got bigger and bigger and the probability of failure has only marginally decreased over the last 15 years (still >70% chance of failure). The widespread adoption of agile and iterative life cycles over the traditional waterfall life cycle has not been as dramatic as the noise made by the agile community would have us believe.

COMMENT There is no precise definition of what Project Management is as it can cover a vast array of activities depending on the size of the development. Some approaches have been made e.g. OGC, PRINCE, DSDM to try and formalise the activities but these don't adequately address a badly specified and procured system which are often root causes of many project failures.