The Principles of Project Management

Value Creation

Delivering value is the only real reason to undertake a project. Whether you're increasing the monetary value of your home by adding an extension, or increasing the productivity of a team by making computer systems easier to use, there should always be a clear benefit to completing the project.

One of the most common issues that causes misunderstandings between business people and technical people is that they talk about value in different ways. For example, a technical team member might be talking about load-balancing the servers and introducing new quad-core processors while the business person stares at her, perplexed. When she's asked to elucidate, the techie starts trying to explain how it all works, so that the business person can comprehend the terms she's using, rather than hearing the cry for help that's inherent in the question!

Getting into the habit of talking about value in business terms is both smart and useful for any project manager. It can help reduce the number of communication problems you'll have, and smooth the way for the customer and the project team to work more effectively together. After all, if the technical person in the example above had explained that the project was needed so that twice as many customers could use the web site at the same time, all would have been clear to the project manager.

Value equals money. When you're talking about value creation, you'll need to be able to tie the project back to money. Whether the value is direct (that is, you're actually cutting costs or increasing sales), or indirect (you're increasing productivity, helping the organization's public image, and so on), you should at least find it easy to explain what the value is. Ideally, it should also be possible to quantify that value, for instance, to say "this project will save $30,000, or the equivalent of 50% of a full-time staff member." (As an aside, be aware that productivity savings seldom translate into staff actually being made redundant, except in very large-scale projects like mergers or factory relocations. The approach that involves measuring the amount of manual work that's removed is used here to illustrate that the team members will have that much extra time to invest in their day-to-day tasks -- time which, otherwise, they wouldn't have had.)

You can work out whether a project is worth undertaking in a number of ways. Regardless of which method you use, the most important points to ensure are these:

• The method for calculating value should be crystal clear (use the organization's standard methodology, if one exists).
• Any estimates of time or cost should be provided by the people who are closest to the problem. Only the people who are currently spending two hours a day manually reconciling invoices are going to know exactly how long it takes them.
• The approach you'll use to measure whether the results are actually being achieved should be identified up-front. For example, if you plan to make a saving of two hours per day, exactly how are you going to measure that? By asking the team members? Timing them while they work?

Industry standard methods for calculating the value of a project do exist, but they can be quite complicated and certainly are more involved than those that are commonly used in most organizations. The most important point is to establish that value is being created, so that the organization can be certain to enjoy definite, measurable benefits if the project is undertaken.

When the time comes to measure that benefit in a more sophisticated way, perhaps to justify funding or to compare similar opportunities, understanding more about net present value (NPV), return on investment (ROI), internal rate of return (IRR), and similar methods and measures will be useful. Appendix A, Tools lists some locations at which you can find out more about these formal metrics.

Now that you've hopefully seen or constructed a proposal for the project you're about to undertake, and you've formed a better idea of what sort of value it will be creating, it's time to move on to look at who will be affected by, and involved in, the project.

Who Are All These People?

... and what are they doing on my project?

Even the smallest project can impact a number of people. As the project manager, you're at the centre of an intricate web of people who are bound together by their common interest in the project you're managing. Let's meet the various people who are involved in any project, discuss the roles they play, and explore how you can manage their participation.

Stakeholders

Stakeholders are those people who hold a stake in the project -- they're people who care about the project's outcome. "Stakeholders" is really a catch-all term that can be used to describe such disparate groups as senior management, end users of systems, customer representatives, administrators, members of the local community, and union representatives. Anyone who feels that the project might affect them could regard themselves as a stakeholder.

How then do you go about identifying stakeholders? And why would you want to do so in the first place?

It's important to identify your stakeholders so that you can understand their points of view, and get an idea of the pressure they'll try to exert on your project. An architect may not think to worry about the local group of amphibian enthusiasts until they start petitioning the local government to withdraw the permission it granted the architect to build on a particular site that is in fact among the last-remaining habitats of great-crested newts -- which the architect has never even heard of before! (You may think I'm being funny here, but that's a real world example! One of the office buildings on the business park where I work had to be delayed because the site was one of the last remaining habitats of the great-crested newt.)

Luckily, most stakeholder groups are more obvious than this, and they're usually very keen to have their voices heard from the outset. The way to start identifying stakeholders is to think about the project itself:

• What are you building?
• What business processes are you changing?
• Who are the people that are currently executing those business processes?
• How will they be impacted by the change?

The easiest stakeholders to identify are those who are directly affected by the project. If we consider this chapter's case study project, in which you're introducing a web site to deal with customer orders, queries, and complaints, we can readily see that the main group affected will be the customer service team. The management of that team will also be affected, as will the IT staff who need to help make the existing call-tracking system integrate with your new web site. And, of course, the actual customers will be affected too -- some of them may love the idea of reporting issues via a web site, but others will be concerned that the change in technology will mean slower, less personalized service.

Thinking a little more broadly, we also realize that the sales and marketing teams are stakeholders in the project. After all, as soon as they heard about the possibility of the customer web site, they had the influence to get it prioritized over the other potential projects! After the project proposals were drawn up and you realized that the four projects really needed to be combined to deliver the true business value, the product supply team, who's in charge of the warehouse (and therefore the inventory system), were also identified as stakeholders. Can you think of anyone else who might be affected?

Sometimes the most important stakeholders to worry about are those who are less obviously linked to the project. Senior managers who have promised to deliver a "step change" in the efficiency of the call centre group, or those who are trying to prove that the entire department could be outsourced to Bangalore, may keep their motives closer to their chests. Equally, interest groups from outside the company (whether they're politicians, consumer groups, or the local amphibian enthusiasts' society) may be difficult to locate.

Don't get too hung up on identifying every possible person who might care about your project, but do make the effort to involve those that are obviously interested. Talk to people in the organization about who will be affected and actively seek out those who you believe will care most. Understand their concerns and think about how to involve them in the project. After all, taking the initiative and defining how they will be involved is better than ignoring them, then later having them force their way into a project meeting and explode at everyone!

We'll now look at two special groups of stakeholders -- the project board and the project team itself.