The Principles of Project Management

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.