30 Project Management Tips That Work.

It's Official - The 30 project Management Tips Really Work!

You don't have to just take my word for it.

I am about to be quoted in an upcoming book with the following kind attribution:

"We would also like to thank the Digital Norseman, Preben Ormen for his useful Project Management advise sprinkled throughout these two chapters [on large project planning and management. PO note]."

The book is Maintenance Planning, Scheduling and Coordination, Industrial Press - forthcoming, by Joel Levitt, President Springfield Resources. www.maintrainer.com

OK, enough already, right? Here's what you really came for...

The proof of your project pudding is reaching your final project milestone; you're done! But before you get there you will have to travel a sometimes long and windy road. To make your travels easier, I have put together a list of practical project management tips. Of course, I can't guarantee that you won't have problems, but you can at least be well prepared.

This is the check list that I use for my own projects. The emphasis is on IT (information technology) projects like system selection and implementation. But you should be able to tweak the list for other projects as well. In the second section, you will find some comments and explanations about each item in the list.

The list: 30 Project Management Tips That Work

1. Justify the project by building a strong documented business case.
   
   
2. Understand the key business drivers of your business.
   
   
3. Get buy-in and support from top management; i.e., make sure to have a strong sponsor.
   
   
4. Be specific about requirements and state them in a way that makes it easy for vendors to respond and think along with you.
   
   
5. Avoid reliance on new, unproven technology.
   
   
6. Ensure the vendors can meet their commitments.
   
   
7. Ensure your organization can meet your own commitments.
   
   
8. Clearly communicate project team roles and responsibilities.
   
   
9. Give the team the budget, tools and space they need to get the work done.
   
   
10. Send designated key users or team members for training as soon as possible.
    
    
11. Develop a formal project plan.
    
    
12. Require the project team to provide the task estimates in order to ensure buy-in to the plan.
    
    
13. Let the plan be driven by specifically defined deliverables which in turn should drive the activities and tasks.
    
    
14. Be objective and realistic when making estimates and setting time targets.
    
    
15. Limit task duration to about two weeks (or 80 hours) or define an interim deliverable.
    
    
16. Do a risk assessment and develop a contingency plan with mitigating actions.
    
    
17. Provide skilled project management resources for the project team.
    
    
18. Stay with the plan.
    
    
19. Have regular and formal project team meetings with agendas and minutes distributed to the team.
    
    
20. Track and report progress by the deliverables identified in the plan.
    
    
21. Keep a formal issue log for all the practical issues that crop up and which were not included in the plan.
    
    
22. Meet regularly with your sponsor.
    
    
23. Require a formal change procedure to change scope and get sign-off by sponsor.
    
    
24. Adjust remaining duration and cost estimates when scope changes are approved or when you must accept a delay.
    
    
25. Have the users do all testing where possible.
    
    
26. Define what it means to be done; i.e., for milestones, project phases or stages and for going live.
    
    
27. Watch for signs of burnout and be prepared for turnover of team members (including vendor personnel).
    
    
28. Start data conversion as early as possible with a representative data dump from the old system for checking of data quality.
    
    
29. Build a project culture based on mission oriented directives where team members take responsibility for assigned deliverables, but figure out how to do it on their own.
    
    
30. Micro manage incidental or temporary project resources because these people seldom really become part of the team.

The 30 tips explained

1. Justify the project by building a strong, documented business case.

2. Understand the key business drivers of your business.

An alternative way to think about this is critical success factors; those things you must be good at in order to succeed and reach your stated goals. If you want to be rigorous in your analysis, you can build an analytical model and even do a simulation.

Don't overlook that half a dozen engaged people and a white board will often get you there plenty fast enough with minimal fuzz and bother. Back to list

3. Get buy-in and support from top management; i.e., make sure to have a strong sponsor.

The key is the scope of your project. With a narrow scope within a restricted area of the organization, you can be successful by staying focused and barging ahead. With a broader scope that crosses functional organization lines, you will probably not make it unless you have a strong sponsor to help stamp out the turf wars you will run into.

Still, the sponsor can only open the door. You will have the pleasure of getting the whole team through it! Back to list

4. Be specific about requirements and state them in a way that makes it easy for vendors to respond and think along with you.

There are two basic ways to go about this. One is to list every piece of functionality or feature you can think of that you might possibly need and make a giant check list. In the end, comparing responses becomes very tedious.

More importantly, you run a very good risk of picking a solution with a high overall score on a ton of features while actually not supporting your business very well. Not unless you come up with a dynamite weighting and prioritizing scheme.

Here's the rub: Without a sensible weighting scheme, you'll score trivia and show stoppers the same. Not a good idea.

Guess what, I favour the other solution. Drop the shopping list approach altogether and concentrate on your key business drivers and how you need to support them. Step through all critical business processes and jot down in bullet point form what you must have covered by your new system.

You don't have to verify that today's accounting systems can do debits and credits or tell you if your trial balance doesn't balance. But if your business is import and export, you better not forget to probe into how you get support for multi currency. Or if you do process manufacturing, you need to get this out in the open so that you can steer clear of those systems which primarily do discrete manufacturing. You get the drift... Back to list

5. Avoid reliance on new, unproven technology.

There is a time and place for being cutting edge. Unless you have deep pockets and is impervious to stress and stomach ulcers, stay with something more main stream and time proven. I trotted this one out in a presentation to a high tech company which drew a few chuckles and sideward glances.

I stood my ground though, because you may understand your own particular area of high tech, but that doesn't necessarily help you in managing new and unfamiliar technology in other areas of your business.

Think about it. Unless cutting (or bleeding) edge technology gives you a clear strategic or otherwise competitive advantage, why take the risk? Back to list

6. Ensure the vendors can meet their commitments.

There are two sides to this. First, make sure that the vendors have the resources to serve you once the project gets underway. Realize that implementation resources can dry up quickly. All it takes is for the vendor to have a string of proposal wins and he is caught short (and so are you).

Secondly, be a good customer and be sober in the demands you make when negotiating deadlines, milestones and budgets. Squeezing out a contingency buffer may look efficient on paper, but compression of project time lines is more black magic than science. Unless you are the grand wizard yourself, you run a very high risk of making a serious mistake.

A vendor will typically stretch his optimism to great lengths to make a sale. So do you really think you can cut the time line further without giving up something in return? Not likely. Back to list

7. Ensure your organization can meet your own commitments.

Time and time again projects are launched with tight deadlines, but without freeing up the project members from their everyday responsibilities. Business must go on, yes. Your people may be very talented, yes. But even elastics have limits. Back to list

8. Clearly communicate project team roles and responsibilities.

People will take responsibility only if they understand what their roles are and what is expected of them. Spell it all out and save yourself some grief. It doesn't take long to do and is time well spent.

I can pretty much guarantee that you will learn something from the exercise that will be valuable to your project. Back to list

9. Give the team the budget, tools and space they need to get the work done.

You cannot build a house without at least the basic carpentry tools. The job goes even faster if you get some power tools. Same thing with most other projects, although I'll admit it isn't always obvious to everyone what the "power tools" might be or how to use them.

I can virtually guarantee that you will have repeated needs for at least one resource skilled in the use of a data manipulation and analysis tool like MS-Access, FileMaker or some such product.

Tools are one thing. What about space? Does your team have phones, work stations, office space, meeting rooms, email and internet access, one or more dedicated printers and what have you? The way things are going, everyone needs access to email. What about outside project resources?

They will need access to your network (could be a giant hassle) or at least a couple of modem lines. What with most phone systems going digital, analog modem lines are not always easy to get in place.

If you think you will be running projects on a regular basis, get going on building a project office and develop some in-house resources and infrastructure. Back to list

10. Send designated key users or team members for training as soon as possible.

Training is almost always under-appreciated and started too late. The key here is to understand clearly the capabilities and skill sets of the team members and the ultimate end users as well as the support staff.

Most implementation projects go through a design or configuration stage (call it what you will) where you drive out the detailed requirements you need to cover in the new system. Never mind your original requirements document. This is where all the stuff you didn't specify up front comes out and faces the harsh light of reality.

I can almost certainly guarantee that your configuration process will be faster and more accurate if you can get a few key or "super-users" to some training at the absolute earliest time possible. In every project I have been involved with, the same comments have always been made several times over: "If only we had a chance to learn the software before we got so far into the project..."

I am beginning to think it some sort of natural law that training will only be available past the point of peak effectiveness. Well, one can hope. Back to list

11. Develop a formal project plan.

Read it again, this rule is for you too. Develop a formal project plan. Be specific. You don't have to take forever and a day. If you bring in the right resources - read experienced implementers - you can knock off a high level activity plan with decent consistency and internal logic very quickly.

Getting the details like actual deliverables and the resource allocations right will chew up some time afterwards, of course.

An experienced project manager's first estimate of project duration is by and large the most accurate one. Hunt around in the literature and you will find that no matter what logic is applied to compress the initial estimate, the project ends up close to the original delivery date. Except now it carries the stigma of being late.

By first estimate I do not mean first draft. You have to cycle the beast a couple of times before you have your best estimate. The trouble starts when various stakeholders begin arguing this way and that, make noises about being realistic and try to save money by applying questionable logic and pressure in the hope that "decisiveness" can get results.

Bullying will not shorten a project time line. To shorten even just a half decent plan means you have to give something up. Period. Back to list

12. Require the project team to provide the task estimates in order to ensure buy-in to the plan.

Here's a golden rule for planning: if you make the plan, it's your plan. You get the whole burden of communicating all the assumptions and hidden thinking embedded in the plan to each of the project resources. you'll be explaining and explaining and it'll still be your plan.

If you get people to develop their own activity plans within some overall limits, you'll get a different plan that is minimum one order of magnitude better that you could do. Why? Because if you have 10 resources planning you get the brain power and experience of 10 local domain experts pulling for you.

They will think of things that you would only discover as you run right into them well into the project. And you'd get the old "I could have told you so" story. Since they made the plan, they can't turn on you later and blame the plan, i.e., your plan. Back to list

13. Let the plan be driven by specifically defined deliverables which in turn drive the activities and tasks.

Planning is a mystery to most of us at first. How can you make a detailed project plan for a 9-12-18-24 month project when there are so many things we don't know at the start of the project? Well relax, you can't. Nobody can and the pro's don't even try. Obviously, something gives here.

The trick is to break up the plan into manageable chunks.

• Do it top down with a high level division into phases of no more than 3-4 month duration.
• Break out the main activities and milestones per phase.
• Grab the first phase and list all the key deliverables you must produce.
• Identify the activities that will produce the deliverables.
• Identify the interrelationships between your activities (e.g., what must happen before something else can happen).
• Finally, assign project resources. Then you farm out the next level of detail planning to the project resources.

14. Be objective and realistic when making estimates and setting time targets.

Most people find it difficult to come forward with hard estimates at first, but after a while they loosen up. You must stress the need for honesty. If you get estimates that are trying to second guess what you want to hear, sooner or later the whole thing will blow up in your face.

So watch what expectations you foster in your communications with management and with your team in the planning phase. Back to list

15. Limit task duration to about two weeks (or 80 hours) or define an interim deliverable.

We are getting very grass roots and detail oriented here, but this is important. After you have done your plan, you need to follow it up. That's why you need short intervals between deliverables.

Otherwise you risk being unaware of a snowballing problem with sneaking slippages that don't become evident until too much time has gone by for you to do anything constructive to get things back on rails again.

This is also known as "boiling the frog".

The story goes that if you put a frog into boiling water, it will jump right out. However, if you put the frog in cold water and slowly raise the temperature, it will not catch on until it's too late and you end up with a boiled frog. So, some problems hit you square on and are easy to spot. Others creep up on you, so watch out.

In my experience, you can control even fair sized projects by tracking progress on intelligently defined deliverables. The short time frame between deliverables keeps the temperature down, so to speak. Back to list

16. Do a risk assessment and develop a contingency plan with mitigating actions.

Many projects fail to appropriately address risk management. It is actually not that hard to do. You need to identify clearly what things can go wrong and critically affect your project progress. Then you must specify what mitigating actions you can take and put together your contingency plan.

Some risks will never go away while others will disappear after you have cleared certain hurdles.

By the way, it's perfectly alright not to have a mitigating action for every risk. You aren't superman and some things you just have to live with. But you must at least monitor these risks because it is your duty to report on changes in the risk status to your sponsor, steering committee or whoever you report to. Back to list

17. Provide skilled project management resources for the project team.

This must be tempered by the size of the project, but you need someone in charge who knows what is going on and can move the project along. There is a formal side to running projects which becomes more important as project size increases.

In my experience, a skilled project manager will get your project moving faster and will be especially valuable if your organization does not have a lot of project experience.

After the first 4-6 months, the team will be over the worst part of the learning curve. They will be much more self motivated and better capable of working independently with mission oriented directives. Back to list

18. Stay with the plan.

Sounds silly, but heed it. You'd be surprised how quickly plans are forgotten. In military circles they like to say that no plan ever survived first contact with the enemy. Well, it's true.

I like to say that projects live three lives:

• the one you hope for
• the one you plan for and
• the one you get.

If you don't have a plan, chances are you won't have a good fall back position for dealing with the unplanned events that real life serves up. So, just because you ran into a problem that doesn't mean you have to abandon the plan.

As your project progresses out of the first 2-3-4 month detail plan phase you may see some slippage here and there and your slack is beginning to be eaten up.

Unless you take the time to hunker down for the detail planning for the next 2-3-4 month stretch, your risk of plan and project disintegration will increase rapidly.

As a matter of fact, the second detail plan sequence is probably more important than the first. By the second stage, you know what the project conditions are really like and you must reconcile the high level initial plan with whatever slippage you have.

Your second project stage is probably the first time you can assess the likelihood of keeping to the remaining milestones and determine what further resources you will need to bring your project in on schedule. Back to list

19. Have regular and formal project team meetings with agendas and minutes distributed to the team.

A common perception I encounter is that we all have too many meetings to go to and not enough time left over to do the "real" work. The assumption being that efficient people don't waste time on meetings and so on. Well, I beg to differ.

The real work is to run the project and go live on time, on quality and on budget. To do that you must have communication and for this you can't get around meetings.

Some meetings are a terrific waste of time, sure. But if we can run our own meetings, we should be able to make them useful, right?

The good meetings:

• have agendas understood by everyone,
• start and end on time,
• report on deliverables and progress,
• assign tasks and responsibilities,
• publish brief minutes and
• bring issues forward from one meeting to the next until they are resolved.

Project status meetings are both communication and control devices. This is the forum where people keep up on what others are doing. This is where you build the cornerstones of your project culture and set the tone for your people.

If your team is at the front end of the project learning curve, these meetings are essential, but keep them short. Try to keep them to an hour, maximum ninety minutes.

It is better to have two short meetings per week rather than one long one. Sometimes a quick 5-10-15 minutes stand-up meeting is all you need.

I have used tele-conferencing with video, phone or both. Video is great, but phones are easier, more readily available and does 90% of what you need. Keep it simple and reliable. Back to list

20. Track and report progress by the deliverables identified in the plan.

Progress tracking is not that hard as long as you have identified concrete and meaningful deliverables and hold people to them. You don't have to rely on Gantt charts which most people find difficult to understand anyway.

Run up a list of deliverables for a two week period and roll it forward every week.

That's your basic check list for the project status meeting right there, and you'll know with pretty good confidence how you are doing according to your plan at all times. Back to list

21. Keep a formal issue log for all the practical issues that crop up and which were not included in the plan.

Your project plan will be full of activities, tasks, milestones and deliverables. All the really important stuff you have to do that you could think of.

Fine. But you know and I know, that there are a ton of things that never made it into the plan. That's why so many people feel uncomfortable with plans - they (the plans) seem to be missing so much.

And what do you do with all the stuff you have to deal with that isn't in the plan? All the questions that come up, all the practical everyday decisions you and your team must make and so on?

Most of these practical and time consuming details are not in the plan, yet they sure can cause you grief and make you late. So what gives? My answer is a little attitude, a little structure and a little discipline.

Don't get floored by the fact that you will run into problems, who said you wouldn't? All this practical stuff that comes up is what I call issues and they need to be dealt with.

The danger is that unless you track important issues, who they were assigned to, how and when they got resolved and so on, you run a very real risk of a snowballing heap of loose ends that can cripple your progress and derail your project completely.

The tool to use is the issue log. Identify the issues and assignments of responsibility in your project status meetings and transfer the items to an issue log. If you can put this log on a server for access by the whole team, great. Now you don't have to be the administrator and spend the time updating it.

At first it may seem like a lot of work, but after a while the team will see the use of it and will begin treating it as tool: what's in the log gets attention and helps you out.

Mind you, if you don't police the log, it can become a garbage can where people dump their problems onto others. Back to list

22. Meet regularly with your sponsor.

Keep the boss, the sponsor and the stakeholders informed. If you have a steering committee, run regular and formal meetings with an agenda and publish minutes.

These meetings should be to inform, to foster understanding of where the project is at and to get certain decisions and sign-offs you need. This is not usually the time and place to solve problems. Keep it short and sweet if you can.

Sometimes you need longer meetings. A steering committee typically has a lot of heavy weight management people on board and getting them to stand still at the same time can be difficult. If you need these people to discuss, e.g., policy issues for decisions right there and then, you may have to budget more time for the meetings.

Don't waste a golden opportunity to get the right people to air their concerns, listen to your message and decide! Back to list

23. Require a formal change procedure to change scope and get sign-off by sponsor.

Your worst enemy is scope creep. The learning curve works for you and it works against you. It works for you because people start to function as a team. It works against you because as people learn about the functionality of the system you are putting in, they get ideas.

And they generate questions and suggestions for improvements and changes that they didn't think of in the requirements definition and scoping phase. Don't laugh, it will happen to you, too.

It is also true that life goes on outside of the project, business conditions change, people leave, others arrive and the organization has to deal with this. It can't be ignored and won't go away. You may have to accept changes, but formalize the process.

Make it clear what is out of scope and the consequences to the project time line, budget or whatever if the proposed changes have to be made. Start using change orders right from the start.

You are especially vulnerable if you take a slippage. You will hear things like: "While we are doing this thing A, it would be silly not to do this other thing B, too."

Fight back. Every change you make introduces the possibilities of further errors and new problems which will consume time and resources to resolve.

You have to work towards keeping a defined and contained scope so that it is clear what you will be delivering.

If you fall into the accommodating pattern of indiscriminately agreeing to changes, you will be doing yourself and your sponsor a disservice. You will also be late. Back to list

24. Adjust remaining duration and cost estimates when scope changes are approved or when you must accept a delay.

Some changes are unavoidable and you must incorporate the consequences in your project plan. Most of the leg work will already be done by the time your change order is approved. Make sure you carry any new deliverables into your list for your project status meetings.

It is important to realize that every delay pushes the remaining stages of the project forward. You will seldom have a plausible reason to assume that you can make up for lost time later in the project. The future stages have their own set of risks and unknowns which will affect you one way or the other.

Just because you had problems early, doesn't mean that the probabilities for later problems have changed for the better. Back to list

25. Have the users do all testing where possible.

The ultimate judge of your project's success is the end user. Don't kid yourself. If the users say you got them a turkey, your goose is cooked. The users typically will know everything there is to know about their jobs except maybe how to improve them. Your project was supposed to help with that last part.

If you bring the users in to the testing phase you increase the likelihood that the right things will get done and that the users will buy into the solution.

Look out, though. If the users were not part of the requirements phase, they can still cop out - perhaps legitimately - and criticize you to death. Back to list

26. Define what it means to be done; i.e., for milestones, project phases or stages and for going live.

A frequent source of nasty surprises is the discovery that what one person thought was a completed tasks someone else finds inadequate and unacceptable. You need to make sure that the team members understand what they are responsible for and what it takes to get a sign-off on a deliverable.

You do that by getting the team to plan their own tasks and agree specific deliverables. Back to list

27. Watch for signs of burnout and be prepared for turnover of team members (including vendor personnel).

People deal with stress differently and you have to be alert for signs of burn-out. You must take these signs seriously because your project will be affected one way or the other.

So take the bull by the horns. Also, don't be surprised by people leaving, being promoted or just plain checking out. Make sure you have a contingency for critical project resources. Back to list

28. Start data conversion as early as possible with a representative data dump from the old system for checking of data quality.

Here's my experience: the data is never ever as clean as promised, the interfaces (a.k.a. feeds) are never as simple to code as expected and you will never really know what you need to bring over until you are well into the project.

Therefore, get yourself a data dump or two as soon as you can and start the cleaning efforts early. Do the math and estimate the time and resources required to get the job done. Back to list

29. Build a project culture based on mission oriented directives where team members take responsibility for assigned deliverables, but figure out how to do it on their own.

Unless you want to overload yourself with micro management of the project plan, you must get your team to take responsibility right from the start.

A great way to accomplish this is to give people mission oriented directives. This means to agree the goal or deliverable and give each team member any reasonable leeway to figure out how to go about the work.

And yes, I am aware that some times it is indeed necessary to crack the whip to get things done, but not as the order of the day. Back to list

30. Micro manage incidental or temporary project resources because these people seldom really become part of the team.

They may or may not read the project plan. They will certainly work to their own agendas because your tasks are to them "extra" or "nuisance" work and their priorities are driven by others, not by you. So, stay on top of them and make absolutely sure they understand what they are on the hook for and when you need it.

And be fair, these people do have other work and often don't have a say in what they get volunteered for. Obviously, the same goes for any other outside resources brought in on a short term or ad-hoc basis. Back to list

Bonus tip: Beware the hard pile.

This collection of imponderables is the "hard pile". Sometimes nothing comes to mind or the team member simply gives up, especially if they are beginning to burn out.

So the hard pile grows and things start to slip. Catch such tendencies early and ensure that no-one gets away with it. You need to make sure people feel comfortable bringing their problems forward and actively ask for help if they get stuck.

Get all problems out in the open, use the issue log to keep track of them and get your people the help they need to get the job done. Back to list

Post script

You will certainly be well prepared and should have increased your chances of avoiding some of the most common sources of project failure like poorly understood requirements, inadequate project planning, insufficient budgets, weak project management and no management support.

I think it is important to realize that IT system implementation projects are an inexact science at best. There is considerable scope for applying good project management "craftsmanship" and nothing really beats experience when it comes to figuring out what is really going on in the project.

And you only get that experience from doing it, from running live projects.

So have at it. And good luck.

Home | BCVSP | Coaching Voyage | Musings | Recreation | Runes | Sailing | Stories | Viking Ships | About this site | Contact me | Links