Yesterday, you were the prominent Production Control Supervisor looking forward to having a new Enterprise Management System.

Today, because you do such a good job, they made you the Project Manager responsible for its company-wide implementation. The fact that you’ve had no formal Project Management training or experience wasn’t even considered to be a factor.

The euphoria of being given such an important role has now passed. You’ve never ran a project that impacted the whole company before and, to say the least, you’re more than a little nervous.

If this scenario sounds familiar, or at least interesting, read on …

Fortunately, you’ve been directed to The Project Manager’s Tool Bag web site and are now at least armed with all the basic PM templates that you need for the project. You have also read through the Sample Project page and are familiar with how the various templates can be used and their value to controlling the project. You now have the tools you need to provide the hard framework for the project.

The problem is you’re not entirely sure of how to get going and what to do next. This is the nebulous side of the PM’s job. It is somewhat hard to describe and there seems to be no end to the considerations. What you lack is PM Street Smarts - a colloquial term referring to knowledge not obtained through higher learning or formal education but instead by practical life experience, in this case, project management.

The purpose of this section of the web site is to provide you with some basic pointers on running a project. These pointers are mostly ‘sound bites’ taken from my extensive experience in obtaining my own PM street smarts while running many different projects over the years.

So, here we go - a collection of thoughts to keep in mind while running your project …

Three Basic Laws that apply to all projects:

Parkinson’s Law: “Work expands to fill the time available”

Implication – keep this in mind when reviewing project plan activity due dates.

Peter’s Principle: “People rise to the level of their incompetence”

Implication – monitor the individual team member’s performance closely at the start of the project. A line manager just may find that your new project is a convenient spot to place a problematic employee. (people don’t really do that, do they?)

Murphy’s Law: “Whatever can go wrong will go wrong”

Implication – expect something to go wrong just about every day, and then you’ll be less surprised and perhaps better prepared.

Some Murphy classics are:

§         Nothing is ever as simple as it first seems.

§         Everything you decide to do costs more than first estimated.

§         Every activity takes more time than you have.

§         It's easier to make a commitment than to get out of it.

§         Whatever you set out to do, something else must be done first.

§         If you improve or tinker with something long enough, eventually it will break.

§         By making something absolutely clear, somebody will be confused.

Random thoughts:

Spend as much or more time planning the work than actually working the plan. Complete the Project Charter and initial project plan Gantt chart before doing anything else.

All engineering development estimates will be understated – plan accordingly, but hold their feet to the schedule fire anyway.

Be aware of my 90/10 rule of software development. Developers don’t know about it, or will likely never admit it. When developers are 90% done they have almost no interest left. Their initial excitement has long gone since the challenge to build the super slick underlying program code has been accomplished. The problem is the user community sees 100% of the incomplete 10%, the visible screen stuff with all of its glaring errors, not the rocket science that went into the underlying code development.
Implications – a user community who’s trust you have lost and need to gain back.

Plan a seemingly absurd amount of time for final testing of the completed product. This testing happens at the tail end of the project, and by then you will have used up all spare time available, trust me. You will be under pressure to deliver the product – and then you will be smacked head on by the 90/10 rule.

Don’t be pushed into accepting unrealistic deliverable dates. There’s only one Y2K event that’s going to happen in our lifetime, and it’s already passed. A quality product delivered a few weeks later, is much better than a poor product delivered earlier. The extra few weeks that seemed so important at the time are soon long forgotten with a good quality product.

You can document the client’s expectations, but you can’t stop them from expecting things.

The project charter is a living document, it stops changing with the final project sign off signatures. Be prepared to make required changes and ensure all related documents and plans are updated accordingly.

Build in project "reviews", performed by independent persons, to make sure things are on track. Minimize use of the “audit” word if you can – it has too negative a feeling about it.

Find an experienced PM to be your mentor, to be available at key project phases, for plan reviews, and a call away for consultation.

Every project needs a big hammer. Y2K projects were easy in this regard - everyone knew you couldn't change or avoid the clock! The need to be successful should always be made very visible.

Have a meaningful slogan or catchphrase.  For example, “plan the work, work the plan”, is more than a slogan, it’s a way of project life. Planning the work takes as long as or longer than working the plan – if done right.

Maintain your regular status meetings, come hell or high water. Keep them on track, crisp, and to the point. Cut off discussions that aren’t relevant. Stick to the published agenda and timing and publish the minutes and action items immediately following the meeting.

Always keep the end state in mind throughout all project related conversations. Don’t get derailed along the way.

It’s a fair statement that good project management is all about sound risk management.

People often assume the worst when they don’t know what’s going on. Communicate effectively by creating and following a formal project communications plan.

It’s not just about the deliverables and due dates. It’s real people that make these things happen. Have regular team events designed to boost morale, and make sure to celebrate the successes.

Don’t be in everyone’s face, but always be available.

Practise MBWA - Management By Walking Around. The project doesn't run in your office, it's out there amongst the project teams and user groups.

Delegate, delegate, delegate.  The PM cannot be involved with every day to day issue or decision. Keep your focus on the big picture and trust your team leads to do their jobs. But, know the difference between delegation and abdication!  Your regular project meetings and status reports should be designed to maintain visibility of project progress and problems.

If you are personally working 12+ hours a day, six or seven days a week, there’s something dreadfully wrong with your project.

There are times to make things happen and times to let things happen. When a major deliverable is due, stick with it like glue to a blanket. When an activity is due in support of a major deliverable, let your team lead stick to that one all night and report status to you.

Focus on the business issues that are to be solved, not the technology to be used.

Major tough decisions will need to be made – make them in a timely manner before the desired project end state is negatively impacted.

People will always have an excuse for not being there or missing a deliverable – don’t accept it. Have them find a way to make it up.

Don’t let a bad apple ruin the whole basket. Quickly replace people who do not contribute, fit in, have the needed skills, support the team, etc. Failure to do so will definitely put the project, and you, in jeopardy.

The PMs who consistently deliver results are rarely loved by everyone. Tough love is not a bad thing. It’s just a project with definite start, middle and end points – not a marriage.

And, attend the project sponsor’s golf tournament – even if you hate, or can’t golf 

Questions to think about, or ask some team member, every project day:

• How do we know when we’re finished?

• Why are you here today?

• Do you know why we are doing this project?

• What are the main things to be accomplished this week?

• How are we tracking to schedule?

• Can you describe the overall project organization?

• Do you know what happens if this project fails?

• Does the entire organization know what’s going on and how it will impact them?

• How well would the project survive an audit tomorrow?

• Are we doing enough to keep the team happy?