Pragmatic Projects

You have a concept, a plan and a team, and now you're about to start your project. But hold on a second: are your objectives coherent, or are you trying to change an organisation in two completely different ways. Are you about to start a Push-Me Pull-You Project?

Let's think about why we try to change things. At a high level, we can identify three dimensions of change, each concentrating on improving a different aspect of an organisation:

• CAPACITY - Projects whose goal is to increase productivity; for example, by conducting more transactions or achieving greater sales volume using existing staff and resources.
• COST - Projects whose goal is to increase efficiency, identify savings and reduce unnecessary spend.
• CONSERVATION - Projects whose goal is to maintain the status quo, protect the organisation from exceptional events and respond to a change in the surrounding environment.

These theoretical types provide us with a quick guide as to the coherence of a planned project. In practice the scope of works may wander across these hard boundaries but unless the overall objective can be largely contained in one dimension, then the Project executive and team are setting themselves up for future headaches.

Consider a project that is designed to achieve an equal mixture of CAPACITY/COST objectives. The team will be trying to achieve more with the same resources - increasing productivity - at the same time as trying to achieve the same with fewer resources - increasing efficiency. These two objectives are mutually exclusive, and we have a textbook example of a Push-Me Pull-You Project.

How can we measure improvements in productivity if we are also cutting resource levels. Equally, how can we improve efficiency if an organisation is in the midst of changes to their processes and other ways of working in pursuit of productivity?

To resolve this situation pragmatically, we must accept that the Project exists to serve the host organisation, so there is little to be gained from refusing the scope of works. But we can structure that work in such a way that we are not trying to push and pull at the same time. The optimum approach is cyclical, where the project implements change in one dimension, validates that change against the original scope and then allows a period of stability before undertaking change in a different dimension.

Alternatively, one can partition an organisation in such a way that different dimensions of change can occur simultaneously - for example in different departments or business units. This approach is attractive in that potentially one can identify a "control group" to be used in an objective comparison of the post-project organisation against original conditions. Evidence-based management of this kind is often difficult to perform in the real world, so the opportunity may be valuable to your project. But take care - weak partitioning will do nothing to ameliorate the risks of multi-dimensional change.

What about other multi-dimensional projects? A CAPACITY/CONSERVATION or COST/CONSERVATION mix are both at risk from the same failure mode - a tendency to overspend on CONSERVATION measures which are by definition a step removed from the core economy of an organisation.

CONSERVATION projects are intrinsically the most difficult to deliver well, since the natural human response to uncertainty is excessive expenditure on the amelioration of unquantifiable but high-visibility risk, even where such expenditure is difficult to justify on purely economic grounds. The key problem is that the benefits associated with CONSERVATION projects are bounded above and yet there is no intrinsic upper boundary on the potential expenditure that can be used to achieve them.

The unpleasant possibility of unbounded expenditure does not sit well with productivity or efficiency oriented goals, and there is much less opportunity for goal partitioning. Therefore CONSERVATION goals are best scheduled to avoid coinciding with other dimensions of change.

Overall, the message that needs to be internalised by both project owners and projects teams is that, when faced with a complex scope of work, look beyond technical or organisational criteria for structuring the project. The use of stages, as recommended by industry standards such as PMI or PRINCE2, is valid but look beyond the obvious to the fundamental dimensions of change. Consider whether you are trying to simultaneously push and pull an organisation, and look for ways to separate these goals. Don't waste your energy and the goodwill of your customers on Push-Me Pull-You Projects.

James M. Barlow is an IT Consultant based in the UK, with a successful career spanning two decades in the Private and Public sectors. Owner of Xrisk Consulting Ltd he publishes a regular newsletter on Project Management, available from the Pragmatic Projects website.

Every year, between forty and seventy percent of all corporations and public sector bodies attempt to make strategic change. Overwhelmingly, formal projects are the preferred structure used to organise such effort, regardless of whether the underlying goals are defined in terms of Business Process Reengineering (BPR), Technology Upgrades, Mergers & Acquisitions, Due Diligence or similar concepts.

Each organisation starts with a desire to make itself better. But "better" is a slippery concept. Certainly projects bring about change, but do they necessarily make things better? Better in the board room might mean lower costs through reduced head count, but would the rest of the team agree? Perspective matters.

In the absence of personal control of events, everybody hates change. A failure to remember this fundamental insight is the root cause of a great many failed projects. Sophisticated communication strategies and planning models may impress project owners, but these tools will not persuade a hostile group of users or stakeholders that a new project will improve their lot in life; certainly not when their instincts and reflexes are telling them to resist.

This resistance may manifest as scepticism of the projects aims or an unwillingness to contribute, but the diametric opposite is also common - those affected may leap in with enthusiasm to suggest, amend and discuss all aspects of the proposed change. While this may seem productive, and there may be no conscious efforts at sabotage, the underlying desire is to minimise the threat of the unknown; to control it, and thus to make it familiar.

Multiply this process by the number of people affected by a project and the net result is a myriad of different requests, memos, change notes, delays, clarifications, amendments to minutes, design reviews, audits, strategy seminars, away days, planning meetings and other artefacts of partial control. A further difficulty arises since stakeholders are not necessarily customers. The difference is simple: if money changes hands, it's a supplier-customer relationship; everyone else is a stakeholder. Stakeholders may be in a position to influence requirements and outcomes, but they don't have a direct financial interest in the project. And there's no money as easily wasted as other people's money.

Paradoxically then, although many project managers are criticised for failing to engage with their customers, there is just as much trouble to be found by too much engagement. A tricky situation…

What strategies are available to counter these problems, then? Very few project managers have the authority to forego persuasion of those affected by projects, nor to adopt an autocratic style of leadership and compel compliance.

As PMs, we need a way to provide those on the receiving end of a project with a degree of control, without sacrificing the momentum of the project. And this is not as difficult as it might sound, as long as the project is properly structured and - of course - as long as you stay pragmatic. There are two simple, core methods.

The first method is to consider how to minimise the psychological impact of change. The single most effective technique for achieving this is to introduce a number of small, symbolic, changes early in the project and use these as a mechanism to create a perception of ownership, and thus the perception of personal control.

I say "Perception of personal control", but a more cynical observer might call it the "Illusion of personal control". They are not synonymous, though, since the underlying purpose of guiding perception is not to manipulate, but rather to encourage project stakeholders to focus on the benefits they will gain from a project; not the short term problems they will face on the path to improvement. This technique gels well with other pragmatic project management techniques- early prototyping, user evaluation and feedback. The only caveat is that such user involvement is structured and leads to a positive outcome, which I'll be discussing in a future article.

The alternative is to present the stakeholders of a project with so much change that they are faced with an unpalatable challenge to their existing ways of working. This could be considered as offering total liberty to those most affected by the project. But in fact, it can be demonstrated that the outcome is to overwhelm them with choice. Remember: in the absence of personal control, everybody hates change.

The second method is to manage expectations, by controlling the release of change. Release Management is a familiar discipline to anyone working in software engineering, and the related field of Configuration Management is an integral part of the physical engineering disciplines. The same methods - even the same processes - can be applied to change - specifically to the presentation and handover of project deliverables.

A crucial point in expectations management is to limit the magnitude of your promises. By their nature projects involve risk and uncertainty. After all, if you were doing something routine and predictable, why go to all the effort of creating a project? So accept that things will go wrong, and that consequently until you have objective evidence that your supply chain and team can perform, you are not helping the stakeholders by offering a fantasy instead of cold, unpleasant reality.

Try these techniques the next time you want to you want to make a change to your organisation. But always ask yourself: "Is this a change for the better, or change for change's sake?"

James M. Barlow is an IT Consultant based in the UK, with a successful career spanning two decades in the Private and Public sectors. Owner of Xrisk Consulting Ltd he publishes a regular newsletter on Project Management, available from the Pragmatic Projects website.

The human mind loves a dichotomy - a simple division into halves or pairs. We respond easily to questions with yes or no answers; our courts deliver guilty or not guilty verdicts; we start sporting matches with a heads or tails coin toss; and in most countries politics is a choice of red or blue.

In Project Management, we strive to find the best approach, the right plan and the right budget. But circumstances do not offer a simple dichotomy - a Right way or a Wrong way. Logically there is one optimal approach, and beyond that are a plethora of less optimal alternatives. Being pessimistic, for each Right answer there are a Million Wrong Answers.

If you're the manager responsible for a significant change programme, then here is an unpleasant fact: you're probably managing it the Wrong way. The probability that you picked the one Right answer rather than one of the Million Wrong Answers is almost zero. But - it doesn't matter! So relax, and listen to a more optimistic appraisal.

As Project Managers we are surrounded by policy, procedures and received wisdom. Much of this will be packaged up as "best practice". In Europe the dominant certification is PRINCE2 (PRojects IN Controlled Environments), whereas the Americas and parts of East Asia favour the Project Management Institute's Project Management Professional (PMP) mark.

These certifications are a starting point for managing projects. They provide us with a common vocabulary for discussing abstract concepts, and a model for structuring teams and communicating between different stakeholders.

But they are not strait-jackets to be adopted without thought or reason. Great managers recognise that their success lies in finding the strengths of each unique team, responding to events and adapting to local circumstances. In fact, the greatest success comes in accepting that your plan will be Wrong - or if you prefer non-optimal - and recognising that you will need to be flexible and change your approach as you proceed.

Before you let yourself be forced down the path of best practice, ask yourself "Says who?" Why is this best practice? Has this approach worked before in this industry, in this country, or even in this organisation?

The unpleasant consequences of an obsessive search for the Right answer (the optimal solution) become extremely important when we are creating plans. The search blinds us to the truth that by remaining flexible, and being pragmatic about the team, the tools and the tasks with which we are equipped, we can find an approach that is Wrong but… not that Wrong. And as we review our progress we can adapt and find a new approach that is still Wrong, but is nevertheless closer to being Right.

It is often overlooked that the planning process draws from the same budget as the rest of the project, and sits on the critical path leading to final delivery. Spending too long at this early stage seeking the optimal solution is a path to frustration and doubt, particularly as the data available for analysis is likely to be forecasts and conjecture.

In fact the obsession with being Right from day one of a project is as damaging as doing no planning at all. Consider that projects do not exist in isolation. Much as we would like to think that a project team can take the end user's requirements, lock themselves away and produce the results, experience has shown that what users ask for is not necessarily what they want, let alone what they need. And for larger endeavours, it is almost guaranteed that users will change their requirements before they receive the final deliverables.

In projects with a heavy Information Technology component, one also faces the March of Obsolescence - the moment a piece of hardware is purchased it is out of date. The moment a new software version is released a support and maintenance burden is created. These liabilities are only made more onerous if the capability they deliver to the user is lacking. It is a horrible experience for a project team to realise that they have put their heart and soul into an effort to deliver what the customer used to want.

Remind yourself of the martial philosophy that the plan is the first casualty of battle, and think about the approach of a typical Army General staff: strategy is broken down into tactical objectives and handed out to local commanders for implementation as they see fit, intelligence is sought on the effectiveness of each action, exploiting success where it is found. And the prudent General always keeps a reserve force for unexpected contingencies.

Success in project management, then, is built on flexibility and pragmatism. Plans are invariably Wrong, but proceeding with a less-optimal plan is a better approach than an exhaustive search for the Right answer. Adapt to circumstances and exploit your successes and you are on the path to a successful project.

James M. Barlow is an IT Consultant based in the UK, with a successful career spanning two decades in the Private and Public sectors. Owner of Xrisk Consulting Ltd., he publishes a regular newsletter on Project Management, available from the Pragmatic Projects website.