Turning Around Failing Projects (Excerpt)

A couple of people have asked me about my Turning Around Failing Projects speeches.  Here is a small excerpt from my book Project Management That Works (a best seller published by AMACOM in 2008)

The statistics are staggering.  The propensity for project failure is enormous.  The general accepted failure rates range from as low as 59% to an unbelievable 94% of projects failing to meet their goals.  When studying project failure, the survey questions try to determine if the project met the desired scope, timeframe, or met all of the requirements that the project set out to complete.  However, these all take on new meanings when you consider something Rob Thomsett says in his book Radical Project Management:

"Projects fail because of context, not because of content"

If this statement is correct, then a large part, if not the entire 59% to 94%, of projects failed because of the improper setting of expectations.  They may have delivered the contents of the project but failed to deliver on the expectations of time and cost.  This drastically changes the landscape of the meaning of project failure.  Now, pair Rob's definition with PMI's belief that a poor project schedule or inadequate budget is the direct result of poor project management, and project failure rests on project manager's shoulders.

It is usually assumed that a project is being run in the first place by a trained project manager.  However, most of the time, someone is managing a project along with their other duties.   

How to Spot a Project that Is on Its Way Down

The first task in turning around a failing project is to learn how to recognize when a project is failing.  In many cases, you need to start with the first step of the classic twelve step process with the first step being identifying that there is a problem.  Although there are many reasons that projects may fail, there are some key indicators that projects are on the way down:

1)      Poor project planning or no plan at all. It has been said that a failure to plan is a plan for failure.  If you do not prepare for problems, they will surely derail you and your project.

2)      Disagreement on project requirements. A lack of good documentation of requirements or receiving different answers from different team members about the goals of the project muddies the waters and makes it difficult for a project to succeed, since no one is really clear on what success means in this instance.

3)      Lack of team involvement. Sponsors, stakeholders, or team members are not involved in team activities or are not responding to inquiries about the project. When people are not involved in the project it has no real life.

4)      Lack of a clearly defined end. Have you ever had a project last a year and every time you ask how much longer will the project last, the answer is just another two to three weeks? Failing to set a clear end point means a project will never end and if it never ends, it can never truly succeed.

5)      Unrealistic Demands.  If I said I needed you to rebuild theEiffelTower from the ground up for $30 in three weeks with five seven-year-old children as laborers, you would laugh.  As ridiculous as this may sound, real demands as ridiculous as this have been set for projects. A project with demands that can never be met is sure to fail.

6)      Failure to stop or plan again. Anytime a new project manager is assigned to a project, one of the first things that they want to do is to stop the project and assess where they are in the plan or re-plan in lieu of having a written plan.  A team that responds by saying they are almost finished or they are too busy to plan is a clear sign of a project on the way down. Every team needs to be able to stop and rethink the project's plan.

These are all general theories and a search of the Internet will bring up many sites that have early warning signs, causes for failure, or theories as to why projects fail.  The funny thing is that project managers seem to make the same mistakes over and over.  The whole point of a project management process and profession is to continually improve.  However, the reasons for project failure still continue to remain the same.  Unfortunately, unless the way the projects are being planned or how the expectations are being set changes, the results of the project are unlikely to change.

Someone Isn't Being Heard

One common reason for project failure is that communication has fallen apart and someone is not being heard. Consider the following example.

A project manager was assigned to a support project that had no project management structure.  The project was consistently not meeting the customer's expectations and senior management wanted a plan to improve customer satisfaction.  The project manager started to investigate the root causes of the satisfaction issues.  She met with the team as a whole and then individually.  As she met with the team members, the issues were becoming quite clear.  The causes of the customer satisfaction issues had already been identified by the team and they attempted to put action plans in place to rectify the problems.  The project manager investigated the options that the team had put together and saw that they were quite viable.  She compiled the information into a presentation and scheduled a meeting with her senior management.  She outlined the options and asked for a decision from senior management as to which option they agreed with.  They chose an option and she implemented the plan.  There was an immediate improvement in the timeliness of customer service which in turn led to an improvement in customer satisfaction.  As the improvements continued for the next couple of weeks, senior management brought the project manager in to thank her for a job well done.  They asked how she came up with the options she presented.  "I didn't," she replied.  "The team developed the options.  All I did was examine them for viability and present them to you."  The senior management team was in disbelief.  They wondered why the team hadn't presented the options to them before this.  The project manager replied, "They may have not understood the best way to present the information to you or how to approach you with their ideas.  But it was their ideas all along."

There are many reasons why the team may not have been able to communicate their options to the management in this example. Teams can develop behaviors based on small insignificant events.  At one point, a senior manager could have said "no" too abruptly and demoralized a team member.  That team member then begins to have the attitude that senior management doesn't care or will not listen to them.  A few episodes of that and groupthink can set in.

According to www.dictionary.com, groupthink is defined as:

The act or practice of reasoning or decision-making by a group, especially when characterized by uncritical acceptance or conformity to prevailing points of view.

 

or

decision making by a group (especially in a manner that discourages creativity or individual responsibility).

 

For a very serious example, groupthink was the cause of the Challenger Space Shuttle disaster.  This is no small statement.  Groupthink was the ultimate cause of one of the worst space tragedies in our time.  When the analysis of the disaster was complete, it was determined that the O-rings of the rocket booster were the cause of the explosion.  An engineer at the company that manufactured the O-rings had warned senior management that when the weather drops below a certain temperature, the integrity of the O-rings is compromised.  The engineer asked for more time from senior management to be certain.  The panel that was formed to uncover the reasons for the Challenger disaster found some startling information.  Originally, the company that made the O-rings recommended that the Challenger should cancel the launch until the temperature rose above 53 degrees, which was not expected to occur for several days.  NASA has already cancelled the launch a few times and was under enormous political and societal pressure.  They applied pressure to the engineering company.  Fearing the loss of future revenue and backlash from causing another delay, the engineering company began to question it's own data and began to rationalize their decision.  The engineering company asked for five minutes to discuss the situation.  During the five minutes that the company was isolated enormous pressure was put on the engineer about his data and analysis.  The question for the company became whether to choose safety and possible loss of revenue or risk and future revenue.  Inevitably, the pressure to conform outweighed the right decision.  When the engineering company called NASA back, they recommended that the Challenger should launch.  The official findings of the panel stated that the technical malfunction was the O-rings, the cause the disaster was groupthink. 

When anyone in management stops listening to their team members, disaster can strike at any time.  When a project is failing, first look to the communication.  Over 90% of a project manager's job is to communicate.  Whether it is documentation, meetings, one-on-one conversation, or phone calls, all are forms of communications.  When you refer to the list of key indicators, communication is central part of all of the items.  When communications stop, people stop being heard.  When team members are not being heard, project failure is sure to follow.

So what do you recommend to open communication? How do we prevent these kinds of failures?

My Next Big Thing!

For my many followers and fans, we have exciting news.  We are getting very close to launching the next big endeavor for me.  Many of you responded to a request for an endorsement of my speaking and seminars.  I am now one of the most recommended people on LinkedIn.  You can view my profile here and if you haven't recommended me yet, I would appreciate your endorsement. 

Now to the subject at hand; I have finally found the question that I need to ask and to answer.  That question is, "What Do I Stand For?" Think about that question.  Think about your answer.  Do you know?  Do you know how to make the decision and fulfill your answer?  Follow this blog and watch in the coming months to find your answer!

There is a book, a kit to help out, and seminars all in development for this topic.  We are tying this together with many of the things that have been happening with me and R2 Consulting.  This is a huge step forward for me and my company and I am literally bursting at the seams with activity.

My blog posts in the coming weeks will be developing this topic further and starting to discuss the content for the series.  I thank all of you that read this column and continue to support me in my endeavors.  I can't wait for this next chapter to begin!

Rick

My Travel Pet Peeves!

When you travel as much as I do, you begin to see patterns and things that begin to rub you the wrong way.  Here are a few things that absolutely drive me crazy when I travel (in no particular order).

1)      Using your cell phone on speaker phone mode in the gate area.  Why do you people do that?  Do you think we care about the conversation?  I recently joined into one.  A lady was talking about how bad her man was treating her to a girlfriend.  It would be one thing if this was being done in a corner somewhere.  Instead, I was sitting in a chair in the gate and she sat down right next to me to have this conversation.  I assumed she wanted me to join in.  When I started answering questions, she gave me the dirtiest look.  I said, "Oh, I thought you wanted my help since you sat down next to me and are on speaker phone.  If this was private, I would have thought you wouldn't be broadcasting it to everyone in the gate."  She was not amused.  Some people can be oblivious to the world around them.

2)      Calling someone as soon as we land and speaking so loud that everyone on the plane can hear you.  I understand the need to call people and communicate from the plane.  However, be mindful of those around you.  On a recent flight, a lady called a shipper of goods to inquire where they were in the delivery process.  Evidently, they had tried to deliver and couldn't.  She began to scream at the top of her lungs how that driver will turn around and go back or she would have his job.  The tirade was nasty and loud.  A gentleman in the very front of the plane finally turned around and yelled, "Shut up, nobody cares!"  She then started telling the whole plane the situation…..and again…..nobody really cared.  She then yelled something that leads me to #3.

3)      Nobody cares who you are.  At least once every trip, I hear somebody exclaim, "Do you know who I am?"  There are many important people in the world.  However, when there is an inconvenience, there is always the person that thinks they are more important than everybody else.  One exchange recently was pretty funny to watch.  The plane was delayed by weather.  The gate agent was trying to handle everybody's connections and accommodate the entire plane.  A guy marches to the front of the line and steps in front of an older lady.  He then demands to know the reason for the delay.  The gate agent said the weather was unsafe to fly through.  He demanded answers as to when he would fly.  She was very polite to suggest that if he returned to his spot in line, she will deal with him when it is his turn.   He responded, "Do you know who I am?  I HAVE to be in Detroit tonight.  I have a very important business deal that must be done tomorrow."  The gate agent again requested that he return to his spot in line.  When the guy yelled that he would have the gate agent's job, another passenger stepped in.  "Nobody cares who you are.  Get in back of the line."  He then turned around and announced he was the Senior Vice President of some small company nobody had heard of.  The whole line just started cracking up.  It was pretty funny.  When a flight is delayed, everybody has a reason to be on that plane; else, they wouldn't have bought the ticket!  The "I am more important than everyone else" game is ridiculous.

4)      I demand to speak to the President of the airline!  When a flight is canceled or delayed, it is a pain.  It unfortunately isn't a rare occurrence.  I have been bumped, had flights cancel, had flights delay five hours and then cancel, and completely missed them.  Revenue for airlines is all based on people sitting on seats on an airplane.  Because people miss, cancel, and move flights, the airlines will overbook.  On some occasions, everybody will actually show up resulting in an oversold situation.  This is normally resolved by seeking volunteers to move their flights.  In rare occasions, a passenger is bumped.  It is a term and condition on every airline's ticket.  It can be frustrating when it happens, but it does.  When weather has occurred or someone has been involuntarily bumped, the outrage ensues.  I was on a plane recently from Birmingham to Atlanta.  The flight is normally between 25-35 minutes in length and is always scheduled for an hour.  Atlanta being one of the busiest airports in the world, the Birmingham flight is frequently placed on a ground hold due to incoming traffic in Atlanta.  Even with the delay, we are generally to our gate +/- 20 minutes.  One day during this delay, a guy announced he had enough.  He called customer service and demanded to speak to the President.  I have heard this many times.  Someone screaming, "Then get me to someone who can make a decision.  I want to speak to the CEO.  Get me the number!"  First, they will never give you that number.  Second, why are you more important that everyone else?

5)      Bringing food on the plane.  This one is probably more controversial.  I understand not having time to eat or being hungry.  However, the plane is so cramped and everyone is on top of each other that whatever you do bring on the plane, everyone can smell.  There is nothing like having the person in front of you eating Chinese food while the person next to you is eating Mexican food.  The blend of aromas is joyous.

6)      Not sharing the space.  I am a big dude.  I take up quite a bit of space, especially on little planes.  I tend to book window seats and try to sit an angle so that it is comfortable for the person sitting next to me.  However, I get angry when they are all in my space.  Not a care in the world.  Reading the newspaper and the paper being in my face.  Using the armrest in between us to store your drink because you have used your entire tray.  Be mindful of space!

In the end, travel can be stressful.  Even when it is as routine as it is for someone like me; it can still be a challenge.  I have several tips that I have developed over the years…..but that will be a subject of another post.  What are some of your pet peeves?

How to Complete a Project Audit

The great and oft-quoted philosopher Socrates once said, "The unexamined life is not worth living." A great project manager may tell you, "The unexamined project is not worth doing." In order for a project team to assess, refine and improve its process, that process must be comprehensively and critically evaluated. Toward that end, the project audit is an invaluable tool.

Project audits are conducted to discover and then examine any issues or challenges that arise as a team works to complete its assigned task. The practical application of this fact-finding is of course to learn from experience with the goal of improving future projects. But it isn't always about finding out what went wrong. Audits can also identify and celebrate innovations and process successes, ensuring that what went right is fleshed out and built upon so that it can go even more right the next time around.

When to conduct an audit: Project audits may be done during a project or at its completion. When conducted while a project is still in progress, an audit provides on-the-ground assessment that informs the project sponsor, project manager and team of what is going well and what needs to be changed in order for the project to be completed successfully, on-time and within budget. If an audit is undertaken at the completion of the project, it becomes more of a post-mortem examination performed to define success for upcoming projects and ensure it is achieved. Regardless of an audit's timing, the process is basically the same.

Who should conduct the audit: Ideally, project audits should be conducted by an outside party bringing impartiality and a fresh perspective, but whether you choose to outsource the audit or not, confidentiality is essential for data gathering. When project team members and other stakeholders are interviewed about their experiences, they should feel comfortable speaking frankly and not fear retribution for voicing any frustrations with the process. An audit is only as comprehensive as the information on which it is based.

A project audit is comprised of three phases:

1. Research Preparation (includes defining success and developing questionnaire)


2. Deep-Dive Research


3. Reporting Findings

Research Preparation, the first phase, actually consists of about three major tasks. First, the auditor must speak with both the project sponsor and the project manager individually to determine each person's success criteria. What do they think the successfully completed project will look like? And what should the successful audit accomplish and uncover? Being clear about client expectations is of utmost importance.

After these high-level interviews, two questionnaires must be developed. The first will be distributed to each person on the project team and any key stakeholders in advance of one-on-one interviews. Ideally, this questionnaire will get the audit's interview subjects thinking (and organizing their thoughts) about the project's successes, weaknesses, challenges and opportunities.

The second questionnaire is for use during the project team interviews and should consist of open-ended questions that work to flesh out the issues the first questionnaire brought to light. Good interviews aren't just SWOT analyses; they focus on process: How did the team work together? Were meetings run efficiently? How were risks mitigated? Did information flow effectively?

Deep-Dive Research: Now that you have developed your tools, it's time to put them to use collecting data. Project auditors will need to conduct individual interviews with the project sponsor, project manager, project team members and key stakeholders, which may include vendors, suppliers, contractors and even customer representation.

In addition to your interviews, an exhaustive review of all documentation pertaining to the project is the audit's other major source of data. This document review should include basic policy items like team structure, project scope and plan, and business requirements. But it will also require delving into daily, ongoing project documentation like meeting minutes, spreadsheets, milestone reports, action items and change logs.

Be sure to speak with both internal and external stakeholders to determine what their expectations were and whether they have been met. Were the Project Quality Management and Product Quality Management plans followed and achieved? Each person you interview and document you study provides an important piece of the overall puzzle.

Reporting Your Findings is the final phase of the audit. Compile all data collected from questionnaires, interviews and project documentation. Identify and explicate the project's successes, failures, concerns and challenges. The crucial conclusion of this in-depth report should be a list of lessons learned and how to implement them going forward.

The comprehensive report should of course be delivered with a companion presentation that highlights key findings in an easily-digestible, attention-grabbing format that energizes the entire project team for the work that lies ahead – a more cohesive effort that results in greater success on future projects.

Conclusion: The project audit is certainly a beneficial, and even cathartic, exercise for all project team members. It provides a mountain of data and insight into an organization's processes and politics. However, every phase of the audit must be focused on, and work in service to, improving the next project. The project audit is a very forward-facing tool. It is only worth the resources expended when the lessons it uncovers are applied to future projects. Only then can your project audit truly be considered a success.

This article was provided by Joe Schembri with Villanova University's project management courses. Professionals interested in earning their PMP certification can take courses to prepare themselves 100% online.

CA's Clarity Version 13 - A New Standard in PPM Tools!

I finally have gotten what I have wished for!  The power of Clarity with an updated user interface. Many superstitious people think that 13 is an unlucky number.  Version 13 for CA's Clarity has been worth the wait.

I run a technology agnostic company, but I am often asked for my opinion. I have been a longtime supporter of Clarity. However, the interface for the tool has become outdated and was the biggest outstanding issue. While configurations and portlets could overcome some of the issues, there were times where it was just cumbersome. Specifically, it was difficult for the project manager to see dependencies or update the project schedules.  It was also cumbersome to add team members and make assignments. Again, with experience, there were workarounds. However, newer tools like Daptiv and @task were smoking Clarity from a user interface perspective even though they lacked the depth and configurability of Clarity. With V13, it is truly a game changer. I have been able to spend some significant time on the latest version and already have several clients on the new version. The big push for CA was establishing what they called 2.2 clicks to value.  I believe they have achieved that.  Here is my first take at some of the game changers.

In line editing - Clarity has had an edit mode which was innovative when it first came out. Project management is a spreadsheet driven industry so being able to edit like a spreadsheet is a positive thing. The old interface allowed for edit mode, but it was not aesthetically pleasing and often hard to navigate. V13 allows direct in line editing with just a click of the mouse button. It is intuitive and effective. It so reverts back to a display mode when you are done. The part that I wasn't expecting was the visual feedback of the change. Clarity has a unique ability of Being able to complete tentative schedules with an innovative view of what had changed. For example, if a date changed, Clarity would display the new date and the old date with a red strikethrough side by side. They have taken this view and applied it to the in line editing which is a fantastic feature. It also gives a visual to the user that changes have not been saved. I wish more web based apps had this functionality.

Auto Suggest Functionality - For all of the browse fields in Clarity and for those users that have very deep OBS structures, you are going to love this functionality!  If the field is a browse field, you still can click the binoculars and search and add as you are used to.  However, you can also type in the first few letters of the value that you want in the field within the in line editing and the system will offer a filtered view of selections allowing you to select the value you want.  This eliminates many clicks and is the most powerful on resource and OBS fields. This feature is worth its weight in gold.

Better assignment view. The assignment view now combines the standard view with a time-scaled view to not only see the total planned work, but a daily view of how the work is going to be executed. This is like a split window view in Microsoft Project, but more configurable and can be edited in the normal flow of a project update.

Adding team members - One of the biggest issues of pre 13 Clarity was how the team members and assignments worked.  It made sense from a logistical standpoint, but for many project managers, it was a source of frustration.  If you were inside a task and wanted to make an assignment to a person that was not on the team, there were between 20-35 clicks that had to be made.  In an open environment, this is frustrating.  However, there are several environments with very strict regulations and procedures as to who and how people can be added to the team.  To accommodate both environments, CA implemented an "Assignment Pool" field.  On a project by project basis, the setting of Team Only (current functionality) or Resource Pool (new functionality) can be selected.  If it is Resource Pool, then the entire resource pool is available to assign to a task.  This eliminates 20-30 clicks from a test case that happens often.

Dependencies - Managing dependencies in Clarity has often been difficult.  You were unable to see them and editing them again was way too many clicks.  There was an easy way to add dependencies from the Work Breakdown Structure view, but there was no visual feedback that anything happened when you clicked the button and there was no visibility in that view that showed if dependencies existed or not.  Again, this has been addressed.  From the Gantt chart view, you are able to create, edit, and view dependencies right in the Gantt chart.  It also supports drag and drop.  It goes one step further than some other tools as well.  If you hover over the dependency link, the system will show you the actual names of the predecessors and successors.  Very nice addition.

No need to export to MSP - As a power user, I would often tell clients that it was easier for me to create a plan in Microsoft Project, upload it to Clarity, and then manage it in Clarity.  For the hardcore Microsoft Project users, this is still available.  However, for 95% of the users that I have personal experience with, there is no need to export to MSP.  The ease of use of the front end and the in line editing availability in the Gantt chart removes the need to do the export.

All of the power still retained - The main reasons I have always liked Clarity are still there. The configurability and power of the tool remains.  The user interface is what received the overhaul.  It is now completely 64 bit including Java and Tomcat and supports more memory to the Java heap.  All things that will mean a boost of performance for most environments.

Favorites Bar - Another great timesaver is taking a concept that was developed in some of the earlier versions of Clarity and expanding it.  I am not sure of the exact version, but in either 8.1 or 12.0, the user had the ability to set the home page to a different view.  If I am managing a project and I find myself always navigating to a certain page, then I could set that page as my home page so that it was the first page that opened when I logged in.  CA has taken this functionality and expanded it for a full Favorites section.  It works the same way except that I can create several "bookmarks" within the tool to allow me to navigate quickly between common screens.  This is a huge boost for productivity and saves a ton of clicks from the normal navigation of the tool.

One thing still missing - There was one feature that is still desperately needed.  I was hoping it would be in this version and I am told it is in the works.  We are still unable to print a project schedule from Clarity.  For those of you that have attended my seminars you know that I am against printing the project schedule anyway.  It's not like the resources really print it, read and understand it, and can't wait until the next version is released!  However, it is a reality that we still need to print the schedules.  I hope that functionality is around the corner.  In the meantime, there are some nice reports and you can still export the plan to Workbench or Project and use their printing functionalities. 

My Conclusion - V13 is absolutely worth the wait and there are so many upsides to the new release in forms of usability and functionality that my personal recommendation is to upgrade as soon as possible.  There will always be issues and things for software to add, but this is not a wait and see release.  This is an absolute add.  There are so many advantages to this release.  In fact, I don't think I have ever been as excited about a new release of software since Microsoft Project announced change highlighting and multiple undo to MSP in 2007!  Contact your CA representatives or hit the CA support site and download the latest version now.  You will not be disappointed!  If you have been on the fence about choosing a PPM tool, this release of Clarity is a game changer.  Being technology agnostic, I have a Pros vs. Cons list for each tool that we work with. This release of Clarity has removed the current cons that I had on that list.  If you are considering a tool and have received a demo of the older version of Clarity, make sure you see this version before proceeding.  As I just told the existing users, you will not be disappointed!

Until next time!

Rick

Some Things Just Take Time.....

There is always the great debate about throwing resources at a project to try to pull off the impossible timeframe.  However, some things just take time.  When I train project managers, I use an analogy of what effort driven in Microsoft Project means.  I ask them, “Are you painting a fence or driving to Nashville?”  If you are painting a fence and it takes 8 hours to paint the fence, then it will also take the full 8 hours of time.  If you add a resource, it will still take 8 hours of effort, but will only take 4 hours of elapsed time since two people are splitting the work.  If it takes you 4 hours to drive to Nashville and you add a second person, it doesn’t mean you cut the time in half.  Now two people are spending 4 hours in the car so it doubles the amount of effort.  This is a cleaner version of the way that I used to explain this.  I used to say that you can’t always throw resources at a problem.  The example I would state is that you can’t put 9 women into a room and produce a baby in a month, some things just take time.  I used that for a couple of years and every once and a while, someone would be offended.  So I changed it to a cleaner version for most of my trainings.  However, a good friend John Ragsdale sent me this and it made me laugh.  I don’t know where this originated to give it proper credit, but to whoever pulled this together….it reminded me of when I got started.  Enjoy!

Definitions of Designations:

Project Manager is a person who thinks nine women can deliver a baby in one month.

Developer is a person who thinks it will take 18 months to deliver a baby.

Onsite Coordinator is one who thinks a single woman can deliver nine babies in one month.

Client is the one who doesn’t know why he wants a baby.

Marketing Manager is a person who thinks he can deliver a baby even if no woman or man is available.

Resource Optimization Team thinks they don’t need a man or woman; they’ll produce a child with zero resources.

Documentation Team thinks they don’t care whether the child is delivered; they’ll just document it in 9 months.

Quality Auditor is the person who is never happy with the PROCESS to produce a baby.

Tester is a person who always tells his wife that this is not the right baby.

HR Manager is a person who thinks that a donkey can deliver a human baby in 9 months.

I don't acknowledge it....therefore it doesn't exist!

Is this a reality?  I overheard a conversation last night at dinner where a guy was explaining to his friends that he has not gotten a cold in the last 15 years.  He stated that his grandmother told him that there is no such thing as a common cold.  He believed her and ever since he has never gotten a cold.  One of his friends asked, “Do you ever not feel good?”  He said, “Sometimes my nose will be stuffy or I get a sore throat or cough.  I will feel run down and will stay in bed a couple of days……but it’s not a cold!  They don’t exist!”  Call me old fashioned, but that sounds like a cold to me.
It reminded me of my top 5 favorite quotes from a sponsor.  We were running a project and the sponsor had announced to the entire customer base the completion date of the project before the project was even opened in the organization.  Her statement committed us to a 10 month project to be delivered in 4 months.  I approached the sponsor and told her that we would have to do some serious risk management on the project.  Her response is still a classic: “Rick, this project has no risk because it must be done on time!”  If we don’t acknowledge it, it must not exist.
This same denial seems to be true for sponsors when they set a project date or budget.  They often will tell a project manager, “just figure it out,” or, “just make it happen.”  As if the project manager can just wave their magic wand and a new month will be created or a bag of cash will appear.  Projects have been run this way since the beginning of time.  Why is it so misunderstood?  I like to compare projects to weight loss.  Look, I would love to take a pill at night, never have to work out, eat whatever I want, and lose weight.  The reality is that eating right and exercise is what it takes.  The sales numbers for weight loss fads, products, pills, exercise machines, etc. is staggering!  Every day I hear an ad for a new product that promised dramatic weight loss without changing and of the bad habits that lead to the weight gain in the first place.  It is this same mentality that continues to plague projects.  This mentality that if we put it out there it will happen and if we don’t acknowledge the bad stuff, it doesn’t exist is the basis of many of the organizations in business today.  Then everybody is surprised when something doesn’t go as planned.  This goes all the way back to the way the project was selected and how most likely the budget was trimmed via a spreadsheet to get it to meet an arbitrary number that feels right to the executives.  Sure we can cut 20% of this project, there was probably padding in it anyway!
Risk does exist.  Project failure is a very real and repeatable process.  Yet we continue to not acknowledge it.  For example, a project manager will be told that they do not have time to plan, the project must start now.  The project fails.  The project team does a lessons learned session and blames the lack of planning as the reason why.  Then the team will agree that more planning will be necessary.  Then the next project comes along and the same project manager is told that there is no time to plan, it must start right away!  One of the greatest things we can do as project managers is simply acknowledging that these things do exist.  Documentation and metrics capture that show these patterns is paramount.  We must acknowledge these failures.  It is the first step in resolution.
Go forth and document!
Rick