Strategies for Managing Change: The Project Manager

By Tom O'Dea

The title of project manager (PM) is used to mean different things in different companies. Fortunately there is a standards body called the Project Management Institute which provides excellent guidance around the role and function of a project manager.

Some will disagree, but I don't care if your project manager is PMI certified or not. You need to care about having a project manager with the skill to carry out the role as the Institute defines it. It's your change management strategy, and it's your reputation on the line.

Finding a Project Manager

Do you need a certified Project Management Professional (PMP)? As I said above, I don't care. There are newly certified PMP's who have taken their tests and gotten the certification, but they may not be battle tested. There are veteran project managers who never got the fancy title, but they know how to manage projects. And there is everything in between. The track record is what you need to care about.

Do you have a strong PM on your team now? Is that person well respected, perhaps a key opinion leader in your organisation? Do they treat project management as a profession? Then by all means use them.

If, on the other hand, project manager has been a title used by junior, untrained people who walk around with a task list and a clipboard, it's time to bring on stronger talent.

Your fastest route to a proven project manager will be a contract hire, either from a reputable firm or an independent. There are many good ones out there. Get and check references, and interview at least three. Let your key opinion leaders and managers interview them as well. Look for their track record and for good chemistry.

Set the Project Manager Up for Success

Simply put, everyone needs to understand that the project manager is your alter ego. Everyone includes you.

Your managers and project leaders must understand that they are accountable to the PM for providing all of their tasks, their dependencies on other tasks and other work units, their schedule commitments, and their resource requirements.

They need to understand that the PM will review all of their information and look for problems. These could include missed tasks, schedule inconsistencies, resource overloads, etc. Often managers will tell the PM that they can handle some of these problems, by working people longer hours or by overlapping some tasks "by a day or two." A good project manager is going to challenge such claims, and you'll need to stand behind the PM.

The PM is going to hold everyone accountable for milestone deliverables. In most projects, especially those that are complex, milestones are missed and contingency plans must be activated. Again, you as the leader need to support the PM as they hold people accountable.

Handling Conflicts

It's entirely possible that the PM will have conflicts with managers, team leads or others in the organisation. Make it safe for people to discuss and bring up such conflicts. Just because the PM is your alter ego doesn't make them right, any more than you are always right.

Engage your key opinion leaders along with the project manager and others. Find out the facts contributing to the conflict, and make the decisions necessary to get the change management strategy back on track.

Change management strategies that fail often do so because of poor project management. Don't let that happen to you.

Understanding Change in a Quality Culture

By John W. Wright III

In any improvement process, managing the influence of change and the anti-change culture that will continually try to raise its head will be one of the most ardent tasks. Learn to deal with this as effectively as you do the project management itself. There are many well-written books on the subject of change in every category of change that you could imagine. Below is a compiled list of items about change that are relevant to implementing process change.

When examining change it is necessary to understand the stages of change that have been identified. It is interesting to note that these stages take place in varying degrees in different people, but are exactly the same whether the change is a different process in the workplace or the death of someone close. You should be able to identify and deal with the levels of acceptance encountered. Here are the stages and some tips on how to deal with them.

Denial

A wonderful self-preservation response. It is characterised by minimising the situation, and saying (or thinking) things like "This isn't happening", "It won't help", and "There's no problem." You may find the person will avoid talking about the situation, or even make up excuses for not attending meetings.

• Explain the denial to commitment process that you went through to get where you are.
• Present the situation openly and allow a lot of time for questions and answers.
• Have a training session on change management.
• Present a caring and understanding front. Though this may not be your normal attitude, during this process it will be invaluable.
• Be a broken record with memos, thank you emails, posters, or anything else that presents your platform in a positive light.

Resistance

It is at this stage that you may see the active signs of sabotage. They may be passive, as in "I'll just do it my way anyway", along with a lot of whining-crabbing about the new systems. Or they may manifest in physical methods of sabotage depending on the character of the person. Be aware that these are real threats to the success of any project. But for the most part, those who fall into this category will show a lack of interest and a lot of time spent on finding reasons it won't work.

• Listen! And I mean listen. You can hear more in the tone and inflection of what is being said as well as the body language than you can imagine.
• Solicit Response. People love to know that they are being heard and even more that their suggestions are valid. Many of them are. These are the people who will make or break the installation, let them know they have input to the outcome.
• Acknowledge Feelings. Let them know you went through a similar process in getting where you are. Validate that they are not alone.

Exploration

People will begin to see some of the good that may occur in the situation, and will generally vacillate between thinking that it might be ok and that it is still a bad idea. But, the up side is that you are beginning to get them on your side and they will begin to make effort to get the changes in place.

• Facilitate. People are more open at this point. Take advantage of it. Be your own commercial! Challenge people to find a better way within the new system. It gets them thinking about the next round of change and off the current.
• Reward forward thinking with mounds of compliments. Praise the desired behaviour.
• Seek out new possibilities. Have brainstorming sessions. It does wonders for everyone's moral.

Commitment

You've got buy-in and will see productivity through the changes. People can see the bigger picture and the opportunity that the change affords.

When dealing with this from a management point of view, it is important to remember several things. These feelings are very real and they happen at different times for different areas of the organisation. Do not expect to spend several months agonising over the commitment to purchase expensive software only to turn around and expect everyone else to do a Tarzan swing from denial to commitment in a week. Remember the process you had to get through in order to accept the change. Others will require the same; allow the process to manifest itself in others. You can facilitate the process by understanding it and helping others to get through.

• Recognise and acknowledge those who get there. Give them more opportunity to improve the process and celebrate their victories.
• Inspire people to get others on board. Teach them about the process and how to recognise the people in various stages and how to move them along.
• CELEBRATE!!!!! Most important. When you have achieved goals, let everyone know and celebrate, celebrate, celebrate. When people know their efforts will be recognised and appreciated, you will have fewer problems in future change.

Remember that we have a tremendous amount of information to process every day. There is more information in a single daily paper today than a person in the 15th century processed in a lifetime. Change takes form in one of three types; that which we cannot control, that which we can, and that which we can influence. Being positive and trying to move things from cannot control to can influence helps in the ability to manage the changes that occur. But, there will always be those things you cannot control and acceptance of that fact is the only road to remaining sane.

Managing Change Successfully: Six Layers of Resistance

By Samuel Okoro

Why is there resistance to change? Are people just naturally perverse, or are there concerns which if understood and correctly dealt with will create the buy-in required to turn resisters into supporters and generate the momentum needed to overcome the gravitational pull of the status quo?

There are six layers at which resistance can occur.

We Do Not Agree on the Problem

Go into any poorly performing organisation and ask people from various functions what the issues are. In all likelihood, within each function you will find different opinions as to what the problem is. The situation is not unlike the six blind men in the rhyme, who went to see the elephant. Each honestly describes his experience, but none of them captures the essence of the whole.

This is why different initiatives are launched in each department to try and solve the different problems. But if we remember that organisation are systems and departments/functions are interacting parts of a whole, we then realise a more holistic approach is needed. Through a combination of rigorous logic and experience based intuition, we build tight cause effect relationships that lead us to the core problem.

Usually disagreements as to the problem disappear once this approach is used.

We Do Not Agree on the Direction of the Solution

If a problem is long standing, its persistence indicates that there are conflicts preventing its successful resolution. An example of such a conflict is where management proclaims quality as number one and generally supports actions that guarantee quality until sales volumes are threatened. Then the quality mantra is quickly abandoned - especially if we are talking about the last quarter of the year. When the pressure eases early in the new year, quality becomes important again.

Another case is the conflict between delegation - to improve speed of operations and customer service on one hand, and control - to contain costs on the other hand.

By questioning the assumptions behind each of the conflicting positions, erroneous paradigms can be unearthed and thus the basis of the conflict eliminated. Thus a particular direction for solving agreed problems can be pursued. A powerful tool for resolving conflicts is the Evaporating Cloud which is part of the TOC logical tool set.

We Do Not Agree that the Proposed Solution Resolves the Problem

Even with the problem and the general direction of the solution agreed, it may be difficult to convince stakeholders that a particular solution completely solves the problem. In this case just as logical cause effect relationships can be used to construct a diagram to represent the problem so also can they be used to construct a diagram logically relating the proposed solution to the new desired states.

Thus such a logical description can be used to convince stakeholders that all the original problems are eliminated when the solution is implemented.

Yes But... the Proposed Solution Will Create Other Problems

It is not unusual that the designer of the solution is blind to the shortcomings. So even though stakeholders now agree that the solution solves the stated problem, they may claim that it creates other problems in their place, like the case where eliminating a pest causes a proliferation of other undesirable creatures that it preyed upon.

The solution here is to acknowledge the concern and then work with those affected to eliminate it by the same logical process already described. Involvement of affected stakeholders creates even stronger buy-in. At this point every one is ready and willing to go ahead, but...

Yes But... there are Huge Obstacles to Implementing the Proposed Solution

The solutions proposed may require skills, resources, technologies, approvals that are currently unavailable. The obstacles are attacked in a step by step manner. The outcome of the process is a sequence of prerequisites needed to overcome the obstacle and thus implement the solution. At this point there is complete buy-in along with a plan for executing the required changes.

Unverbalised Fear

At the end of the day, any residual resistance is most likely due to unverbalised fear - a vague feeling of unease arising from the fact that we will be doing something entirely new. Leadership is what is needed here to provide the inspiration and confidence to go forth and just do it!

Making Change Happen

By Kevin Dwyer

Seventy percent of all change management projects are considered to be failures.

The critical factors for change management success or failure are fairly simple.

The first factor is to have a group of people at leadership level believe that change is required. More than that, they must believe that "change management" is required. If these factors are not evident then failure is assured.

Understanding that major change is required is not enough. Developing a project plan which includes changes to processes, policies and infrastructure that does not include a plan to manage the change at a people level is not enough.

The second requirement is that the people undergoing change must have a reason to believe the change is necessary. They need the big picture painted for them to understand what benefits the organisation will gain from what many people will consider as the shared pain of change.

The big picture must be compelling, giving as many people in the organisation the desire to embrace the change even if it is difficult. Organisational change for organisational change's sake is likely to fail to deliver change.

The third requirement is that individuals must know how the change will affect them as individuals. Never forget the greatest motivational tool is to be able to respond to the question, "What's in it for me?"

For most individuals in most organisations, motivation is about achievement, recognition, the work itself, responsibility, advancement and personal growth. So be sure that the change message addresses as best it can the motivational opportunities for people.

The fourth requirement is to "tell them early, tell them often." Do not be surprised how many times the message needs to be repeated to the same people. Human beings filter information based on their emotional state, their previous experiences and their thinking styles. In a time of significant change people are often in emotional turmoil and will filter severely whatever they are told.

Tell people the compelling reason for the change, the plan for change, the progress of the plan for change including any early wins and their role in change, again and again as the project is implemented.

The fifth requirement is to be honest about the change. Sugar coating change is seen as being untrustworthy and will adversely impact the ability to communicate with the very people who have to embrace and implement the change.

If there is any bad news say so. If jobs are going to be lost, say so. If there are going to be challenges with the change, say so. If people have to re-skill, say so. If the targets are going to become much tougher, say so. Do not dress mutton as lamb. If an insignificant advantage will accrue to people, do not make it seem more significant than it is.

If you are honest about change and you don't know about some of the implications, you may have a significant number of people actually believe you. When you ask for help in making the change work, you may get a positive response. Be dishonest and even your best workers will smell a rat and treat you like one.

The sixth requirement is to utilise project management processes and skills. For those involved in change management who do not use project management processes and skills the simple advice is, "If I were you, I would not have started there."

Project management processes and outputs play a big part in both planning and communicating the changes anticipated. They assist in risk management, contingency planning, change control, resource management, prioritisation and post implementation review of the change.

Far too many organisations embark on change in manner best described in the vernacular language, as flying by the seat of their pants. They do not plan change. They do not estimate the resources required by change. They do not plan the precursors to events required to make the change happen. They do not understand the risks and plan the contingencies. They usually reap the rewards with a failed change project.

Managing change is not easy. However, it is not as difficult as a seventy percent failure rate would make it seem. It needs to be taken as seriously as managing the finances of an organisation or the safety of an organisation.

Managing change requires a leadership team with project management, communication and analytical skills with a high degree of results orientation. The latter is important as when a journey of change is embarked upon, the environment in which the change is being implemented immediately changes. A changing environment often calls for changed tactics to achieve the same result.

More than that it requires the leadership team to have a vision for what the change can bring to the organisation and to individuals and a passion to make that change happen.

Push-Me Pull-You Projects

By James Barlow

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.

What is Change Management?

By Duncan Haughey, PMP

The change management process is key to the successful outcome of a project. The process ensures that each change introduced is properly defined, considered and approved before implementation. Change management contains four stages:

• Proposing a change
• Summary of impact
• Decision
• Implementing a change

Proposing a Change

This process give the ability to anyone within the team (including the customer) to propose a change to a project. The proposal must include a description of the change and expected benefits or other reason for the change and is presented using a Change Request Form.

Summary of Impact

This process is carried out by the project manager who will log the change and consider the overall impact on the project. The following will be considered:

• Quantifiable cost savings and/or benefits
• Estimated cost
• Impact on timescales
• Additional resources required
• Impact on other projects and activities
• Additional risk and issues

Following this assessment, the project manager will make a recommendation whether to implement the change.

Decision

This process involves a review of the change request by an approved authority who will consider all of the information provided by the person making the request and the project manager. The decision will usually be to accept, accept with comments and/or special conditions or reject.

Change Management in Practice: Why Does Change Fail?

By Jonathan Palmer

Resistance to change may be active or passive, overt or covert, individual or organised, aggressive or timid and on occasions totally justified.

Sadly most significant change fails to meet the expectations and targets of the proposers. The failure is given the catchall name resistance, yet resistance can be principled and creative as well as from vested interest. Top management is frequently unreasonable in its expectations and time scale, forgetting the process it went through when it decided to make the change.

An effective change manager will prepare an organisation for change in the early stages of project definition and stakeholder review, by taking managers through a similar sales process and responding to their apparent resistance: the creative conflict.

This process is likely to improve the project definition and buy in. It will also ensure that it is clear the moment resistance becomes vested interest.

It is unrealistic to expect an independent change manager to tackle vested interest resistance but the change director can use his or her intervention as a signal to the organisation - such interventions should be few but telling.

An independent change manager is a cross between a foil and a lightning conductor - the foil ensuring that positive energy is deflected to the right place, the lightening conductor removing negative energy from the organisation.

Avoiding failure: managing resistance

Resistance is a key element in why change fails. A recent informal UK survey of 120 government transformation programmes identified that:

• 15% achieved their objectives
• A further 20% failed to achieve their objectives but were nevertheless regarded as satisfactory
• 65% were unsatisfactory.

A subsequent discussion forum on ecademy.com identified 7 key reasons why change fails. (The list is virtually identical to one made by Kotter at Harvard 15 years ago).

1. The organisation had not been clear about the reasons for the change and the overall objectives. This plays into the hands of any vested interests.
2. They had failed to move from talking to action quickly enough. This leads to mixed messages and gives resistance a better opportunity to focus.
3. The leaders had not been prepared for the change of management style required to manage a changed business or one where change is the norm. "Change programmes" fail in that they are seen as just that: "programmers". The mentality of "now we're going to do change and then we'll get back to normal" causes the failure. Change as the cliche goes is a constant; so a one off programme, which presumably has a start and a finish, doesn't address the long-term change in management style.
4. They had chosen a change methodology or approach that did not suit the business. Or worse still had piled methodology upon methodology, programme upon programme. One organisation had 6 sigma, balanced scorecard and IIP methodology all at the same time.
5. The organisation had not been prepared and the internal culture had 'pushed back' against the change.
6. The business had 'ram raided' certain functions with little regard to the overall business (i.e. they had changed one part of the process and not considered the impact up or downstream) In short they had panicked and were looking for a quick win or to declare victory too soon.
7. They had set the strategic direction for the change and then the leaders had remained remote from the change (sometimes called 'Distance Transformation') leaving the actual change to less motivated people. Success has many parents; failure is an orphan.

Very few organisations will manage all 7! However any one in isolation will make the change programme inconsistent and aggravate resistance. Advance planning and stakeholder management will avoid some of these pitfalls. Furthermore the list is an invaluable diagnostic tool for identifying why (and where) resistance is taking place, giving an opportunity to defuse resistance by correcting the mistake.

Conclusion

• Resistance can be healthy (a pearl can result)
• Unknown, unanticipated, unquantified, unaddressed resistance will always be dangerous.
• A badly thought out process and implementation will always result in resistance
• An independent change manager can bring the independence, experience, and objectivity to manage resistance.
• A successful change is essential in creating a change culture

Persuasion and Perception

By James Barlow

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 and 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 on those affected by projects, and compel the wider organisation, and yet persuasion is not enough. There are also plenty of problems with a more autocratic style of leadership.

As project managers, 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.

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?"

7 Steps to Project Success

By Peter Draper

The successful completion of a big project should bring big benefits for your company - otherwise, why bother? The prize sought is often increased customer satisfaction, bigger profits, higher share price or some other key performance indicator. Projects often require company staff, experts and suppliers to come together on a temporary basis to carry out a one-off change that will leapfrog the company to greater success. But all too often, the hope of success meets with problems, delays and cost over-runs that cause frustration and stress for everyone concerned. The project that looked so good on the drawing board may somehow fail despite all seemingly reasonable efforts. So, what might be done to improve your project's chances of success?

Here is a seven step procedure that I use to manage successful projects. It guarantees the best chance of achieving maximum project benefits for my clients. This checklist should also be useful to senior company executives, functional chiefs and project managers alike. My procedural checklist keeps profits in mind as follows:

1. Profit from your project
2. Rally support
3. Organise plans, resources, etc
4. Focus on key benefits
5. Invoke risk responses in advance
6. Test your project is working
7. Switch to the new working practices

Step 1: Profit From Your Project

Think about it. Every part of every organisation needs to generate more benefit than it consumes. So, if your project, even on the drawing board, cannot produce profits for the company, then no amount of management effort further down the line is going to be help. I have seen many examples of proposed projects that have benefit to cost ratios that only barely meet the company investment hurdle rates. These benefits are also sometimes "inflated" using some proposed value of intangible items. If this is the case with your project, then maybe it is time to look deeper and consider other alternatives before you start. As the responsible executive, before you kick-off your project, I suggest you make sure that you have some good answers to the following questions:

• What is your company's business strategy?
• How will the outcome of this project add value to that strategy?
• What alternatives are there to doing this project?
• What dollar-value is this project outcome? (Get your finance staff to calculate internal rate of return, etc.)
• Is your project, in fact, mainly designed to avert some impending crisis?
• What contingency needs to be developed in the unlikely event that your project outcome may benefit from some additional support?

By considering the answers to these questions you should have most of the information required to justify the need, and hence, determine the expected benefits for your project. Select your project carefully.

Step 2: Rally Support

In addition to getting the top-level support from your executive management team, it is critical to rally support and get input from other interested parties too. For example, major customers may need to be consulted, as may representatives of the planned user base too.

These parties interested in the outcome of your project will:

• Contribute to your list of the benefits and also dis-benefits of the project
• Possess a wealth of expertise and experience for you to consult and gain valuable advice from
• Be the main candidates for providing funding or support for your project

The purpose of this step is to develop a clear picture of how your project will come together in more detail. The step is highly consultative and requires answers to the following questions:

• Has a similar project to this ever been done before? If so can this be used as a model?
• How could your project outcome be improved for the various interested parties?
• What legitimate concerns do the other interested parties have regarding your project?
• Are all parties in agreement with all the assumptions made?
• Should the order of magnitude costs and expected benefits be modified?
• What dependencies are there relating to other current projects?

Once these questions have been addressed you must check that the executive management team, major customers and other key parties are all on-board. They need to be aligned as much as possible to enable the required degree of collective ownership. Now you should have a great start to your project and a high degree of confidence that you will get those sought after benefits.

Step 3: Organise Plans, Resources, etc.

A key appointment on your project team is the project manager. He will take full and personal responsibility for achieving the successful outcome of your project using the best methods available. He organises everything. His starting point to getting the best resources, to negotiating the best contracts, to managing your project is to communicate effectively with all the relevant parties concerned. The key is to be communicating "facts" such as requirements and plans. He should be aware that communication is a two-way street and much of the time should be spent getting feedback and seeking information from knowledgeable parties.

The project manager is also an integrator. In particular, he integrates the project team and other interested parties, and he also integrates products and services. Any new product or service resulting from a project will need to be merged with the company infrastructure on "live" date. In building the project plan it is essential to break the work down into manageable units. However, in every area from technology to manufacturing to human resources there is currently an opportunity to leverage off standard models and structures. So ensure the project manager uses industry standards where possible, for example using:

• Process models (such as the Project Management Institute's project management methodology)
• Architecture models to enable "pick 'n' mix" type deliverables

It makes sense to consider outsourcing project activities and deliverables unless, say, for security reasons it must be in-house or perhaps it is somehow part of your core business.

Step 4: Focus on Key Benefits

Once the project has been planned, it is important to stay focused on key benefits. The problem is that projects tend to take on lives of their own. You cannot let this happen otherwise all sorts of side tracks may be taken or other features added in. It will probably be necessary to break up the project into smaller, independent sub-projects that are more easily manageable. These sub-projects must be:

• Small, that is, less than $1m
• Fast, that is, takes less than 6 months
• Compact, that is, fewer than 6 people on the team
• Focused on key benefits and not just deliverables

This is also the time to reconsider carefully again the desired project objective. Do these sub-projects really produce tangible added value in dollar amounts? It may be that considering the additional costs, many of these lesser features may be dropped to achieve project efficiency gains. Remember, jettison non-essentials and focus your project to do ONLY the items that MUST be done to achieve the benefits you really need.

Step 5: Invoke Risk Responses in Advance

During the life of your project the world is not standing still. Competitors are introducing changes, customers' demands are changing, technology is moving forward at near breakneck speed, etc. You cannot keep up with all this on your own. You must empower your project team to anticipate problems and you must tell them how you want them to deal with these issues in advance. Some studies show that up to 90% of project problems can be handled effectively by using proactive risk management similar to that described below. Here are the questions to ask:

• What problems have been encountered on similar projects in the past?
• What else can possibly go wrong at each stage of this project?
• What are the early warning signs of these problems occurring?
• What is the dollar impact of each possible problem that has been identified?
• What is the likelihood each problem might occur?
• What response strategy is best to handle each of these possible problems?

Evading the problem altogether is a good strategy for coping with risks, but alternatively, you might want to use one of the following standard risk responses:

• Avoidance - eliminating the cause
• Mitigation - reducing the effect
• Acceptance - simply accepting the impact
• Transference - "outsourcing" the problem

Managing project risks means anticipating them to avoid "fire-fighting" responses; and replacing them with prior delegated actions. This way your project outcome and benefits can be protected to a very large degree.

Step 6: Test Your Project is Working

Controlling your project involves testing and checking progress, then making adjustments to bring your project back on course. This means deciding up front what key measurements need to be taken and how often; and then deciding what values for these items make them unacceptable. Examples of such measures are:

• Work done (pay special attention to "scope creep")
• Cost variances
• Activities behind schedule
• Quality issues

These need to be considered on a "management by exception" basis and the facts need to be reported to interested parties. At the same time adjustments can be made to activities to bring these factors back into line immediately. This way, you can guide your project to a successful outcome. But be careful that watching paperwork alone is not enough. There will be critical times on any project when you must know how to motivate your team to achieve exceptional results.

Step 7: Switch to the New Working Practices

Congratulations! You have reached the final step. You now have to make sure you complete the last step to get those hard earned benefits. This generally requires switching off that out-going system, or re-deploying the department you have just made unnecessary, or simply stopping using that old set of procedures. To get the full project benefits, you need to switch to the new working practices completely. This final act often requires courage and resolve. I have come across many examples, say, of an old system that is never switched off because it is needed for that "special" client, or whole departments that continue in parallel years after a major company merger.

Of course, you should finally celebrate a job well done!

Real World Project Management: Procurement Management

By Joseph Phillips

Projects typically need stuff: servers, software, subject matter experts, pizza, etc. And to buy all this stuff, you need to go through procurement processes. That's just a fancy way of saying you need to follow some rules and procedures within your organisation to get the things you need to complete your project. Well, duh.

In some organisations where I've consulted, the project managers can spend carte blanche up to $10,000 on any purchases they need. In other, less fun organisations, the project managers can't buy a soda pop without an accountant's permission.

So where are you? Do you get to buy, buy, buy, or is every purchase considered, weighed, and meditated on before someone reaches for the wallet? In either shop, there are some guidelines you should consider. Really, there are.

Planning What to Buy

All purchases require some level of planning. The intensity of the planning is relevant to the purchase being made. You do this already, right? If you're about to install a new piece of hardware, you'll consider all the functions that the hardware should have, shop around a bit for prices, and then see how much your project or organisation can spend (or is willing to spend).

Planning for procurement includes more than window shopping. Think way, way back to the start of any project that required procurement. Early in the project planning, it was easy to identify those things or services that you needed to buy for the project to succeed. As the project moved forward, "emergencies" popped up, requiring you to buy more stuff: cables, software, additional hardware, tools, training, spaghetti sauce, whatever. So how did you go about getting all this stuff? Did you go to management, hat in hand, and plead your case for your much-needed spaghetti sauce, or did you dip into a project contingency fund?

How you go about purchasing depends on the structure within your organisation. It's difficult, if not impossible, to define a universal approach to procurement. Everybody, every organisation, has a specific approach to procurement. The moral of the story? Follow the rules. Once you know the rules of how to procure, then you can play the game.

Gettin' to the Gettin'

I know lots of people who like to go shopping. One person (who shall remain nameless, but her initials are Lisa) plans her vacations based on the shopping malls in the vicinity of her hotel. She buys an extra seat for the flight home, just to carry all of her new shoes and fancy outfits.

As a project manager, you can't go project shopping just because shoes are on sale. While sales are good, they don't always help the project to acquire the things it needs to reach project closure.

There's nothing better than finding a sale on the hardware or software that your project needs, but you and I know that's just not the way technology and procurement usually works. We have to shop, compare, evaluate, and eventually cough up the cash to get what our projects need. But here's some Econ 101 for you: Prices are affected by supply and demand, pending changes, and other factors, from government regulations to the economy as a whole.

I can hear you again: Duh.

But hold that "duh" for one moment. Three specific conditions affect how much you pay for the things your project needs:

1. Sole source. In this condition, you'll likely pay big bucks. Sole source means there is only one qualified seller in the market. This is supply and demand at its finest. If your project needs a Cisco CCIE-certified consultant who must also know how to program in COBOL, speak Spanish, and cook spaghetti for up to forty people, and must live local to your firm, those are some high requirements, you'll likely have to pay a higher dollar for this expert than for your average spaghetti-cooking hack.
2. Single source. You're in love. When there's a single source provider, your organisation prefers to work with this provider even though other providers may be less costly or more qualified. The danger is that your single source provider may know your attachment and take advantage of the situation. Or get lax in their commitment to quality. Or go out of business. (Or not.)
3. Oligopoly. This one is just fun to say. Try it: Oh-lig-AH-polly (sounds like monopoly). This market condition means that there are so few providers of the particular good or service that the events, actions, or circumstances of one seller affect the events, actions, or circumstances of the other sellers. Examples: Airline fares; oil prices; hardware costs; or possibly availability of spaghetti-cooking, COBOL-programming CCIEs who live in your neighborhood.

Cash and the Law of Diminishing Returns

One of my favorite economic laws is the Law of Diminishing Returns. It's basic stuff at first glance, but can really haunt a project manager if he's not careful. I know you're familiar with the Law of Diminishing Returns, but that guy from Sheboygan is also reading, so let me help him out.

Imagine that you have a wheat field. Wait, he's from Sheboygan. Imagine that you have a corn field and you know that you can get 100 trucks of corn out of the field. That's the most corn you'll ever get from the field. You also know that if you hire 10 guys to harvest the corn for you, they'll be done in 2 days. So you reason that if you hire 20 guys you'll be done in 1 day. So this must mean that if you hire 40 workers, all the corn will be harvested in half a day, right? Maybe, but if you continue to add workers to the field, a few things will happen:

• Your yield-100 trucks of corn-remains the same no matter how quickly you harvest the corn.
• Your profit will decline because you have to pay all those workers to harvest the corn for you. At some point, you may even be upside down on profitability because of the expense of labour.
• The workers will become counterproductive because they'll start getting into each other's way.

So how does all this corn relate to an IT project?

The obvious answer is that you can't exponentially add labour to get a project done faster. And just because you add labour doesn't mean that the project will get done faster. (Have you ever had two programmers, two systems engineers, or even two Spanish-speaking, spaghetti-cooking, COBOL-programming CCIEs argue over how a task should be completed? The argument could go on for years before the work actually gets started.)

But the Law of Diminishing Returns also applies to the technology that you purchase. Have you ever bought an application that was so rich with features that the cost and time of learning the application was more than the returns from using the application? Or have you ever installed a massive powerhouse print server where many of the features of the OS go ignored? Or maxed out the RAM on a laptop that's only used for PowerPoint presentations and solitaire? When it comes to IT hardware, as with labour, project managers should procure only what's needed-not the maximum that the budget will allow.

Build or Buy?

Ah, one of the great arguments of all time. Should we buy it or should we build it? Well, it's probably not that great of an argument, but I'll bet you've been in some heated discussions on the value of either side of the debate. If not, let's start one now.

Sometimes, like it or not, it's more cost-effective to spend the cash and pay someone else to build the thing for you. Why? Your crew is busy doing other jobs, they don't have the competence to build the thing you need, or your organisation doesn't want to take the risk of creating the thing in-house. Lots of reasons.

Other times, like when your project team is lounging by the company pool sipping pinot noir and snacking on spaghetti, it's ideal to put them back to work building something. Again, there are lots of reasons why it may be better to build versus buy, or the other way around.

But sometimes it's purely a price decision. Here's the deal: Let's say that if your organisation builds a piece of software, it'll cost $45,000 to create and then $4,500 each month to support. Now, a vendor says they'll only charge you $23,000 to build the initial product, but they'll need $6,500 each month to support it as part of the deal.

Hmmm... so what's a project manager to do?

Maths.

Here's how it works: Take your build option of $45,000 and subtract the vendor's quote of $23,000. The difference is $22,000. Now take the monthly support fees of the vendor, $6,500, and subtract your lesser in-house fees of $4,500. The difference is $2,000.

Now, drum roll please, divide the initial out-of-pocket expense difference of $22,000 by the monthly support fees difference of $2,000 and you'll get 11. Eleven what?

Well, 11 in Blackjack means double down. Here it means that you can pay for the out-of-pocket expenses of creating the software in-house in 11 months. So, Copernicus, if your software creation will exist for less than 11 months, hire the vendor to do the work for you. If your solution will be around longer than 11 months, and price is the only factor, build the software yourself.

Taking Out a Contract

Contracts override everything: promises, email, secret handshakes. As long as they don't include illegal activities, contracts are backed by the U.S. legal system. A contract is what makes the deal a deal.

To get to the contracting activities, you need to create the procurement documents. The initial document is usually the statement of work (SOW), which describes the thing or service you want to buy. The SOW is provided to the vendor with an invitation to bid (IFB), which you probably also know as a request for quote (RFQ). The IFB and the RFQ are basically the same thing and are focused just on price, not ideas.

A request for proposal wants a price, but also suggestions and ideas on how the project work should be done. Proposals are more than just costs, they're a bit of consulting from the vendor.

In big-dollar contracts, you'll likely host a bidders' conference in which all vendors that want to create a proposal or bid will meet with you at once and ask questions concerning the SOW. This setup ensures that all the vendors have the same information on which to base prices and proposals.

Once you make a decision on which vendor to use, you go through negotiations, which lead to a contract. The contract-type selection might also be negotiated, but usually the type of work or goods being procured dictate the appropriate contract type. The following table lists the most common contract types and their attributes.

Contract Type	Description	Risk
Fixed fee	Fixed fee for the goods or services provided. Nice and easy.	The vendor has the risk of cost overruns.
Time and materials	You pay for the time and materials to complete the work.	Low risk as long as the contract includes a "not to exceed" (NTE) clause as a price cap.
Unit price	Fee per item or hour purchased. Sometimes these plans include incentives such as "Buy more items and the cost per item drops."	Low risk.
Cost plus (anything)	Cost of the goods and services plus a fee or percentage of the cost. Who uses these anymore? Not too many folks.	High risk for the buyer, as waste means you get to buy more and pay more.
Incentive fee contracts	These contracts award a bonus if the project is done early and can include penalties if the work is late or lacking in quality.	Usually low risk.

Bring Your Wallet

Procurement is, uh, big business. There are lots of details in procurement planning, the creation of procurement documents, bidder conferences, and in the contracting of the work. All organisations have their approach to procurement and contracting. You, the project manager, need to understand your organisation's approach and then follow the rules to get the stuff you need.

Now, if you'll excuse me, my Spanish-speaking, CCIE-certified, COBOL programmer has spaghetti ready. And I need to pay his invoice.

Having a Robust

Having a Robust Governance Process

By Ron Rosenhead

So, you are organised, have identified the stakeholders as well as project risks (and you are actively managing both), you have planned the project and you are all ready to deliver.

But, have you developed a monitoring and control process for your project - an essential part of project management and work generally? One person who attended one of our project management training courses suggested that:

"A project goes over its deadline a day at a time, a day at a time, a day at a time. We have no excuse for not knowing. We should actively monitor and control our projects from business case through to closure."

This person had had some really bad experiences and wanted others who were on the course to avoid what he went through!

So, what can you put in place to ensure that you monitor and control your projects?

1. Loose v Tight Control

You need to decide, in conjunction with your sponsor (senior manager) the type of control that is appropriate for your project. Tight control is appropriate for high risk projects. You may want to mix the type of monitoring and control throughout the project. One you have decided on the appropriate type of control, ensure you develop a system that actually fits it. We have seen control processes that are supposed to be tight, but when examined are really loose.

2. Project Spend

You MUST have accurate project spend figures - whether it is a small low budget project or high capital expenditure. Ensure you create your own processes for capturing the figures if your internal system does not help! (See point 4 Planned v Actual below)

3. Tolerance

This is an interesting way of controlling projects. It works like this; in conjunction with the senior manager a figure is agreed - say 22.5% or 5% or 7.5%. You only report if you are over or under each activity.

Example 1: It is planned that activity twenty takes 15 days. A tolerance figure of 10% is agreed. The activity takes only 19 days to complete. You report this to the sponsor as you are over the tolerance figure of 10%.

Example 2: Activity 12 is planned for delivery at a cost of £4,000. The actual cost is £4,700. You report that activity 12 is over tolerance. You only report against those activities that are over or under tolerance.

4. Planned v Actual

Develop a simple chart which maps out the planned activity durations and costs. Plot against each the actual figures.

5. Reporting

Agree with senior managers how often and how you will report. NOTE: we advocate a one page report with agreed headings. In some projects you need to fulfil external reporting requirements. We suggest you familiarise yourself with these early in the life of the project.

6. Milestone Reports

Report against milestones. Develop a simple milestone reporting chart. Ensure when someone reports they are off schedule against a milestone they have a recovery plan to bring it back on target!

7. Project Changes

Develop an agreed process to deal with project changes. Few projects go through their life cycle without change. But, you must control the changes rather than allowing them to control you! How? Use a simple change control sheet. Record the type of change and the impact. Formally agree changes with the project sponsor if the change impacts on the project budget or the project objectives.

8. Meetings

Have agreed agendas and agreed durations for each project meeting. Ensure you produce ACTION POINTS which are circulated very soon after the meeting.

When should you put start putting in place the project monitoring and control process? We suggest as early as possible. It should be discussed at the time the business case is agreed. Without a process in place early then you will not have a robust process and the project could well stray!

Project management needs robust monitoring and control processes. As one delegate on a training programme put it, "anything to prevent project creep!"

Benefits of Merging

Get Maximum Benefits of Merging Top-down and Bottom-up Project Management

Get the PDF Version

By Andrew Filev

Nowadays, the bottom-up approach to management is becoming more and more popular. More and more, organisations are abandoning the top-down management style. Among them are the New York Times, Tribune Co., Ernst & Young and many others. Even the world biggest corporations, such as Toyota and IBM, are trying to implement bottom-up management style elements in some of their departments. However, managers are still arguing over which approach is more beneficial for organisations. To understand the reason for the ongoing changes in management processes, we need to compare the two management styles.

New York Times Case: Problems Caused by the Top-down Approach

The essence of the top-down approach is that all the directions come from the top. The top management establishes project objectives and provides guidelines, information, plans and funding processes. The manager clearly communicates his expectations to each project team member. To advocates of this approach, ambiguity opens the door for potential failure, so managers should be as specific as possible when communicating their expectations.

One of organisations applying a top-down management style was the New York Times, a leader in the newspaper industry. According to American Journalism Review, several years ago, the Times' executive management felt that what they were doing was not able to create a vibrant workplace and a successful enterprise. The power was centralised. Masthead editors had overall control. The editors naturally introduced the same management pattern in the projects for which they were responsible. Project managers' emotions and opinions influenced all the project decisions. As a result, people felt that their voices didn't count, that they weren't listened to. Journalists were not morally motivated to do their jobs. There was no effective collaboration between them. The managing executives then realised that more freedom should be given to the teams. It took a lot of time to introduce bottom-up style elements to management. However, it was worth the time and effort, as the collaboration is now enhanced, and teams work more productively.

Similar problems can be observed in many organisations with a traditional management style. Practice shows that the top-down approach can reduce productivity and cause bottlenecks or so-called lockdowns. Lockdown gives a project manager as much control over his team as possible. This inflexibility can cause unnecessary pain and slow down the project work.

Is the Bottom-up Approach Better?

The factors mentioned above can lead the best projects to failure. That is the reason why many organisations, such as the New York Times, try to implement a bottom-up management style or at least some of its elements. Bottom-up management proactively seeks the input of the team in the project executing process. Employees are invited to participate in every step of the process. The team as a whole agrees on the course of action. This approach allows managers to communicate goals and value, e.g. through milestone planning. Then team members develop personal to-do lists, which include the steps necessary to reach the milestones on their own. It is up to them to choose the methods and ways to perform their tasks. The advantage of this approach is that it empowers team members to think more creatively. They know that their initiatives are appreciated. The team members' motivation to work and make the project a success is increased. The planning process flows significantly faster, as it is facilitated by a number of people. The to-do lists of all the team members are collected into the detailed project master plan. Schedules, budgets and results are transparent. The project manager makes all the issues clear to avoid as many surprises as possible.

However, despite all of the enumerated advantages, the bottom-up approach is not the perfect solution. Sometimes it lacks clarity and control. A lot of experts agree that a bottom-up style alone will not make your projects flourish. The wisest thing for a project manager to do would be to take the best practices from the two approaches and try to create a hybrid method.

Leveraging Advantages of the Two Styles

Is it possible to successfully introduce the best bottom-up practices to an organisation by utilising traditional tools? Traditional project management software was originally designed with the top-down approach in mind. Traditional applications are not meant for bottom-up management. They are complex and hard to master. These applications are focused on the project manager and make him the major link in project communications. Team members very often do not have access to the project plan and cannot make contributions. The employees e-mail their updates to the project manager in disconnected files. The project manager then has to collect all the data and put the information manually into the project plan. Then he has to communicate the changes to the corporate executives. The misalignment between the bottom-up best principles and the old tools may cause situations when the project manager's talents are buried by the routine operations. Sometimes project managers just do not have time for leadership.

The old methods of how people share and receive information have been radically transformed in recent years. Now there are more means for the successful implementation of the bottom-up management best practices. These are Enterprise 2.0 technologies, such as wikis, blogs and collaboration tools. The new technologies come into organisations and change the old way of managing projects. They turn traditional project management into Project Management 2.0 and bring new patterns of collaboration, which are based on collective intelligence. Collective intelligence is a collection of valuable knowledge from different fields that each project team member is an expert in. This knowledge is now successfully collected and shared in a flexible, collaborative environment brought by second-generation project management software. The project manager is the one to conduct the work and choose the right direction for the project development, based on the information received from individual employees.

The role the project manager plays in the project changes. Project Management 2.0 software helps him create complete delegation. People become less dependent on the manager as a to-do generator. The project manager turns from a taskmaster into a project leader who facilitates the team communications, provides a creative working environment and guides the team. He becomes a visionary who can leverage the team strengths and weaknesses and adjust project development to the external changes.

The second-generation tools allow project managers to merge the advantages of the two initial management approaches. These applications let you combine control and collaboration, clarity of project goals and visibility of internal organisational processes.

Thousands of companies now report that bottom-up project management, implemented with the help of Enterprise 2.0 tools, improved their business performance. Among them are Bell Canada, Sun and Yahoo. These corporations created their corporate blogs to streamline project communications. Even giants, such as IBM, realise the benefits of allowing contributors to have a more active hand in how collaborative work is organised.

Democratising project management is never an end in itself. The primary goal is always to find ways to make project management and project collaboration more efficient. New technologies applied to projects offer us the powerful ability to make projects more successful and teams more productive. With the help of new-generation tools, projects can be delivered much faster, and this is to everyone's benefit.

MakeEffective

Let's Make Those Project Meetings More Effective

By Ron Rosenhead

I was trying to get hold of the project manager. Or rather he was trying to get hold of me. However, I had tried 3 times already so I sent him an email knowing it would sink to the bottom of the pile.

I got to thinking that it wasn't just this project manager who always seemed to be in meetings. Several people I have been trying to get hold of always seem to be in back to back meetings.

Project Agency has been collecting statistics for several years. Some 1,120 people have completed our questionnaire and one of the questions is quite revealing:

"Project meetings are collaborative events which look at achievements not past failures." The percentages are shown below:

• Strongly Agree: 1.3% (15 people)
• Agree: 25.6% (289 people)
• Disagree: 57.3% (648 people)
• Strongly Disagree: 12.6% (143 people)
• Don't Know: 3.2% (36 people)

Not very good stats are they? Interesting that 36 people do not know how effective their meetings are!

So, what can be done? Well, here are some golden rules for project management meetings (and meetings in general):

Rule 1: Ensure you have the right people there. May seem obvious but how many meetings go ahead with the wrong people there and the right people "on the way" or a key stakeholder not even invited?

Rule 2: Have an agenda for each meeting and against each item put a time (the length of time the item will take). Ensure you stick to the stated time.

Rule 3: Have a clear objective. Is it to receive a highlight report, or to prepare a highlight report. Is it to review project progress based on milestones, or develop part of your plan, or all of these. If you go off agenda/objective here is a quick tip. Everyone is given a coloured card (any colour as long as they are the same). If a person goes off the agenda or is rambling on you put up your card. It works, try it.

Rule 4: Summarise before moving on to the next point. This ensures everyone is clear about what has been agreed or said.

Rule 5: Have a stand up meeting. Yes, stand up meetings i.e. NO chairs - speeds up the meeting and really does focus attention.

Rule 6: Papers, we are supposedly in the era of a paperless office. Ensure the meeting is not bogged down with papers. Use highlight reports to cut down paper and speed up the meeting.

Rule 7: Rules, what rules have you agreed? I know of one person who said that if the start time for a meeting was 3pm then no one was allowed in after this time! What are your rules for your meetings and does everyone know about them. Useful to use your cards here (rule 3).

Rule 8: Train, yes you can train people to be better in meetings. Chairing a meeting, contributing via appropriate questions, listening, preparing an agenda, these are all areas a person can be trained and developed. Call us or e mail events@projectagency.com for more information.

And finally (Rule 9) - review how successful your meetings have been. If you set out an hour and a half for a meeting and it has only lasted an hour then you should be saying well done (provided the meeting met its objective). If it lasted 2 hours then you should review why to stop it happening again.

Help make sure your meetings go well and help make the scores above better, much better.

21 Success Tips

21 Project Management Success Tips

By Karl Wiegers, Ph.D

Managing software projects is difficult under the best circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and unachievable demands from unreasonable people. Project management is people management, technology management, business management, risk management, and expectation management. It's a juggling act, with too many balls in the air at once.

Unfortunately, many new project managers receive little training in how to do the job. Anyone can learn to draw a Gantt chart, but effective project managers also rely on the savvy that comes from painful experience. Coaching and survival tips from people who have already done their tour of duty in the project management trenches can save you from learning such lessons the hard way. Here are 21 such tips for success, which I've learned from both well-managed and challenged projects. The tips are organised into five categories:

1. Laying the groundwork for success.
2. Planning the project.
3. Estimating the work.
4. Tracking your progress.
5. Learning for the future.

Together, the practices in these five categories define a project management control system that can help your project deliver on expectations. Keep these suggestions in mind on your next project, recognising that none of them is a silver bullet for your project management problems.

Laying the Groundwork

Tip #1: Define project success criteria

At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Begin by identifying your stakeholders and their interests and expectations. Next, define some clear and measurable business goals. Some examples are:

• Increasing market share by a certain amount by a specified date.
• Reaching a specified sales volume or revenue.
• Achieving certain customer satisfaction measures.
• Saving money by retiring a high-maintenance legacy system.
• Achieving a particular transaction processing volume and correctness.

These business goals should imply specific project success criteria, which should again be measurable and trackable. They could include achieving schedule and budget targets, delivering committed functionality in a form that satisfies customer acceptance tests, complying with industry standards or government regulations, or achieving specific technological milestones.

Also, keep your eye on team member job satisfaction, sometimes indicated by staff turnover rate and the willingness of team members to do what it takes to make the project succeed. The business objectives define the overarching goal, though. It doesn't matter if you deliver to the specification on schedule and budget if those factors don't clearly align with business success.

Remember that not all of these defined success criteria can be your top priority. You'll have to make some thoughtful trade-off decisions to ensure that you satisfy your most important priorities. If you don't define clear priorities for success, team members can wind up working at cross-purposes, leading to frustration, stress, and reduced teamwork effectiveness.

Tip #2: Identify project drivers, constraints, and degrees of freedom

Every project must balance its functionality, staffing, cost, schedule, and quality objectives [Wiegers, 1996]. Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds. There's bad news: not all factors can be constraints and not all can be drivers. The project manager must have some flexibility to react to schedule slips, demands for increased functionality, staff turnover, and other realities.

A "flexibility diagram" such as that shown in Figure 1 visually depicts your constraints, drivers, and degrees of freedom. A constraint gives the project manager no flexibility in that dimension, so it is plotted at the zero value on its axis. A driver yields a small amount of flexibility, so its point is plotted a bit higher than zero. Degrees of freedom provide varying degrees of latitude. They represent parameters the project manager can adjust to achieve the project's success drivers within the limits imposed by its constraints. Connecting the five plotted points creates an irregular pentagon. The smaller the area inside the pentagon, the more constrained the project is.

I once heard a senior manager ask a project leader how long it would take to deliver a planned new large software system. The project leader replied, "Two years." The senior manager said, "No, that's too long. I need it in six months." The project leader's response was simply, "Okay," despite the fact that nothing had changed in the few seconds of that conversation to make the six-month target achievable. A better response would have been to negotiate a realistic outcome through a series of questions such as the following:

• How critical is the six-month target? Does something drastic happen if we don't deliver in six months [schedule is a constraint], or is that just a desirable target date [schedule is a driver]?
• If the six months is a firm limit, what subset of the requested functionality do you absolutely need delivered by then?
• Can I get more people to work on it? [staff is a degree of freedom].
• Do you care how well it works? [quality is a degree of freedom].

Figure 1. A flexibility diagram for a project that is staff-constrained and schedule-constrained, with cost being a driver, and quality and features being degrees of freedom.

Tip #3: Define product release criteria

Early in the project, decide what criteria will indicate whether the product is ready for release. Possible release criteria might include the following:

• There are no open high-priority defects.
• The number of open defects has decreased for X weeks and the estimated number of residual defects is acceptable.
• Performance goals are achieved on all target platforms.
• Specific required functionality is fully operational.
• Quantitative reliability goals are satisfied.
• X% of system tests have been passed.
• Specified legal, contractual, or regulatory goals are met.
• The optimum marketplace time to release has arrived.
• Customer acceptance criteria are satisfied.

Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what "quality" means to your customers. Decide early on how you will tell when you're done, track progress toward your goals, and stick to your guns when confronted with pressure to ship before the product is ready for prime time.

Carefully consider your target market segments when deciding on release criteria [Rothman, 1999]. The early adopters and enthusiasts have a higher tolerance for defects than do the pragmatic early majority of customers or the conservative late majority. In contrast, time to market and innovative features or technology usage are most important to the early adopters.

Tip #4: Negotiate achievable commitments

Despite pressure to promise the impossible, never make a commitment you know you can't keep. Engage in good-faith negotiations with customers, managers, and team members about goals that are realistically achievable. Negotiation is required whenever there is a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates. Principled negotiation involves four precepts [Fisher, 1991]:

• Separate the people from the problem.
• Focus on interests, not positions.
• Invent options for mutual gain.
• Insist on using objective criteria.

Any data you have from previous projects will help you make persuasive arguments, although there is no real defence against truly unreasonable people.

I once met with an aggressive and intimidating senior manager to discuss our department's software process improvement plans. Jack was eager to see our department achieve CMM Level 2 by July of 1996. My process improvement group had carefully studied the problem and estimated that the end of 1997 was the earliest date that was even remotely feasible. After some debate, Jack grudgingly agreed to the end of 1996, but I regarded even that goal as pure fantasy. After additional discussion, I finally said, "Jack, I'm not going to commit to the end of 1996." I don't think anyone had ever told Jack he wouldn't make a commitment that Jack demanded. He wasn't sure what to say next. Jack eventually agreed to the target date to which I was willing to commit.

Plan to renegotiate commitments when project realities (such as staff, budget, or deadlines) change, unanticipated problems arise, risks materialise, or new requirements are added. No one likes to have to modify his commitments. However, if the reality is that the initial commitments won't be achieved, let's not pretend that they will up until the moment of unfortunate truth.

Planning the Project

Tip #5: Write a plan

Some people believe the time spent writing a plan could be better spent writing code, but I don't agree. The hard part isn't writing the plan. The hard part is actually doing the planning-thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analysing what it will take to solve the problem will reduce the number of surprises you have to cope with later in the project. Today's multi-site and cross-cultural development projects demand even more careful planning and tracking than do traditional projects undertaken by a co-located team.

A useful plan is much more than a schedule or work breakdown structure of tasks to perform. It also includes:

• Staff, budget, and other resource estimates and plans.
• Team roles and responsibilities.
• How you will acquire and train the necessary staff.
• Assumptions, dependencies, and risks.
• Descriptions of, and target dates for, major deliverables.
• Identification of the software development life cycle that you'll follow.
• How you will track and monitor the project.
• Metrics that you'll collect.
• How you will manage any subcontractor relationships.

Your organisation should adopt a standard software project plan template, which can be tailored for various kinds of projects. An excellent starting point is IEEE Std 1058-1998, the "IEEE Standard for Software Project Management Plans" [IEEE, 1998]. This standard describes a comprehensive template, sufficient for the largest projects. Study this template to see what sections would make sense for the types and sizes of projects that you work on.

If you commonly tackle different kinds of projects, such as major new product development as well as small enhancements, adopt a separate project plan template for each. Avoid overburdening small projects with excessive documentation that adds little value. The project plan should be no any longer nor more elaborate than necessary to make sure you can successfully execute the project. But always write a plan.

Tip #6: Decompose tasks to inch-pebble granularity

Inch-pebbles are miniature milestones (get it?). Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking. Select inch-pebbles of a size that you feel you can estimate accurately. I feel most comfortable with inch-pebbles that represent tasks of about 5 to 15 labour-hours, or about one to three days in duration. Overlooked tasks are a common contributor to schedule slips, so breaking large problems into small bits reveals more details about the work that must be done and improves your ability to make accurate estimates.

You can track progress based on the number of inch-pebbles that have been completed at any given time, compared to those you planned to complete by that time. Defining the project's work in terms of inch-pebbles is an aid to tracking status through earned value analysis [Lewis, 2000]. The earned value technique compares the investment of effort or dollars that you've made to date with progress as measured by completed inch-pebbles.

Tip #7: Develop planning worksheets for common large tasks

If your team frequently undertakes certain common tasks, such as implementing a new object class, executing a system test cycle, or performing a product build, develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Using standard worksheets will help the team members adopt common processes that they can tune up as they gain experience. Tailor the worksheets to meet the specific needs of individual projects.

Tip #8: Plan to do rework after a quality control activity

I've seen project task lists in which the author assumed that every testing experience will be a success that lets you move into the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. Base your estimates of rework time on previous experience. For example, you might have historical inspection data indicating that, on average, your developers find 25 defects per thousand lines of code by inspection and that it costs an average of 40 minutes to fully repair each code defect. You can crunch these kinds of numbers to come up with average expected rework effort for various types of work products. If you don't actually have to do any rework after a test, great; you're ahead of schedule on that task. Don't count on it, though.

Tip #9: Manage project risks

If you don't identify and control project risks, they will control you. A risk is a potential problem that could affect the success of your project, a problem that hasn't happened yet, and you'd like to keep it that way [Wiegers, 1998]. Risk management has been identified as one of the most significant best practices for software development [Brown, 1996]. Simply identifying the possible risk factors isn't enough. You also have to evaluate the relative threat each one poses so you can focus your risk management energy where it will do the most good.

Risk exposure is a combination of the probability that a specific risk could materialise into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities are not effective. Suppose you are concerned that your top developer might move to Australia to be with her new boyfriend. Consider the following actions:

• Pay her more money, offer to hire the boyfriend, or give her more vacation time to fly to Australia periodically (reduces probability).
• Keep her on as a telecommuting employee or contractor, have her document her work, or have her impart her specialised knowledge to other employees (reduces impact).
• Line up a consultant or contract specialist to replace her if she leaves anyway (contingency plan).

A risk list does not replace a plan for how you will identify, prioritise, control, and track risks. Incorporate risk tracking into your routine project status tracking. Record which risks materialised and which mitigation actions were effective for reference on future projects.

Tip #10: Plan time for process improvement

Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you'll have to invest some time in process improvement [Wiegers, 1999]. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Don't allocate 100 percent of your team members' available time to project tasks and then wonder why they don't make any progress on the improvement initiatives. Some process changes can begin to pay off immediately, whereas you won't reap the full return on your investment in other improvements until the next project. View process improvement as a strategic investment in the sustained effectiveness of your development organisation. I liken process improvement to highway construction: it slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput greater.

Tip #11: Respect the learning curve

The time and money you spend on training, reading and self-study, consultants, and developing improved processes are part of the investment your organisation makes in project success. Recognise that you'll pay a price in terms of a short-term productivity loss when you first try to apply new processes, tools, or technologies. Don't expect to get fabulous benefits from new software engineering approaches on the first try, no matter what the tool vendor's literature or the methodology consultant's brochure claims. Instead, build extra time into the schedule to account for the inevitable learning curve. Make sure your managers and customers understand the learning curve and accept it as an inescapable consequence of working in a rapidly changing, high-technology field.

Estimating the Work

Tip #12: Estimate based on effort, not calendar time

People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labour-hours) associated with a task, then translate the effort into a calendar-time estimate. A 20-hour task might take 2.5 calendar days of nominal full-time effort, or 2 exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. The translation of effort into calendar time is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears. If you keep track of how you actually spend your time at work, you'll know how many effective weekly project hours you have available on average [Wiegers, 1996]. Typically, this is only about 50 to 60 percent of the nominal time people spend at work, far less than the assumed 100 percent effective time on which so many project schedules are planned.

Tip #13: Don't schedule multi-tasking people for more than 80 percent of their time

The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multi-tasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so she could do five of them at once. In reality, she'll be lucky if she can handle three such tasks. Some people multi-task more efficiently than others. If some of your team members thrash when working on too many tasks at once, set clear priorities and help them succeed by focusing on just one or two objectives at a time.

Tip #14: Build training time into the schedule

Estimate how much time your team members spend on training activities annually, and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way. Recognise that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company's time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the knowledge is put to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.

Tip #15: Record estimates and how you derived them

When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is instinctively skilled at predicting the future. Develop estimation procedures and checklists that people throughout your organisation can use.

An effective group estimation technique is the Wideband Delphi method [Wiegers, 2000]. Wideband Delphi builds on the principle that multiple heads are better than one. The Delphi estimation method asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. Figure 2 illustrates the Wideband Delphi process flow. The outputs from the process include a complete list of project and quality-related tasks and an estimate for each task, in whatever units the team chose (such as dollars, weeks, or labour-hours). Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Delphi method more reliable than simply asking a single individual for his best guess.

Figure 2. The Wideband Delphi process flow.

Tip #16: Use estimation tools

Many commercial tools are available to help you estimate entire projects. Based on large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They'll also help you avoid the "impossible region," combinations of product size, effort, and schedule where no known project has been successful. The tools incorporate a number of "cost drivers" you can adjust to make the tool more accurately model your project, based on the technologies used, the team's experience, and other factors. Over time, you can calibrate the tool with your own project data to make it an even more reliable predictor of the future. A good tool to try is Estimate Pro from the Software Productivity Center (www.spc.ca). Others include KnowledgePlan (www.spr.com), SLIM (www.qsm.com), and Cost Xpert (www.costxpert.com). You can compare the estimates from the tools with the bottom-up estimates generated from a work breakdown structure. Reconcile any major disconnects so you can generate the most realistic overall estimate.

Tip #17: Plan contingency buffers

Projects never go precisely as planed. The prudent project manager incorporates budget and schedule contingency buffers (also known as management reserve) at the end of major phases to accommodate the unforeseen. Use your project risk analysis to estimate the possible schedule impact if several of the risks materialise and build that projected risk exposure into your schedule as a contingency buffer. Even more sophisticated is the use of critical chain analysis, a technique that pools the uncertainties in estimates and risks into a rational overall contingency buffer [Zultner, 1999].

Your manager or customer might view these contingency buffers as padding, rather than as the sensible acknowledgement of reality that they are. To help persuade skeptics, point to unpleasant surprises on previous projects as a rationale for your foresight. If a manager elects to discard contingency buffers, he has tacitly absorbed all the risks that fed into the buffer and assumed that all estimates are perfect, no scope growth will occur, and no unexpected events will take place. The reality on most projects is quite different. I'd rather see us deal with reality, however unattractive, than to live in Fantasyland, which leads to chronic disappointments.

Tracking Your Progress

Tip #18: Record actuals and estimates

Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, "If you write down what actually happened today, that becomes historical data tomorrow." Unless you record the actual effort or time spent on each task and compare them to your estimates, you'll never improve your estimating approach. Your estimates will forever remain guesses. Each individual can begin recording estimates and actuals, and the project manager should track these important data items on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in units of lines of code, function points, classes and methods, GUI screens, or other units that make sense for your project.

Tip #19: Count tasks as complete only when they're 100 percent complete

We give ourselves a lot of partial credit for tasks we've begun but not fully completed: "I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I'm probably about 60 percent done." It's difficult to accurately assess what fraction of a sizable task has actually been done at a given moment. One benefit of using inch-pebbles for task planning is that you can break a large activity into a number of small tasks and classify each small task as either done or not done, nothing in between. Your project status tracking is then based on the fraction of the tasks that are completed, not the percent completion of each task. If someone asks you whether a specific task is complete and your reply is, "It's all done except...", it's not done! Don't let people "round up" their task completion status; use explicit criteria to tell whether a step truly is completed.

Tip #20: Track project status openly and honestly

An old riddle asks, "How does a software project become six months late?" The answer is, "One day at a time." The painful problems arise when you don't know just how far behind (or, occasionally, ahead) of plan the project really is. Create a climate in which team members feel it is safe for them to report project status accurately. Strive to run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that sometimes arises from the fear of reporting bad news. Use project status information and metrics data to take corrective actions when necessary and to celebrate when you can. You can only manage a project effectively when you really know what's done and what isn't, what tasks are falling behind their estimates and why, and what problems and issues remain to be tackled. The five major areas of software measurement are size, effort, time, quality, and status. Remember the cardinal rule of software metrics: metrics data must never be used to punish or reward individuals for their performance.

Learning for the Future

Tip #21: Conduct project retrospectives

Retrospectives (also called postmortems or post-project reviews) provide an opportunity for the team to reflect on how the last project or the previous phase went and to capture lessons learned that will help enhance your future performance [Kerth, 2001]. During such a review, identify the things that went well, so you can create an environment that enables you to repeat those success contributors. Also look for things that didn't go so well, so you can change your approaches and prevent those problems in the future. In addition, think of events that surprised you. These might be risk factors for which you should be alert on the next project.

Conduct retrospectives in a constructive, honest atmosphere. Don't make them an opportunity to assign blame for previous problems. Capture the lessons learned from each review and share them with the entire team and organisation, so all can benefit from your painfully gained experience. I like to write lessons learned in a neutral way, such that it isn't obvious whether we learned the lesson because we did something right or because we made a mistake.

These 21 project management tips won't guarantee success, but they will help you get a solid handle on your project and ensure that you're doing all you can to make it succeed in an unpredictable world.