Talk about your character-building experience -
 
I was a young hot-shot project manager on an engagement that I had sold to a client, I had it all planned out and had delusions of completely delighting my client with an issue-free project and it all seemed so simple, then the project started and never finished.
 
I'll spare you the gory details of my harrowing experience but what I can tell you is that I put more focus on selling and planning the project than I did on its execution.  I took a naive attitude of the project being able to pretty much run itself with some junior analysts running the day-to-day aspects of the work.  It blew up in my face and I got booted from the client never to return again.  It was my inaugural visit to the project management guillotine. 

Any project manager who has been around the block a few times has experienced a visit to the project management guillotine.  Perhaps it was with a sponsor, management, or a customer.  The project either had a massive schedule slip, cost overrun, or scope slash (or sometimes all three...now that's a party!)  and the project manager was first in line at the guillotine. 

Some of my most uncomfortable situations in my 20+ years as a professional have involved me getting my head handed to me on a silver platter because I bungled a project. 

Visiting the guillotine was very uncomfortable but at the same time was a great learning experience.  It taught me that I not only needed to be good at planning a project, I also needed to excel in its delivery.  It wasn't enough to be only peripherally involved in a project or to be its administrator.  I had to know what was happening, be on the lookout for problems, and squash the problems before they had a chance to spin out of control.  It taught me that I needed to avoid the guillotine by being able to execute.  It was that simple:  Execute or be executed.
 
Avoid a trip to the project management guillotine by keeping some of these simple tips in mind:

Break large projects down into mini projects that are three months in duration - I've rarely seen a project manager who is running a long-duration project raise a schedule issue early on in the project.  Most times, schedule issues get raised during the last third of the project.  Is that because the last third of the project is usually the most complex in nature?  Hardly. 

It typically means that the project manager either wasn't aware of earlier problems or just slipped tasks without raising any alarm bells that the overall project was slipping.  Break larger projects down to short-duration three month mini projects which have a clearly defined deliverable associated with the project's completion.  Running mini projects not only keep everyone on their toes with the completion date just around the corner but can be an fantastic motivator for project team members to git-er-done. 
 
Communicate the facts regularly - Regardless of whether the news is good or bad, the project manager absolutely has to establish and maintain a steady rhythm of communication about how the project is going.  I personally like doing a pointed weekly status which focuses on cost, schedule, risks and issues.  If there is good news to share, do it.  If there is bad news to share, do it and tell what you're doing about it.  Don't suppress communication waiting for a "Hail Mary" to save the project.  It likely won't happen.
 
Avoid "whine and cheese parties" when raising issues - Yes, issues are going to happen, and yes, some of them can cause your project to fail.  This isn't the time to show panic or to get on your soap box about how tough the project is.  As the project manager, your job is to raise the big issues, articulate what needs to happen to resolve the issues, put a name next to each issue for resolution, then hold those people accountable for resolution.  Keep a cool head and stay focused on resolution, don't use the platform as a means to say "I told you so."
 
Maximize the value of your trips back to the well - So okay, sometimes you can't keep it all together without revising either cost, schedule or scope.  When faced with the situation of having to go back to the sponsor (or the person writing the checks) I've found a couple of things to be very helpful: 

• Give the sponsor alternativewhich allow him or her to choose between relaxing scope, schedule, and/or cost.  Too many times I've seen project managers pre-assume what needs to happen and not present alternatives to the sponsor.  Allow the sponsor to be part of the decision making process.
• Minimize the number of times you have to go back to the well.  It is very frustrating for a sponsor to agree to a scope/schedule/cost variance in one month, only to have the project manager come back the next month looking for an additional variance.  Understand the implications of the variance and present reality to your sponsor.

Ask for help, don't abdicate responsibility or tough it out yourself - I learned this lesson very early on in my project management career.  As a young buck I saw it as a sign of weakness to ask someone for help if I got in trouble.  Asking for help meant I wasn't cut out for the job and management would view me as incompetent. 

Through the years I've refined my attitude about asking for help pretty significantly.  It's not about raising the flag any time the smallest issue crops up; it's about knowing what issues are within my domain to fix and knowing what issues can best be addressed by someone else.   There's not a good reason to try to tough it out yourself; ask for help when you're in trouble. 

On the other end of the spectrum is the PM who leaves the helm.  Rather than trying to fix a project problem, I've seen the project manager run for the exits or try to get assigned on another project to get out from under the mess.  As the PM you can't run for the exits; you've got to stay with the ship and work through the tough problems.  Just don't swing the pendulum too far the other way and forget to ask for help.

Lonnie Pacelli is an internationally recognized author and president of Consetta Group. Lonnie has 30 years of leadership experience as an executive, project manager, developer, tester, analyst, trainer, consultant, and business owner. During his 11 years at Accenture he gained leadership expertise consulting with many Fortune 500 companies including Motorola, Hughes Electronics, and Northrop-Grumman. Throughout his nine years at Microsoft he built his leadership expertise through development of some of Microsoft's internal systems and led their Corporate Procurement group, managed their Corporate Planning group, and led company-wide initiatives on Continuous Fiscal Improvement and Training Process Optimization.

www.projectmanagementadvisor.com