Project Management optimize

Top five reasons organizations fail at project management

Why are so many organizations still so bad at project management? An expert ponders this question through many consulting and training engagements and ranks his top five reasons below.

Generally

Generally speaking, all companies and organizations are trying to get better at project management. (In other words, there aren't any organizations that are purposely trying to get worse at project management.) Though they may not be able to articulate it, organizations recognize that there is value associated with being able to manage projects more effectively.

Why then, are so many organizations still so bad at project management? What is keeping most organizations from being able to effectively manage projects? I have pondered this on many consulting and training engagements and I have ranked my top five reasons below. See if you can pick out the reasons why your organization falls short in implementing good project management discipline.

5. Senior managers think that project management is a software tool

When you discuss project management with some managers, they initially think you are trying to implement a tool that allows you to be a better project manager. Actually, if it were a tool, you might have more luck convincing them to do it. Even though some aspects of project management, like the creation and management of the workplan, may utilize a tool, that is not where the value of project management is. Instead, project management is about skills and discipline. It's about applying proactive processes and best practices. It's about using common and understood templates. Don't get me wrong--tools have their place. However, software tools are not the answer.

4. Organizations don't value the upfront investment of time

Many people consider themselves to be "doers." Organizations can be that way as well. If you're going to be good at project management, you have to understand that the upfront planning process has value. You need to know that if you plan the project well (in other words, if you know what you're doing before you start), you'll be able to manage the work more effectively. I have seen organizations that say they want to apply good project management, but then are unwilling to invest the time required. No one wants to take the time to plan. Instead, everyone wants to start executing immediately and then redo all the work later to get it right.

3. You may have been burned in the past

A common criticism of project management methodology is that it is cumbersome, paper intensive, and takes too much focus away from the work at hand. Sometimes this is a legitimate concern, caused by not scaling the methodology appropriately to the size of your project. However, project management was not the problem. The problem was a misguided attempt at implementation of project management. If you implement project management methodology right, the results will be outstanding.

2. Your organization is not committed

Many organizations say they want good project management, but do the actions back up the words? For instance, the first time you try to define the work, does everyone say "just get going"? If you try to enforce scope change management, does your manager say "just do the work"? Does your sponsor say you are wasting time identifying risks? This disconnect is very common. The words say one thing, but the actions say another.

1. Organizations don't know how to implement culture change

Most organizations don't know how to manage culture change in general and project management in particular. You can't just train people and turn them loose. You can't just buy MS Project and turn people loose. You have to have a long-term, multi-faceted approach to managing culture change. It takes hard work and resources. Most organizations aren't committed to focus on the culture change long-term, and they don't want to spend any resources to do it. Is it any wonder then, that six months later, project management deployment ends up in the trash pile of culture change initiatives that have all failed in the past?

114 comments
billsherlock
billsherlock

The old PM Cliché is plan to do, do to plan. As a PM do not get sucked into other peoples games and fantasies. First, write a very clear explicit project charter, with summary business case, as described to you and get the 'management' to sign it off. Things like what is the project to do in SMART terms, what authority the PM has, if any and what priority the project has over other work that people are doing. Make sure every other power broker has a copy and let them at each other. When it is signed off, then send a plan, with milestones and resources, for 'approval'. Remember as a PM you can never start a project too slowly. Get your authority before you start using resources. Too many PMs get wrapped up in the initial dream, do not plan or obtain authority, just dive in head first, and find the pool is both shallow and leaking fast.

william.stoddart
william.stoddart

In my opinion, #4 is a big reason for project failure. To do projects correctly (especially larger projects), there is simply no substitute for up-front planning. This of course takes time and resources. Most people are 'doers' and they just want to roll-up their collective sleeves and have at it! This invariably leads to projects that end up over budget and past due. Very thoughtful article - thank you!

jrbogle
jrbogle

For Project Management to be successful your organization and senior leadership have to support it. The result of this commitment will drive the change throughout the organization and impact all of the other reasons for success. If they only go halfway in the preverbial PM pool then you are bound to hit a roadblock(or one of the other four reasons why they fail).

tonycopp
tonycopp

Number 2 is the Top reason, and number 1 never gets attempted. PM is a pull-the-trigger decision, and if there is no one person in the organization with the absolute authority with vision and the cojones to go for it, all else is a circle jerk. If I knew how to prove such commitment, life would be a dream.

shijinou
shijinou

Hi, Guys: I am a head of project management team in a Japanese IT firm. I think the root reason, it failed, is because the organization has no corresponding revenue recognition system towards Project Management. While customer does not pay for it - Customer often only pays for result, not process - then supplier must identity its process needs. As one of them, PM value must be recognized. If not, then, normally there is no enough resource assignment to PM and thus lead PM failure. One of the countermeasure is to set the PM team as cost center. The other is to use multiple element concept in your accounting system to share the PM to other elements. If resource is there, most PM problem can be worked out. Thanks.

RW17
RW17

Oh, I think the #1 reason is missing! Sorry, but I do. The number one reason that Project Management fails in North America is because of the inherent belief that project management must motivate the project to be as fast in delivery as possible, regardless of all other factors! This perspective of project management is fully reinforced by the fact that project managers in North American are solely rewarded based on "implement faster than anyone else"! With 13 major projects (more than 6 months long) under my belt (as an analyst, consultant, senior consultant, project phase/stream lead), this is the sole consistency that I have experienced within every project and every project manager... especially the senior PMs! I also have the fortune of working with a great many people from overseas (Germany, Spain, Russia, Switzerland, India, Pakistan, Singapore, China, Japan, Uruguay... etc etc) on North American projects and I hear their comparative thoughts on the North American P.M. They all say the same thing: North American Project Managers build such an irrational, unachievable plan and then they burn out their consultants in perpetuity trying to achieve those unrealistic timelines, and the projects fail because of missed milestones (and report-lying to the client to pretend those milestones have been met) and the unneeded turnover of burnt-out consultants causing the project learning curve to be repeated and repeated and repeated. Now, I am all for being very busy on a project but there is a distinct and intelligent difference between crushing your consultants on a continual basis and asking them to perform in a timely manner with a responsible level of quality that is deserved by the client! Unfortunately, as long as N.A. PMs focus solely on their superior's demands to implement faster than any other P.M., consutlants will continue to quit at an unreasonable rate, clients will continue to be lied to, and the rest of the world will laugh at us in North America as we commit suicide by paper-work! Sincerely, Russ Willis

K2 YYC
K2 YYC

This nicely sums up the proverbial "whole ball of wax". Project management is at it's core - management. There are a number of tools available and used where appropriate. All projects need to have a sharp focus on "getting things done" but within a context of "changing". I've always liked the quote that "projects are the mechanism we use to facilitate change from one operational state to an improved one." (or something to that effect). If more organizations treated all projects as "change management" first, and "technical" second -- we would be celebrating more successes.

schat05
schat05

Very well said,I think one of the most critical aspects is changing the culture of a company as still most non IT organizations think of Project Management in terms of a software tool ONLY.

Cory M
Cory M

This highlights the need for PM's to be savvy in negotiating scope and relating to the business in non process terms. Don't try to sell process to business leaders-sell results and negotiate risk, cost and benefit.

Bill_Carone
Bill_Carone

I must agree with these Top 5. On numerous occasions many senior managers think that PM is magic. I went into a project once with the complaint that we are behind and what can we do about it. Programmers and Business Analysts were trying to do the work but they weren't focused on the big picture. The BA's wanted a lot of things that just weren't reasonable and the coders were saying that the functionality wasn't defined. So I wrote my report and was quickly hired to bring the project up too speed. I quickly identified that the BA's were saying they needed more database fields and didn't think the ORACLE admin knew what he was doing. Big mistake. So I had to bring EVERYONE together (most BA's were remote) and we spent two days going over what they thought the requirements were. We got that straightened out by implementing Enterprise Architect and then the Java programmers got really busy. The benefit of good PM was, we took a project that was behind a year (not idea how much that cost) and brought it up to speed and slightly ahead of schedule in six months. The sucky thing that happened was that they then assigned the PM work to a BA already a full time employee (I was a contractor). I found out later that it went behind schedule again and now who knows what happened to that project. So the bottom line is, if you implement good PM work at the start, you save later by not having to rewrite and fix mistakes because of the TIME committed at the start of a project.

mahadeva_sarma
mahadeva_sarma

Pure Project Managers without technical experise of the right kind in a particularly important area tend to take the technical part of the job(make light of) and with only bulldozing attoitude try to assign resposibilities w/o considering the WBS. Instead if they only playa an enabler's role w/o getting played down by the most veceferous person in the meeting, it would improve project management quite a lot. Though your reason #5 seems more suited to the IT field, examples of a similar attitude(more than an attitude a fond hope or an overestimated awe for a tool)in a non-IT field are not uncommon.

rramos
rramos

We have all seen it, business or projects grows to quickly and insufficient experienced staffing becomes a firm biggest problem. Many senior managers will delegate their responsibility to the PM's consequently holding them liable for production. PM's are then forced to become technical staff as they don't have authority to hire anyone but are still held to produce their projects as if properly staffed. I have seen many a PM take work home just to meet the deadlines of their original work plan when it is seemingly impossible to keep at their staffing levels. I too was culpable of such action until it was physically unsustainable. I believe this is when senior management revert to reason #2 and thus product quality assurance and quality control fail.

dcritchley
dcritchley

Macro level Scope Creep where the business keeps heaping on requirements and Micro level Scope Creep were BA's and/or Programmers covertly add neat new things.

krauskopfk
krauskopfk

1) inexpereinced project managers 2) lack of understanding of project management pricipals and benefits 3) Trying to implement project management without bringing everyone on board. Development, Product Management, end users may not have agreed to the project management process, or been involved in its creation, so they don't see / know / accept the stated benefits. 4) The process is cumbersome, hard to understand, hard to find, inadequately documented, too long to read, not intuitive. Change is hard. 5) When push comes to shove, project management practices are abandoned to 'get the work done' - lack of commitment from senior management.

beardkj
beardkj

It is not organisations that are bad at project management it is the people appointed as project managers are not skilled and experienced enough. Line managers are good at routine and project managers are good at variety, uniqueness, ambiguity, living in transition etc etc etc

rosearch
rosearch

Organizations get hung up on complicated schemes managing time and resources, forgetting that it's people who push those units around, and indeed it's people who make up most of the 'resources'. If you don't manage your people, all the charts and spreadsheets in the world won't bring your project home on time, on budget - or even within a hundred miles of where you intended it to land. People, as the agents who push those timeframes and resources, and as resources themselves don't all run at the same speed and in the same direction. Just having the plan doesn't mean they are going to follow it. Even forcing them to conform with the 'plan' isn't going to engender an equal commitment from all of them. Indeed in any project you can likely count on folk who kick, folk who sulk, and a heap of very active folk - you think you're on a winner with these until you realize they're the most dangerous because they are out to use you project to push their own barrows. What to do? Simply understand the 'interests' of all of the players before you start, and factor that into your project plan. For example I left a 'endless project' a few years ago after realizing that it was in the interest of just about everyone there to 'never finish the product', they'd been guaranteed virtually endless funding and had no performance targets except the ones they set themselves - which were all activity based rather than outcome based. Sure it's a busy place, but anything they achieve is more by accident than design. But remember, all the performance indicators will show this one as a big success. Which leads to my last point. Don't rely on reputations to tell you what works well. Sometimes the biggest planning disasters are touted as the greatest successes. In business perceived failure equals failure, perceived success equals success. If someone (usually some product vendor) tells you about a fairy tale transformation of an organisation I suggest you listen respectfully, then contact someone at a mid level of that organisation and hear the real story. Managing interests, as opposed to just timelines and resources, is difficult. Which is why good project managers are just about as rare as good managers. Good luck!

jck
jck

The biggest reason is missing: greed Organizations try to "manage" a project by cutting time so short that, in the eventuality of issues, it fails. Managing humans and machines and processes means accounting for fallability and mistakes and mishaps and breakdowns in process. So many want to get the most out of things, they either manage schedule poorly or make promises they can't keep without the worker putting in double length weeks...which in itself is a hazard to a long-term project.

avidtrober
avidtrober

Mis-aligned goals & interests (aka politics) - the inevitable hitch-a-ride types - hidden agendas - incompetency somewhere up the ladder

Project_20
Project_20

So, if my company is guilty of all five (yikes!), what does that say about the company (or me, for putting up with it)?

Steve Romero
Steve Romero

The list of reasons included in this blog, and those added in the comments, will resonate with just about anyone who has worked on IT projects. Though everything is true, it underscores the mistake most organizations make - focusing largely on project management discipline to fix the woes of project management efforts. In fact, I find most of the problems with projects are due to a lack of good IT investment management, also known as IT portfolio management or project and portfolio management (PPM). The fundamental objective of the PPM process is to determine the optimal mix and sequencing of proposed programs and projects to best achieve the organization's overall goals. Few organizations do this well. I argue that many IT projects are doomed before they start due to the lack of good PPM. I will close by borrowing what I consider to be the best description of PPM today. It comes from the ValIT Framework from the IT Governance Institute: The goal of Project and Portfolio Management is to ensure that an organization???s overall portfolio of IT-enabled investments is aligned with and contributing optimal value to the organization???s strategic objectives by: - Establishing and managing resource profiles - Defining investment thresholds - Evaluating, prioritizing and selecting, deferring, or rejecting new investments - Managing the overall portfolio - Monitoring and reporting on portfolio performance *ITGI Copyright. 2006 IT Governance Institute ??? Val IT Framework Without these mechanisms project delivery becomes incredibly problematic and project management can do only so much to overcome the lack of good project portfolio decision-making. Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

swinokur
swinokur

First rule of project management - not properly managing end-user and stakeholder expectations - will surely kill or severely set a project back.

pearson.associates
pearson.associates

1. Unwillingness to follow project methodology - shortcutting steps and overlapping phases combined with unrealistic expectations, deadlines, estimates and risk assessments 2. Part time staff who are not qualified and inability of senior management to set priorities among competing projects 3. dynamic project plans and focus on date driven rather than quality deliverables 4. political agendas within team and no agreement on common objectives 5.Senior management 'blaming' project manager for failures when problems caused by their lack of involvement

kobemsu
kobemsu

I think there is another point is: the continual review and update of a project plan. Time and time again I have seen a plan made and the project managers unwilling to update a plan when it is needed. This leads to a plan which is outdated and useless to everyone. Also I think the relationship/networking aspect is left out as an important point many times a requirement(s) can be changed to make it easier on both parties. Project management has to be dynamic and not a static process you can not sometimes expect to go from 1 to 2 to 3 in that order, you have to be flexible and willing to adapt. Especially in this digital era when situations can change daily.

Satha Arumanayagam
Satha Arumanayagam

a) the project management tools and methodoligies are not tailored to meet the specific requirements of the business.. qualified project managers and sophisticated methodologies do not deliver desired business outcomes Satha Founder SVA Global (ERP/CRM Channel Strategist & Project Managers) m: + 61 417 321 257 e: satha@svaglobal.com w: www.svaglobal.com http://www.linkedin.com/in/satha

dan.dumaraos
dan.dumaraos

Constantly changing objectives is one things that most project managers dislikes alot.

runner412
runner412

Time, resources for PM need to be at least 10% of total project(Increases with complexity). Project =4000 hours of effort. PM = 400 hours of effort. Change management =400 hours to analyze change request( not implement it). Therefore total project = 4800 hours of effort.

osocram
osocram

Just yesterday I spoke with a CEO of an important software firm, and was almost impossible to clear about difference between product/project scope. He (the CEO) think that every think has a solution with product engineering (product scope) in this case software (PSP/TSP, CMMI, RUP), and he can't think that exist project management (cost, comunication, negotiation, EVM, etc...). So I think the only solution is to show it, a real project management with succesfull results. But can be the old problem: what is first, the egg or the chicken?.

patclem
patclem

People who do one thing for a living can make things very complete and functional, but very complicated. For those that don't do whatever it is (like project management) the processes can be so complex that no one but the project manager even understand them! That's why people don't buy into it - keep the "presentation" and the team member responsibilities extremely simple - much more simple than you can even fathom.

Tony Hopkinson
Tony Hopkinson

The real problem to me is PM's in most organisations don't have the authority necessary to do the job. Whether it's a failure to identify the required resources initially, some one important moving the goal posts, unforseen reduction in resources. Most of the time they get to manage within poorly defined constraints and have no way to change them. Hence report success and hope crossing of fingers does some good. I've got to say the japanese work ethic probably helps you out. One place I worked at used to go over regular for tips and tricks. That was one thing they couldn't get past us gaijin though. :p Never got the chance to go over to Kobe, mainly the engineering types. Some big head must have thought we couldn't learn any IT stuff off you guys.

T.Walpole
T.Walpole

As opposed to talking to people who are from there and making judgements based on their musings, I've actually run projects in some of the places you mention. I hate to say it, but the same lack of understanding of the need for proper project planning exists everywhere. I read this article and can cite many of my own experiences that match the anecdotes mentioned. Yes, in North America timeframes are usually tighter but, as a result, American PMs are known and respected for being able to get things done. Projects in Europe have a tendency to take much longer than they need to. That can be for different reasons. In Russia, over-reliance on existing bureaucratic process may result in unnecessary project delays. In Germany, there may be a tendency to over-analyze and over-plan. The resulting system will probably work perfectly, but its often over-engineered and they took twice as long to implement and as a result their competitor has beat them to the market. There is a reason why innovation in tech is still for the most part originating in North America.

jck
jck

however, not only planning well but sticking to that plan from concept to delivery is important. i worked in an environment once where the dropdead change deadline was Dec 31. the project manager was still letting the customer make changes in march. the amount of regression testing and QA we had to do with all the changes was enormous and management wondered why we got 2 months behind even though we were working 55-80 hour weeks. execution of the plan means making sure all things are being done right...not just that it is designed "good enough" and that you put tons of hours in to get it completed. i've had both great PM and bad PM...it does make the difference.

aghai
aghai

Some additional reasons to some of the excellent ones already mentioned: 1. Inexperienced, untrained PMs; 2. Lack of PM knowledge amongst executives/ senior management/project sponsors that results in insufficient support to the PM; 3. Lack of understanding of a PMs role, authority, responsibility; 4. Mistaken belief that PM is a part-time job and can be added when a person is already fully allocated in another role;

georgef
georgef

I would caution against developing empirical conclusions from relatively narrow experiences. I don't mean to demean your PM experience or knowledge but unless we've had the experience of managing hundreds of projects in hundreds of companies and different situations, something like Ralph Kimball's DW experience, we can only feed our judgements from that relatively narrow experience. One thing that you write sticks out a lot of for me. Your second to last sentence comparing good project managers to good managers. I wholeheartedly agree and consider a PM position to be an episodic or sliced manager, except in those situation where the PM has absolutely no management responsibility or authority, situation, I believe, that are likely to fail. That rarity is in the 10% range for both, because of human nature and the confusion generated by these cookie cutter standards of process.

fidlrjiffy
fidlrjiffy

Indeed, depending on the use to which IT governance is put can have a lot to do with success. At one extreme only accepting projects that are so easy that they can't possibly fail ensures success. At the other extreme accepting every project that comes along because, yes, they are all necessary to some degree means that virtually all of them will likely fail. In my experience in managing the IT governance process my attempts to quantify the value of a project met with a great deal of resistance from my own IT management. On the other hand, the business areas were all too happy to make the attempt but had no idea of how to apply a value to their project even to be able to estimate the value of their cost avoidance. Senior management only cared about how many FTE's could be reduced by the project. Really large projects involving 3rd party vendors came to the steering meetings with the contracts well under way if not actually approved. And of course I agree that most organizations do it badly so I am curious about your role a Governance Evangelist. There cannot be any doubt that the more wisely projects are chosen the more the likelihood of success. So, aside from advocating governance how is your success rate?

georgef
georgef

Amen, I say to you. Site requires body text. I think the first Amen was nuff said

fidlrjiffy
fidlrjiffy

Amusing anecdotes: I had a senior manager who objected to my using MS Project which I had used to compose my project plan completed with WBS and linked tasks. He did not like the fact that when a particular task somewhere in the middle of the project was late I would enter whatever new date the developer gave me. Of course, this would push out other dates and invariably the go live date. "You can't change the date!". I think he just figured we could just spend less time doing other tasks which would invariably mean that they would be late, too. I recently had an interview for a PM job where the interviewer was apparently trying to give me a realistic view of the culture. "When projects are successful the team gets the credit, when they fail the PM gets the blame." I did not hear from the recruiter again after I pointed out that this sort of thing did not exactly make the job hugely attractive.

georgef
georgef

..that its the digital era that makes things so variable. I think its just the nature of business climate these days. Mergers, acquisitions, divestitures, partnerships, etc. A lot of MBAs justifying their existence, maybe. I think if you have a project set to run more than 3 years (maybe even 2), it has a much much higher likelihood for failure.

Tony Hopkinson
Tony Hopkinson

it's 11.575% You are guessing, admit it. You'll feel better.

NotSoChiGuy
NotSoChiGuy

I was put into that position at my former employer, and let me tell you, nothing starts the gray/white hairs sprouting quite like having to juggle the implementation of an offsite call center project with a critical enterprise application server dying in the data center. Not exactly fun times; especially when senior leadership is without a clue.

georgef
georgef

...sound too negative, and please Steve don't take this personal, but IT Governance Institute. Sometimes it seems like Institutes and methodologies, etc. spring up like ticket scalpers at a NY Giants game. What Fidlr mentions in the 2nd para,refers back to something from the "old" days. Systems Analyst would perform a Cost Benefit Analysis of a proposed project and pass that up to the respective decision makers. Its old hat but like so many things, is forgotten in the name of other things. KISS should still reign supreme in shops. What I mean by that is, forgot about all these fancy terms, methodologies, and institutes and work things from their basic level. Much was accomplished in those "old" days and because many projects derailed, doesn't mean that fundamentals have to be reinvented or forgotten.

georgef
georgef

.. even a the higher level, in general the IT manager will get the blame for things going wrong. As a PM or DirIT/ITMgr, you have to float up and make visible the problems you have and their potential impacts. Keep the right people in the loop so that informed judgements can be made. That doesn't mean find a scape goat. You should own up to your own mistakes as a matter of good ethics. Even with this, there will still be situations that you get the blame anyway. Such is Life.

runner412
runner412

managing change can be done by costing the sponsers of the project. PM admin costs contained by costing. No changes , change management cost reinbursed. Additional PM efforts constrained by costs. Experience and rsults inforce this approach.

georgef
georgef

We're of a mind. I agree with everything you have here. Everyone's experience is limited, there's just too many people who think they've experienced it all, and so they come up with a system or a book. You've got to separate the static from the music. ;^). I feel we've had similar experiences and taken similar things from them, which is never guaranteed, where humans are concerned.

fidlrjiffy
fidlrjiffy

Sounds like "we love standards which is why we have so many of them". I agree wholeheartedly. It seems that the quest for the perfect, or even less than imperfect, methodology feverishly continues, and each one that arises is "THE SOLUTION" until this perfect solution is modified out of existence to make it even better. A framework always makes sense, heck, a plan is vital, but in the end common sense reigns. If 90% of your work remains and 50% of your time is left you're late. Deal with it; move the date, cut requirements, kill the project, (don't add resources, please!!!), but whatever one does don't do the next project with the methodology de jure expecting that it will solve your problems. I'm especially wary of PMBOK which appears to me to be a combination of common sense, waterfall, and snake oil. As a fairly common requirement these days is seems to be more of an expectation or hope that it will lead to a higher rate of success than a proven, consistent, and repeatable process framework. Stage Gating, for instance, assumes or requires that a phase be completed and signed off before moving on. I suppose there are some shops where it happens but there's not a developer around that can or should wait for a committee to sign off on their work before moving on. I would be interested in other views as my experience is somewhat limited.

Tony Hopkinson
Tony Hopkinson

That's the fella. Mess about with numbers, get smileys on the dash board, job done....

georgef
georgef

..hist that nail TDC. Keep everybody anesthetized by producing reports and status meetings and don't focus on managing the project. That, I would think is the biggest cause of failure.

runner412
runner412

I agree. Changes without resource consequences is fatal. Buget cutting aand/or increasing scope again fatal. Most PMs do only project reporting and abdicate management. From The CHAOS Report -2007- CHAOS reported 84 percent IT project failure rate in US. 2004- CHAOS - U.S. project waste to be $55 billion ($38 billion in lost dollar value and $17 billion in cost overruns.)

Tony Hopkinson
Tony Hopkinson

because they agree they can change the thing, and not give you any more resource. Often doesn't work on external projects with an up front qoute for a fairly fixed cost and often fairly ambiguous requirements, because the initial estimate was deemed too high, so someone chopped it to get the job.. Set up to fail, the pseudo scientific twiddling is an illusion of control enabling accurate reporting of abysmal failure. Not knocking all PMs, but all too often they don't do project management they do project reporting... I see the above two time after time, so obviously past results and experience aren't even on the radar.