Project Management

Fast, Cheap, Good - choose any two.

What is a project?

A project is a work with a a defined start and end, which is undertaken to reach a specific goal. To make this possible, resources like manpower or investments are allotted to it. Time, Cost, and Quality are in equilibrium against each other. In some cases, one of them is critical and cannot be adapted, so the other two must yield.

Simple 5+1 phase model for projects

0 - Initiation

You got an idea for a project. Find out if it is a good one. Most projects start with a simple idea, and usually when you want the idea to become reality, you have to advertise it to get supporters. In the initial phase, that's what you do: talk to others, kick around ideas, try to find a sponsor, and do not give up. There are some business-school gimmick you can use here:

• Brainstorming: get together a bunch of people, state your problem, and collect all the suggested solutions however zany. Only afterwards you start to filter and evaluate the ideas.
  The basic idea of brainstorming is that two minds think better than one. And sometimes by combining different approaches, even better solutions are found, that never would have been discovered by one man with his limited creativity. It's like lateral thinking: search a bigger space of ideas. Of course, sometimes even a lot of Jon Does and superficial ideas will not be able to do what a single Einstein can.
• Metaplan: You can also break out ye olde metaplan kit to give brainstorming more structure: everybody writes his ideas on little cards, one per card, as fast as he can generate them. After five minutes everybody stops. All cards are collected, filtered for doubles and arranged on a wall chart into logical groups. Now you can assign ressources and deadlines to the cards.
• Forcefield analysis: Try to identify all forces that would push the project and all that inhibit it. Then develop a plan to do away with or weaken the inhibitory forces. (You can again use Brainstorming to find ideas for this plan.)
• Ask end users: Since they are the ones to use the result (and probably also pay for it), finding out what they want is a really good idea.
• Five times why: Ask times "Why should we do this?", answering with "So that", as so that points ahead. Use the answer to ask why again. If after five iterations you arrived at the mission/goals of your enterprise, you should be in good shape. I tried this to find the root cause for a problem, and it is surprisingly powerful.
• Cost benefit analysis: This you will have to do anyways to see if your project is worth to be started. Find out what benefits your project will bring and how much it'll cost. If it's still attractive in face of the costs, you can go on. The costs should always be expressed in money. Try to quantify the benefit. Methods used for this are "return on capital employed", or "discounted cash flows". It might be a good idea to get the people from accounting on board to do this.
• Strategic fit. The project has to fit to what the organization you are in is trying to achieve overall. There needs to be a business reason for it.

1 - Definition (Specification, Project Charter)

Define the goal you want to reach, acceptable costs and time for it. Identify stakeholders and assemble a team for your project. Write a definition document for your project that collects all the important information in an overview. Here's a simple example:

PROJECT DEFINITION
Name:	Revison:
Manager:	Sponsor:
Team:	Stakeholders:
	End Users:
Objective:	Benefits:
Time:
Costs:
Risks:
Escalation:

For a small project, an overview stating deadline, cost, objective, and who is involved may be enough. For bigger projects, you need to plan, with milestones, deliverables and so on.

2 - Planning

Plan the activities, who will do them, how long they will need - in more detail.
Make sure you have a clear specification of your goal, and the end users and sponsor understands and likes it. List milestones and deliverables, and steps that have to be done in a certain order. Here most of the project management tools like Gantt Charts and Dependency Graphs are used, and here project management software tries to help you do this. Be aware that these plans are just for orientation and to have a target to shoot for. Probably later on, they will have to be changed anyways. You again can use the metaplan procedure here:

1. generate the structured plans
   SPD (structured plan of deliverables) - use the metaplan procedure allowing substantives only. When ordering, try to use a hierarchical tree of main and subdeliverables.
   SPA (structured plan of activities) - use the metaplan procedure allowing verbs only. When ordering try to grouptasks in timeline order, or maybe first group by who will have to do what, then order for time.
2. dump irrelevant tasks - not all ideas might be neccessary, so filter out what you do not need.
3. assign ressources - assign people and costs
4. assign time - use man hours (or weeks, months), not time stretches on the calendar. Guessing the right time is a black art. For IT, think about what is realistic (not optimistic, think of all the little problems that pop up unforeseen all the time!), then double that.
5. find dependencies - some tasks have to be finished before others (logical dependency), some tasks need the same people and cannot be done concurrently (ressource dependency).
6. define checkpoints. milestones are checkpoints that mark achievement of important steps. They are usually obvious from the tasks and deliverables.

Most dependent tasks are end-start dependent: one has to be finished before the other.Planning software gives you the possiblity to make tasks start-start or end-end dependent, too. Once you have identified all your tasks and dependecies and put them into your favourite planning software, you can easily generate:

• Dependency net plans, for which you can calculate the critical path, that is the fastest possible path from start to end, and time buffers for non-critical concurrent steps. You can then try to play around and optimize that, by assigning more ressouces to critical activities. Put control points into your schedule for the critical tasks.
• Gantt charts, this is simply a table with one row per task, one column per time unit (days, weeks), were the from-to duration of each task is shown as a bar. This is very useful for the day-to-day work, because you can check your progress against the schedule on the calendar.
• Histograms, to plot time against scheduled ressources. You can see at what time you'd need more people than you have, and where you have slack.

You do not neccessarily need planning software. Caesar was pretty successful without it, and he was managing thousands of slodiers with bad communication channels. With email and some calendar software you have the basic needs covered. You also can use your spreadsheet software to create charts.

Finally, think about possible risks. Each of the parameters for the project can be a risk:

• People: do you have enough, are they well trained and informed?
• Technologies: is the technology mature, do you have know-how and experience for using it?
• Politics: Are there influential negative stakeholders? Is there agreement about the need for the project.
• Finances: Do you have control over the budget?
• Legal stuff: are you liable to someone if the project fails?

You can assign a severity and a probability from 1 to 10 to each risk, and think about those risks whose product is bigger than about 30. Of course the numbers you assign are pure guesswork. In any case, jot down the risks you fear most on the project plan. If you identify some risk, also decide how to handle it - you can avoid it by doing something different, shift it by hiring someone taking the risk for you, or use plan B.

3 - Implementation

Here all the real work is done. This is the Phase were communication and management are important.

4 - Handover

Hand over the result to the end users, which might have to be trained to use it, so there are additional costs and difficulties to make the whole thing successful. Throw a party.

+1 - Reflection

Think about what worked and what didn't, and why, so you can make it better next time.

Roles
The Sponsor
This is the guy who has the power to decide the project will be made and give the money.
The Manager
This is the guy who does the meta-work for the project: planning, communication, coordination, and lobbying. He assembles the team and has to motivate and support his team members. He defines roles and sets goals and milestones - if possible together with his team members, so they feel these are their goals. He checks if work is in plan. He informs the sponsor about the project status, defends the project and shields his people so they can work. If the team needs orientation, he has to set goals. If the team feels they know what to do, he has to let them work without disturbing them. Rule where neccessary, encourage to act on one's own initiative where possible.
The End-user
These are the people that have to use the finalized product. They are often hard to query, but their input is invaluable to do the right thing. To make them happy is success.
The Team
The team usually consist of an internal team, people from the same organisation that have been recruited or assigned to the project. It may also consist of an external team, hired external groups or technical specialists. These are the guys that do the actual work. Good teams = good projects. If the team can work well together, work is fun and results are good.
The Stakeholders
These are all people that do not belong to one of the above groups, and are for some reason affected by or interested in the project. They can be friendly, indifferent or hostile, and some of them will have power to affect the project. For example, an old rival of the sponsor could be an enemy. It is the job of the manager to identify stakeholders, keep friends informed and happy and assure enemies will not destroy it.

References

Professionelles Projektmanagement The source for most of the material presented here.
Der Termin A book on what I believe management really is about.

I trained as a professional project manager after writing this. I think it is good in stressing importance of stakeholders, but obviously there is more to project management than what is listed here.