By: Meri Williams

March 26th, 2008

Reader Rating: 6.5

You've already got an understanding of the basic project life cycle, and we've just talked through some of the underlying principles of project management. But I bet you're itching to actually do something. In this chapter, which is taken from SitePoint's new title, The Principles of Project Management [1], we'll talk about the work that comes before the project life cycle -- finding possible projects, working out which projects are worth pursuing, and getting to know the different groups of people who will be involved in any project. Finally, we'll discuss the process of actually initiating a project.

I know -- we're covering a lot here! But as always, you can download this chapter in PDF format to read offline [2].

In each of the sections that follow, you'll find a discussion of what the process is and why it matters, followed by tools and best practices that will help you get your project off to a flying start.

Discovery: Finding the Projects

Projects don't just spring from nowhere. Although many project managers only get involved when it's already been decided that a project will be undertaken to achieve some end, there is, of course, a phase before this: discovery. Discovery is the process by which the organization reviews the available opportunities and decides which of them will become projects in due course.

Ideally, the discovery process should ensure that the best opportunities are pursued -- not just those that were mentioned first, or those that have the loudest supporters. Where this process is undertaken, it's usually combined with some sort of portfolio planning through which the potential projects are matched against the resources or capabilities of the organization itself. The eventual result is a list of projects that are truly the top priorities.

The sad reality is that in many cases, there's either no process at all for discovery and portfolio planning, or the process that's in place doesn't result in the selection of projects that will deliver the most value. It's also true that as a project manager, your influence may be very limited at this stage -- after all, in many cases, you won't even know about the potential projects until one is assigned to you!

However, understanding what has been discovered, and how the project that you're managing came to be started, is very important. It can tell you whether the project is truly of high value to the organization for which you're working (either as an employee, contractor, or service provider) or whether its potential value still needs to be ascertained. It may also give you early insight into the complexities you might have to face during the project.

If you find that little or no discovery work has been done, don't despair -- do it yourself! Find out why people in the organization think your project is important. Understand what they're expecting the project to deliver -- try to focus on what it means to them, not the nuts and bolts of what will be built. If their answers suggest that they don't think the project matters, find out where they think the time and effort would be better spent.

Your first instinct will be to protect your project, but you might find an opportunity for another project that will deliver even more value. Even if you don't end up jettisoning the original project and taking on the new one instead, bringing it to the attention of the stakeholders within the organization will make you stand out as a project manager who really cares about the good of the company, not just your own projects.

Example 2.1. Choosing the Wrong Options

Imagine there's a team at a company you're working with that deals with customer orders. The team members have identified a number of opportunities:

Remove manual work from current processes.
Many in the team feel that they spend almost all their time shuffling paper, rather than actually dealing with the customers.

Speed up inventory checking.
When a customer places an order, the team members have to call up the inventory team to find out whether the goods are in stock or not. Making this process faster would improve their efficiency greatly.

Improve tracking of customer orders, queries, and complaints.
Currently, all tracking of customer interactions is done manually. There's actually one person in the team whose full-time job is collecting the information and putting it in an Excel spreadsheet!

Allow customers to interact in more ways.
A number of customers have signalled that they'd like to be able to email the team as a whole, or to input queries and complaints online.

As you might have guessed, the opportunities above are ordered in terms of importance. The team feels that reducing their manual work is most important, with the inventory tracking improvements and customer tracking automation coming a close second. Once these fundamental issues have been fixed, the team feels that it can start work on items that will really benefit the customer -- introducing a web site and email addresses so they can log orders, queries, and so on.

When people from elsewhere in the organization get involved, however, they get very focused on the web site for the customers. Marketing can see that this will be a real selling point and the sales teams think that it will delight their contacts. They don't realize that in order for the customer web site to be successful, the team needs to have all the other opportunities addressed first.

The first you know about any of this, however, is when you're brought in to build the new customer web site. You get started working on it, but are finding that the people from the team who deal with the orders are very difficult to work with: they won't answer questions clearly, don't turn up to meetings that you've organized, and don't answer emails unless they're reminded to again and again. You're sensing hostility, but you have no idea why -- you've only been there a week. Surely you can't have offended them already?

You get in touch with some of the IT guys that you know from the last project you worked on for this company and ask them what's up. They explain about the other projects that this team identified ... and that the team actually thought those other projects were more important. However, someone in the marketing team, having heard about the possibility of the web site being developed, promised one of the big customers that it would be ready soon, so management decided to prioritize this project over the improvement of the systems.

Now you understand why the team is so unresponsive! They're upset because their own needs have been ignored, and now you're working on the project that they've been forced into prematurely.

At this point, it can be very easy to get depressed or start panicking. What if the team continues to sabotage the project and you get blamed when it isn't delivered? You don't have the power to go back and work on the project they really wanted to happen, so perhaps you should just give up now ...

The point, though, is that now you understand what was causing the team to be unhelpful and unresponsive. Armed with that knowledge, you can do something about it!

As we've already discussed, often the project manager won't be involved in deciding which projects will be undertaken. In this particular situation, however, you can try to mitigate some of the impacts of the web site project being prioritized over that of updating the existing systems.

Firstly, you have a discussion with Pamela, the team member who's been the main cause of friction so far. You explain that you understand there were originally other projects on the cards, and ask her to clarify for you what they would have entailed. As she talks, you realize that some of the elements of the existing manual process are going to be problematic for your project as well -- for instance, it won't be possible to determine whether or not an item is in stock without someone making a phone call.

In this particular example, there's an obvious route forward -- help to identify the modernizations of the existing system that are required for the web site project to be a real success. Then push either for these to be brought into the scope of your own project, or for a separate team to be set up to deal with those issues in parallel.

However, even if you won't be able to influence the organization to work on the productivity improvements as well as the site, just having spoken to Pamela seems to have improved relations immensely. She commented that you were the first one of the "techie guys" who had taken the time to really understand why the team is so frustrated. She has started responding to your queries and emails and even seems to have told the rest of the team that they should help you out as well.

The point is that without understanding where your project's roots lie, you're flying blind. By investing some time to find out a little more about how the discovery work was or wasn't done, and how the decisions were made, you can gain a valuable insight into the challenges you might face, day to day, on the project. This approach can also give you an early warning of any office politics that might make your life difficult!

Picking the Best Projects

Choosing the best projects to work on involves a three-step process:

1. Identify the opportunities.


2. Compare the opportunities.


3. Rank them and decide which to undertake.

Identifying the Opportunities

There are many approaches to identifying opportunities, some of which are more sophisticated than others, so let's start by considering some of the basic tools that you'll probably already have come across.

The most obvious option is a brainstorm. Get people in the organization together, and ask them to think of anything that annoys them, anything that could be done better, or things that aren't being done yet that could be started.

The Stop, Start, Continue Approach
One model that you can use to get people to focus called Stop, Start, Continue. Here, you essentially ask the people in the room to name one task they want the organization to stop doing, one task that it should start doing, and one task that it should continue to do.

If it's obvious that a particular business process or set of processes is causing a lot of pain, manual work, or rework in the organization, it might be worth charting that process. You can do this using any tool -- from the good old marker and whiteboard, through to bespoke process-flow mapping tools or UML diagrams. (UML stands for Unified Modeling Language, and constitutes a set of standard formats for creating flow diagrams of processes, data, etc. UML tends to be popular with usability professionals and software engineers. As always, think carefully about the tools you choose—they need to be understandable and accessible to everyone involved.)

Once you have drawn out the business process, look at each step and ask, "Why do we do this?" If there isn't a good reason to take the step, remove it! If the step is necessary but could be done more intelligently, ask how. If the question of what needs to change isn't answered easily, a project to fully investigate the options and create a solution could spring from your analysis.

Example 2.2. Innovate or Improve

One example of the need for innovation is made clear by the anecdote about an early 20th-century buggy whip manufacturer. The organization was focused on making whips (used on horses that drew buggies and carts) faster, cheaper, and better ... at a time when horse-drawn carts were rapidly being replaced by motor cars. Making the buggy whip cheaper was not going to increase sales, since price was not the problem.

Remember, though, that sometimes the opportunities that are the biggest -- the projects that will make a huge difference to the business -- might be those that don't represent incremental improvements. In many cases, the real way to make a difference may be to realize that there's a completely new direction to take, product to focus on, or way to operate.

Comparing the Opportunities

Once you have a list of opportunities that could be addressed, you then need to work out which is the most important. You might want to start by identifying what benefit would be generated if the process was fixed, the gap was filled, or the new service was created. Would it reduce the amount of work for someone? Make the company more money? Bring in new customers? Reduce risk in some way?

Typically, the reasons why a company decides to approach an opportunity are one -- or a combination -- of the following benefits:

• to increase income (higher sales, new market, new service)
• to decrease costs (make it cheaper, faster, lower inventory)
• to improve productivity (same work done with less time/cost/people)
• to reduce risk (increase tax compliance, improve audit score)

Once you've identified what the benefit of each project is, you need to work out how big that benefit will be. Ideally, you'll want to be able to measure the benefit in numbers somehow -- whether it's that someone can get 50% more invoices posted, that sales increase by $50,000, that widgets now cost only ten cents, or that your accountants smile for the first time in living memory.

What's the Problem?
At this stage, you're still comparing the opportunities, not the projects! Think of problems and gaps at this stage -- we'll be looking at the solutions (projects) soon enough.

Later on in this chapter, one of the discovery tools we'll look at is value creation -- an approach to working out the value that will be delivered by a project.

Ranking and Choosing Opportunities to Pursue

Now that you have an idea of the available opportunities, and how much of a benefit could be gained from addressing them, you need to work out which one to tackle. You may have uncovered an opportunity that's so big that you feel it's imperative to go ahead and deal with it immediately. More likely, however, is the eventuality that you'll have a number of options, and will need to decide which is the most important.

First, rank the opportunities in order of their potential benefits. Second, work out what a project might entail in very, very rough detail -- literally just a sentence or two describing how you'd go about solving the problem. If you have no clue, the project may well focus on researching and finding a solution that can, ultimately, be implemented!

For instance, if we think back to our earlier case study, the problems had already been ranked in the order that was most important to the customer service organization. Their focus was cost saving and productivity. It was when the marketing folks (who are more focused on increasing sales) got involved that the equation changed, as they were interested in the increased income.

In this situation, we might rank the opportunities available through a project in terms of the number of areas each would affect. To do so, we could use a matrix like the one in Table 2.1, "Ranking and Roughing Out Opportunities and Benefits".

Ideally, the next step would be to quantify the benefit by working out the numbers. In the case of a clear cost saving, assigning a figure is easy. If you predict that reducing paperwork will mean a monthly saving of the funds currently spent on paper, printers, photocopiers, and so on, you can simply total those numbers. When you start to predict increased sales and productivity improvements, however, the calculations become fuzzier. Don't get hung up on representing everything in cash terms; instead, express the benefit as clearly as possible, so you can get it in front of the right people to have a decision made about the project.

Next, try to rank the projects in terms of which are easier or cheaper to complete. Depending on your situation, the questions of ease and affordability may be of greater or lesser importance. If people within your organization could be assigned to a given project, you're probably more concerned with how quickly they could make a difference. On the other hand, if you'd have to pay a third party to come in and deal with the project, the project's cost may be a bigger issue.

Having worked out where the greatest benefit can be gained for the lowest cost, you can, in collaboration with the relevant stakeholders, pick a project or two to proceed with.

It's Only a Rule of Thumb
Don't forget that at this point, all you have are initial estimates. You haven't spent a great deal of time making sure that the potential benefits and projected costs are really accurate.

This is a "rule of thumb" type tool -- in the project Initiation phase, you should make sure that both the cost and benefit sides of the equation are investigated and validated. If you find that an element of the project is considerably different than you'd predicted, you might even come back to the discovery phase and pick a different project to work on.

Is the Best Project for the Organization the Best for You?
This process is focused on finding the best projects for the organization. As an external contractor or service provider, you also need to care about the benefits your business will gain from the projects you work on.

You might also want to conduct a similar comparison of the projects you have the option of undertaking -- across all your clients -- and picking the ones most likely to benefit your own organization. The process will be the same, but some of the considerations might be different. For example, you might choose to undertake a project that will make less profit, but has strong potential to lead to more work in future. You should invest as much energy in choosing the right projects for yourself as you do in helping your clients select the best projects for their own needs.

Spotting Bad Projects

As we've already discussed, many project managers aren't involved in the discovery phase, where good projects are selected. As a result, an ability to spot the signs of a bad project is a valuable skill for the project manager to develop.

First of all, let's think about some hallmarks of good projects:

• They deliver big benefits, with defined metrics that specify the size of those benefits.
• They're important to the future of the organization (or, in management speak, they're "strategically important").
• Sufficient resources are invested in them.
• They have supporters within the organization.

We'll talk more about the kinds of supporters you need, and the importance of having a sponsor for your project, later in this chapter.

The hallmarks of a bad project contrast rather predictably with those outlined above:

• Projects for which no one has really identified the business benefit, or for which the closest you can get to a cost estimate is someone waving their hands in a the-size-of-the-monster-catfish-I-caught-last-summer type gesture are dangerous.
• Projects that focus too heavily on the present and neglect the future are dangerous. Think of the buggy whip manufacturer investing in making his production lines faster and cheaper, rather than realizing that a change in direction was needed.
• Insufficient -- or nonexistent -- resource investments in a project are another warning sign that you should beware of. Projects without budgets, people, or equipment are risky from the outset.
• Projects that are being undertaken even though only a few people in the organization believe that they should be completed are the most dangerous of all. These kinds of projects quickly start to feel like everyone's just standing around watching, and waiting for you to slip up and prove them right.

Beware of Focusing In the Wrong Place
Today's technology is very advanced, and as a consequence, our options seem limitless. It's rare that tasks aren't attempted because they're viewed as being impossible. In fact, quite the opposite is true -- organizations often choose the unlikeliest paths, optimistically believing that their rough plans will all come right in the end.

I have nothing against optimism, but personally, I like to have the odds stacked in my favor! Making sure that you're focused on the real reasons for completing the project, rather than on what's technically possible, is imperative. A benefit-focused approach also often makes the difference between a fantastic project manager (who achieves what the organization needs) and a mediocre project manager (who does what's asked, but doesn't work out if that's what's best).

Why would any of these projects survive, you ask? Well, the reality is that they won't! The reason that they get started in the first place is that the people creating the project aren't really sure about what they're trying to achieve. Helping them to define the business benefit is usually the first step to fixing this issue -- as soon as they realize how important the project is, dedicating the required investment into resources is an obvious step to take. Supporters also flock to important projects (so much so that you might actually be overwhelmed). Making sure that the work is aligned with the strategic objectives of the company is what those high-level sponsors are good at.

Project, or Day-by-day Improvement?

The other question that needs to be worked out during the discovery phase is whether a project is really needed at all. Although a project is, at its simplest, just a one-time piece of work, in practice, most organizations also have guidelines that describe what's seen to constitute a project, and what's regarded as merely a minor change or fix.

As an example, the rule of thumb in many companies is, "if the job needs at least one full-time staff member for two weeks (or the equivalent), then it's a project." The important issue here is the size of the effort -- if you're going to have two people working full-time for a week, or four people working at 25% of capacity for two weeks, those staff hours all reflect the same amount of effort. A job that will take one person a day or two, by contrast, would not be treated as a real project.

Work that's routine or ongoing is never a project. The management speak for this kind of work tends to involved words like "operational excellence" or "continuous improvement," which are both really just corporate ways of saying "being better at what we do every day." Sometimes, a project will be undertaken to introduce a capability that will make the day-to-day work more efficient and productive -- for instance, updating the systems that are used, or introducing new business processes such as problem, change, and incident management.

Very small pieces of work, or mini-projects, may well be absorbed into the normal day-to-day work. This approach can blur the lines between project work and normal operations for many people. It's worth understanding how the organizations you're working with distinguish projects from regular work, and thinking about the impact this may have on the projects you're leading.

If some of the people involved in your projects usually just work on day-to-day operational tasks, they may be completely unfamiliar with a project-based style of work. You might need to meet with them separately to explain project management, clarify your role as the project manager, and illustrate how the project will be run.

Setting Expectations and Priorities
You might also need to set expectations more explicitly around deadlines and priorities -- it can be hard for individuals to prioritize project work over day-to-day operational tasks unless they've been told this is the right attitude to take.

Again, this isn't a huge issue, but you should be aware of it. When you're very used to completing project-based work, it can be easy to forget how the other half lives!

Discovery Tools and Practices

The full range of tools and practices that can be useful in discovering projects within an organization would include:

• idea elicitation
• portfolio management
• organization building
• resource planning

On their own, the discussion of these tools could easily warrant a separate book, so I'm going to focus on the tools and practices you're most likely to need as a project manager who gets involved once the decision to undertake the project has already been made: project proposals and value creation.

Project Proposals

Project proposals are simple, short (usually single-page) documents that outline the potential project, provide brief background information, identify the value of undertaking the project, and give a very rough estimate of the resources (budget, people, time) that would be required to deliver the project. (Project proposals are sometimes called project request documents (PRDs) or project charters, though the latter indicates a little more finality and is more like the project initiation document we'll talk about later in this chapter.)

Ideally, a project proposal is collected for each of the possible projects, and from this pool, the projects that are determined to have the potential to deliver the greatest benefit to the organization are chosen. The project proposal is a document that illustrates the value of completing the project and recommending that the project be resourced.

Now, this may sound good, but have you spotted the big warning sign yet? These proposals are the first indication to management of what the project will be, and what it will deliver. They even include rough estimates of how long the project will take, how much it will cost, and how many people will need to be assigned to it. Yet minimal effort is invested in getting these estimates right -- the project doesn't exist yet, so no one's actually working on it! Of course it would be unrealistic to expect anything else, so really this is just a caveat we all need to be aware of.

We've already identified that project proposals are fundamentally flawed, so why am I advocating them? Well, what would be worse than a flawed project proposal? It would be worse to have nothing at all! At least if you have a proposal, you have documentation that represents the foundations of a contract between the project team, the customer, and management. Without it, you have to guess the expectations of each group -- clearly an unenviable task unless your telepathic skills have been improving recently!

But what can you do if there isn't even a project proposal, and you're faced with amorphous, hand-waving descriptions of what the project is meant to be? This is the beauty of the project proposal -- you can have a proposal written retrospectively, even if the decision to go ahead with the project has already been made. Some companies and freelancers use a very similar template to form the basis of quotes.

Once the project proposal is written -- by you, or by someone else -- what can it give us? There are three key pieces of information that project managers will want to obtain from the project proposal:

1. Understand the project's background -- What problem does the problem solve? What process does it affect?


2. Gain a clear explanation of the business value that the project will deliver -- Why is the project important to the organization?


3. Ascertain the expectations of the project's timing, personnel, and budget -- If, from the outset, you can see that the project is hopelessly underfunded, or that the delivery date is wildly optimistic, it will be better to deal with these concerns up-front rather than coming to them later, when your wish to change these factors may be perceived as an attempt to renege on the initial project agreement.

Project proposals can also help us to identify assumptions and constraints. Remember the four opportunities we discussed earlier, in the example in the section called "Discovery: Finding the Projects"? When we go back to write project proposals for each of those opportunities, it'll become obvious that implementing a customer web site without fixing the manual processing, inventory, and call-tracking issues isn't sensible.

The scope of the project can then be expanded to include a complete customer relationship management (CRM) solution. This way, the operational team will only need to use one system to manage all of the customer interactions, and the task of optimizing the business processes can become part of your project.

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.

The Project Board

The project board is a small group of people whose main responsibility is to make the really big project decisions. Much as you, as the project manager, have an incredibly important role to play, and indeed will make many of the day-to-day decisions, you'll always be focused on delivering the project. The project board is there to make the really big strategic decisions -- even if that means potentially killing the project.

Your project's board should consist of:

• the project sponsor
• a technical advisor
• a business advisor or domain expert (if needed)

The project sponsor is the embodiment of the project customer, that is, the person for whom the project is being delivered. Typically, this person will be the head of the department that will benefit the most from the project, though in some cases, if multiple groups within the company will all benefit from the project, the sponsor may be someone who's even higher up within the organization. This person is usually also the one who's paying for the project, so he or she will have a clear interest in ensuring that value for money is delivered. Ultimate decision-making authority resides with the project sponsor.

Choosing the right project sponsor is very important. This person needs to be interested enough to stay involved and take the project seriously. He or she equally needs to be senior enough to have the authority to make the very big decisions -- even the decision to cancel the project if necessary.

Sometimes, you don't get to choose the project sponsor: either someone has already been selected, or is chosen without much input from you. This can be fine -- the sponsor may be interested in the project and have sufficient authority to help you achieve results. Equally, they may seem disinterested and disengaged from the project.

Dealing with Disinterested Sponsors
If you find yourself working with a disinterested sponsor, sit down with that person and discuss the project, his or her role within it, and your expectations. If the person can be the sponsor you need, engaging him or her in a discussion may well pique the sponsor's interest and lead to more active involvement. Alternatively, if you need more than the sponsor can give, he or she may step aside quietly, or even volunteer to help you find a replacement.

The technical advisor and business advisor or domain expert are there to provide perspective and advice to the project sponsor. The sponsor may not understand the full technical or business process implications of certain decisions that need to be made through the project -- he or she can rely on these advisors to promote and encourage the best possible decision.

As project manager, you should expect to meet with the project board regularly to provide progress updates and discuss any key decisions. Usually, the role of the project manager is to lay out the options and recommend the course of action that you believe is the best way forward. However, it's important to realize that the project board's job is to make the really crucial decisions, which may even extend to stopping the project if it's been delayed too long, is too expensive, or if there's evidence that the desired value will not or cannot be delivered.

Usually, the biggest challenge with the project board is not to identify the three members, but to keep the size of the board to just three! All sorts of stakeholders will feel that they should be on the project board, particularly in organizations where decision-making authority is seen to convey status.

What you ideally want is for all stakeholders to feel that they're being represented on the board by at least one of the three members, rather than needing to be on the board themselves. This is another reason why project board members are often senior members of the organization -- if the other stakeholders report to them (either directly or indirectly), the board members will also be representing their views.

But let's get back to our example. Before we realized that the four projects really needed to be combined, the project might have had a very different project board, as different teams would have been involved and affected. However, for the combined project, we identify that since the customer service, sales, marketing, IT, and product supply departments are all affected, John Vaswani, the Head of Operations (which encompasses all these groups) is the right person to be the project sponsor.

The technical advisor will be Sandra Chan, Head of IT, who can advise on how the solutions being proposed will fit with the existing company systems, and how ongoing maintenance and support will be completed. The Head of Customer Service, Adam Garcia, will also participate on the board as the business expert. They will, of course, be advised by their own operational teams, but the point is that the project board will include three key people who can make the big calls!

As soon as she heard about the project board being formed, the Head of Marketing wanted to be included as well. You had a difficult decision to make. As far as possible, it's best to keep the number of board members low. Any efforts to expand the board can easily snowball until half of your stakeholders want to be on the board casting their votes! That said, if the project scope is broad, and you're going to be working on business processes in a wide range of areas, as in this case, it can be useful to have multiple business experts.

In this case, however, you sit down with the marketing chief and explain that the marketing department will still be consulted -- you want to have some of the marketing team on the project as "consultants" to ensure that the solution that's developed isn't solely focused internally, on the customer service team's needs. The marketing department's point of view would also be represented on the project board by John Vaswani, who, as Head of Operations, will be interested in making sure that all of the different areas work together as efficiently as possible.

You come away from this meeting with a double win: content with the proposed arrangement, the Head of Marketing has already assigned some of her team members to be more directly involved with your project. You've also managed to keep the size of the project board down to three, which will make the decision-making process much smoother than it would have been if the team was bigger.

The Project Team

The other stakeholders that are very obviously quite invested in the project's success are the project team members themselves. These are the folks who are working alongside you to deliver the actual work and, as such, they're essential! Depending on your circumstances, the project team members may herald from different backgrounds and companies, and may have been brought together just for this specific project, or they might comprise an existing team that's been charged with focusing its efforts on this new challenge.

Whichever is the case, ensuring that you have the right mix of abilities on the project team is key. We'll talk a lot more in later chapters about how to help your team members work well together, but the first step towards harmony is to make sure that they have the skills necessary for the job.

As with the other stakeholders, you'll want to understand where the people in your project team are coming from. You may well find yourself with a mix of contractors and employees, some working full-time and some part-time. What are their personal motivations? How do they feel about working on this project? Are they viewing it as the opportunity of a lifetime or a punishment? Do they feel they have the needed skills, or are they worried that they're out of their depth?

"Hang on a second!" I hear you protest. "I'm not their manager. Why should I care about how they're feeling?"

Even though you may not be their line manager, or responsible for their careers, you still need to care about how your team members feel, since this will affect your project. People will always be the most complicated component of any project, so it's crucial that you become adept at understanding them. While this may seem daunting, the reality is that just by listening to your team and trying to understand where they're coming from, you'll learn almost everything you need to know. The elements that you don't uncover by talking to them, you'll learn from watching them work together (or failing to work together, as the case may be!).

When you're starting a project with a new team, I suggest that you sit down, one on one, with each individual. Ask them what they're looking forward to and what they're feeling apprehensive about. Share your vision for the project and how you see them being involved. Try not to pile on the expectations too much, though; rather, focus on listening to how they feel about the project and what concerns they might have.

What If It's Just Me?

Sometimes you may find yourself being both project manager and project team. In this situation you might doubt the need for project management. Your doubts would be valid! If you're a team of one, the tools and practices of project management that focus on team collaboration won't be as useful. With no need to share and communicate, you can keep track of your tasks and deliverables however you like.

Realistically though, much of the true value of project management is in communicating to the stakeholders and project board, rather than your team. Project success depends on the involvement, trust and often contributions of the stakeholders. Equipping the project board to make well-informed key decisions is also extremely important.

If you are a freelancer or similar, primarily working solo on projects, then you may well want to strip down to just the essential tools and best practices. By focusing on the tools that smooth your interfaces to stakeholders and project board, you will get the most out of your investment in project management. For more information, see Appendix A, Tools.

Stakeholder Tools and Best Practices

Let's examine some of the tools and best practices that will help you identify stakeholders and manage their involvement in your project.

The Project Organization Chart

A project organization chart is a simple graphical illustration of who's involved in the project and where they fit in the overall organizational, or project, plan. First you'd include yourself, the project manager, with the project team linked in beneath. You report to the project board, which is led by the project sponsor. Depending on the specifics of your project, you will likely then group the remaining stakeholders into their respective areas (for instance, end users and IT staff). These groups are shown on either side of the project team, since they'll be giving input as the project progresses, as Figure 2.1 reflects.

To create a project organization chart, follow these steps:

• Write down the names of everyone who's involved in the project.
• Group them according to their roles -- project board members, stakeholders, and project team members. In most cases, you'll need to split the stakeholders' group further into the various stakeholder categories.
• Chart the results graphically, with project board at the top, the project team in the middle, and stakeholders radiating out from them. If some of the stakeholders report to the project board members, it may be worth indicating this on the chart.

The project organization chart is useful because it illustrates to everyone within the organization who's directly involved in the project (that is, the project team and board), and who has a more advisory role to play. You may need to consider establishing a team of key stakeholders who will be directly involved in the project, whether they're providing realistic testing for the product, or helping with the requirements gathering task.

Is There Anybody Out There?
If people in your project haven't worked together in the past, or if they're spread across offices or even time zones, it may be worth adding their photos and contact information to the organizational chart. Making it easy for team members and stakeholders to get in touch with each other can only aid communication and collaboration.

As your project progresses, keeping the project organization chart up to date becomes more and more important. Projects tend to get more complex as they continue, and more people get involved, and understanding where any given person fits into the bigger picture is important if you are to have a context for his or her input. A particular stakeholder who complains about everything, wants to be involved in every decision, and generally makes a nuisance of himself or herself can be difficult to deal with. But, by looking at the project organization chart, you might realize that that particular individual is really a minor stakeholder, but reports to the project sponsor. In the process, you may also recognize that the person is trying to get noticed in the run-up to the annual review period, which can help you work out how best to deal with this individual.

Perhaps you'll choose to have a word with that person in private, and ask for his or her help in making the project a success; you may also involve this person more obviously in the project so he or she obtains the desired visibility. On the other hand, if the person is being positively destructive, you might choose to have a word with the sponsor to see if that individual's efforts couldn't be redirected somewhere more constructive.

Organizational Chart Evolution
Quite often, your organizational chart will evolve. Before your project has really started, you might not have a full picture of what the team will look like, and which stakeholders will be involved. It's a useful tool from the very start, though, so always start by drawing a rough chart on a piece of paper, even if you only progress to a shareable electronic version later on during the project's Initiating or Planning phases.

The Communication Plan

A communication plan is a simple document that outlines how you will communicate the project process, how frequently you'll do so, who will be invited or involved, and who will be in charge of making sure the communication occurs.

The communication plan should cover everything from monthly email updates (which might be sent to all the interested parties) to daily meetings (for the project team) and fortnightly board meetings (organized by you with the project board). It might also define what specific information you'll be reporting to a much wider public -- for instance, for particularly important projects, it might be worth posting summary updates on the homepage of the company's intranet.

Therefore, anyone who's interested in the project, or feels that their own work might somehow overlap with what your team is doing, can see what's going on. You should always include your contact details alongside this type of communication -- after all, you never know who might warn you of the next big project hiccup!

Letting Them Know
Believe it or not, some of the value of your communication plan lies just in letting people know they'll be kept informed! Uncertainty is the cause of a lot of noise in projects. The communication plan can not only reassure stakeholders that they'll be kept in the loop, but can also inform them of how and when this will happen. It can also help you to ensure their input is directed to the appropriate people and points in the project, and avoid having them crash your team meetings!

Initiating Your Project

Now we're ready to really get going with the project! So let's look at why initiating your project well is so important, and how you should go about it. We'll also investigate some of the tools and best practices for doing so.

The Purpose of Initiating

The purpose of the Initiating phase is to set the project up for success. I often argue that it is the most important phase of the project life cycle, since, if it's neglected, the results can be catastrophic. After all, the beginning of the project is the point at which you form with the customer the contract (both formal and informal) that explains what will be delivered, roughly how it will be done, and when it will be ready.

The formal contract will be the piece of paper you sign, but the informal contract is the unspoken understanding between yourself and the other interested parties. Often the informal contract is the more important of the two -- people are more interested in what they believe you're going to deliver than the specifics written in the contract. This is especially true if the contracts are drawn up by a lawyer or separate part of the organization. If you're working internally and there's no formal contract, the informal contract is all that matters!

Keeping the Project in Perspective
Unless this is agreed on, you and the customers can walk away with completely different understandings of what you're trying to accomplish. These differences of perspective will only creep out of the woodwork to cause you trouble later on, unless you consciously shine a light on them during the project's initiation.

Initiating is also the best chance you'll get to define success. At the very outset you can agree on the project's success criteria -- key elements that need to be delivered for the project to be successful. These criteria will then help guide you throughout the project. Of course, if it's obvious from your initial discussions that the success criteria aren't clearly linked to the business purpose of the project, again, you've uncovered a potential stumbling block very early, before too much energy has been invested in the project.

The Process of Initiating

The process of project initiation is quite simple. Gather information about:

• why the project is happening
• what needs to be delivered and how this will be done
• who will be involved
• the timings to which the project will be delivered

Make sure to get input from all the key stakeholders:

• Summarize the why, what, how, who, and when of the project into a Project Initiation Document.
• Review the Project Initiation Document with the project board and key stakeholders to get their agreement.
• Hold a kickoff meeting to herald the start of the project, share the success criteria, and plan going forward with the project team, board members, and key stakeholders.

There may well be a number of unfamiliar terms in that process explanation, but don't worry about that just now. We're about to look at the different tools and best practices that will help you get your project off to a flying start. The key point to take away from the initiating process is that you should start the project with everyone on the same page, and move forward towards a common, agreed goal.

Initiation Tools and Best Practices

The project's Initiation phase will be eased by the following key tools and practices.

The Project Initiation Document

The Project Initiation Document (PID) summarizes the what, how, when, and why of the project. It represents the agreement between all parties on what the project is about and, importantly, why the project is being undertaken. Although obviously some facets will change during the course of the project (notably the details of how the project is achieved, the project's timings, and the resources available) the fundamentals of what the project is and why it'll make a difference to the organization should be pretty stable.

The Project Initiation Document needs to summarize:

• the project's objective (what you're trying to achieve)
• the key deliverables (how you're going to achieve the objective)
• the overall rationale for the project (why you're undertaking it)
• the initial timings (when it will be achieved)
• the project's initial organization (who is involved)

Other elements that should be included in the initiation document are key assumptions and constraints, and success criteria. You may also want to include high-level information about the risk and quality management approaches you'll use, although this detail is often included in the project plan, rather than the PID.

It's important that the PID be as concise as possible. The shorter the PID, the greater are the chances that the stakeholders will actually read it at the outset, which can smooth the project's progress over time.

Once you've written your initiation document, don't just stick it on a shelf and forget about it! The document should be agreed upon up-front with your project's key stakeholders (including the project sponsor and board), and should be referred to subsequently throughout the project. Whenever you're making difficult decisions about which changes to the project's scope or design should be accepted, referring to the project's original objectives and success criteria will prove invaluable.

A PID Is Not a Contract!
The Project Initiation Document is not a legal contract. For a start, it's much shorter than any contract I've ever seen! The PID can't replace the contract, either. If you're a freelancer or a business providing services to a client, you still need to make sure that you have all your regular contracts in place. You probably want to refer to the PID in the contract, but since it's accepted that the actual execution of the project will likely diverge from the descriptions in the PID, you can't rely on it as you would a contract.

If you're employed by an organization, and providing project management services to another part of the same company, it will depend very much on the company culture whether or not you need to have a contract in place. Many companies don't have formal contracts for internal projects. In such cases, the PID serves an even more important role, since it's the only place where the expectations that the project team and customer have of each other are recorded.

Let's consider the project initiation document for our example project, which will address all four opportunities originally identified during the discovery phase.

The first section defines the business need -- it's simply a paragraph or two that describes the opportunity for the project, as Figure 2.2 shows.

Then comes the project objective, as shown in Figure 2.3. You'll notice that this part is written to a particular format that includes:

• an overall description of what the project's about
• a description of the key areas to be addressed
• a definition of the specific business benefit that the project will realize

This is a very useful format for describing objectives. You may find another standard in use in your organization, though, and it's often best to use the format that people are familiar and comfortable with.

SMAC Your Objectives
Your objectives should be SMAC: specific, measurable, actionable, and consistent. The key feature is that at the end of the project, you should be able to say "yes, we did that" or "no, we failed." There should be no gray areas. Throughout the project, you should be able to track the team's progress towards those objectives.

The next section of the PID identifies the project deliverables, as shown in Figure 2.4; it describes how you're going to achieve the objective. This description must necessarily be completed on a very high level, because the project is just getting started -- you haven't done any detailed planning yet. Here, you just need to give an idea of the biggest chunks of work to be done. Try to make sure that no deliverable will take longer than a month to complete, though -- if you're still looking at phases of three months or more, break those phases into a little more detail.

Next, we come to the project timeline. If the project is one that you're familiar with, you might already have a good idea of rough timelines for the various phases as well as the project overall. If you can, list the major deliverables against the week or month in which they'll be delivered (there's no fine detail here, of course -- you'd really only use a weekly breakdown if the project time was less than three months). In this case, the first two pieces of work are going to define the rest of the timeline, so we're only setting a deadline for these two phases, as Figure 2.5 shows.

Is it Feasible?
In some organizations, the initial analysis of the business processes and investigation of whether to buy or build a system might form what's known as a feasibility study or feasibility project. Rather than starting the full project with such uncertainty, a separate smaller project would be undertaken just to work out whether the main project is worth undertaking, and what would be required if it was.

The last part of the PID outlines the project organization. For this project, we've just pasted in the organization chart that we'd already prepared, as in Figure 2.6. Depending on how much the organization values role descriptions, you might want to put in more detail about what's expected of each individual.

Brief details of assumptions and constraints are often included in the Project Initiation Document. If the feasibility study had been split into a separate project, we would have listed all the assumptions we were making about buying the technical solution as compared to building one. However, since this project is starting with an investigation, these sections are not as important as they might be if we were going straight into the Executing phase.

The Kickoff Meeting

The kickoff meeting is more of a best practice than a tool. It's essentially a meeting at which you bring together the key players in the project to officially get the project started. Usually this will take at least a couple of hours, but you should judge an appropriate timeframe based on the complexity of your project.

The key attendees of the kickoff meeting are the project team and the interested stakeholders. The kickoff meeting is probably the first time that everyone involved will have come together for the project, so it's a great opportunity to get everyone enthused. Since you are (I hope!) working on a project that's important to the future of the organization, you might want to ask the sponsor to say a few words about why he or she thinks the project is important, and what will be achieved, before going into the main discussion points. A typical kickoff meeting agenda might look like this:

• welcome and introduction
• highlights from PID (with a particular focus on the "why" of the project)
• project approach (sharing some of the details of how the project will be managed)
• communication plan (so that everyone knows when they'll hear more)
• plan for moving forward (that is, what will happen in the immediate future)

The fifth point is the one likely to inspire the most debate. Hopefully, through the process of creating the project initiation document (PID), you've ensured that you've captured everyone's opinions about why the project should happen. Conversely, the project approach and communications plan are unlikely to be particularly controversial. But the plan for actually going and tackling the work can inspire rigorous debate!

This is why it's particularly important to have the key stakeholders in the meeting, as well as the team -- it would be a rare project on which you won't need their help and input during the actual project activities, so involving them in some of the initial planning work is a smart move.

Hand Out the PID
The real focus of the kickoff meeting is to get everyone aligned on the initiation of the project, so why not hand out a copy of the Project Initiation Document to every attendee? This will make sure everyone has the same information from which to form expectations of what the project will involve, and how it will work.

Seven Essential Steps for a Successful Initiation

Follow this advice, and you'll drastically increase your chances of running a successful project that makes a real difference!

1. Pick projects that are important to the organization and to its future.


2. Make sure that you have appropriate resources for your project -- whether those include people, equipment, or budget.


3. Include the people who are affected by, and interested in, your project in the project itself -- their inputs and opinions matter!


4. Set up a project board with the necessary members right at the beginning of the project, not just when the difficult decisions need to be made.


5. Create a Project Initiation Document and review it with the project team, board members, and key stakeholders.


6. Get your project started with a kickoff meeting, both to ensure the alignment of stakeholder expectations, and get everyone enthusiastic about the project!


7. Create a communications plan that outlines who needs to be kept informed about your project's progress, and how you're going to communicate with those people.

Summary

In this chapter, we firstly looked at the discovery phase -- how projects are identified and prioritized based on the business value they can deliver, and their relative importance to the future of the organization as a whole. We then considered a discovery tool and a best practice: project proposals and value creation, respectively. The former is a short summary of the project, which can be compared to other project proposals in order to evaluate its priority. Value creation is an important task because unless you know up-front what business benefits you are trying to deliver, you won't know whether or not the project has been successful when you complete it!

Next, we looked at all the people involved in the project, ranging from stakeholders (essentially anyone who's affected by the project) to the project board (which makes the really big decisions) and the project team (those that actually undertake the work). The key tools we discussed included the project organization chart and communication plan.

Finally -- and most importantly -- we looked at actually getting your project off the ground! The key tools we considered were the PID and kickoff meeting. The Project Initiation Document (PID) summarizes the what, why, how, who, and when of the project, so that you can share and agree on these details with the project's stakeholders. The kickoff meeting brings everyone involved together to start the project, helping the stakeholders feel engaged in the project, and demonstrating the commitment of the project board.

Later chapters of this book cover the Planning, Executing, and Controlling phases of the project management lifecycle, managing communication, collaboration, and change, and closing the project -- see the Table of Contents [3] for details, and don't forget to download this chapter in PDF format to read offline [4].

Create a PID for an Existing Project
Make sure that you familiarize yourself with the tools that we've been talking about. One really good way of coming to terms with these tools is to retrospectively create some of the documents for a project you're currently working on (or one that you've already completed). A great way to start is by creating a project proposal and a PID.

[1] http://www.sitepoint.com/books/project1/
[2] http://www.sitepoint.com/books/project1/
[3] http://www.sitepoint.com/books/project1/toc.php
[4] http://www.sitepoint.com/books/project1/