10 things your IT project manager never wants to hear
Summary: "The dog ate my presentation." "We've decided to change directions." "I'm dumping this employee on you who has failed at every other thing we've assigned them." ... IT project managers have heard it all.
![]() |
| "This isn't what we were expecting." |
IT project managers have heard it all, but they still shudder when they hear these excuses because the number of things that can set a project behind schedule or completely off-course are numbered to infinity--but that's not even the worst of it. Below, a round-up of the ten words and phrases that project managers say send such fear into their hearts, they must fight the urge to run for the hills.
1. "I have a challenge for you." Often uttered by a CIO or high-level manager in an upbeat, enthusiastic tone, this proposition sends most project managers running in the other direction, as they know all-too-well that "challenge" usually means "the CEO has read something in an in-flight magazine and its now very, very important for us to embrace it to be ahead of the game," says Cornelius Fichtner, an IT project manager based in Silverado, CA who produces The Project Management Podcast.
"That usually means that you're about to get a project that is absolutely impossible to succeed with, impossible deadlines, no budget, no people and by the way you have to do this on top of everything else you need to do."
2. "One minor change." The only person who thinks this change is "minor" is the one requesting it, say project managers.
"The customer often thinks its a small thing but it's actually a huge change in the philosophy and architecture of the project you're doing," said Fichtner. "But micro-changes will be exhausting as well... all of the 'two moves to the left' and 'a hue bluer'--dozens of little things that require more work."
3. "Rearchitecting" The decision to rebuild something from scratch rather than taking the time to make sense of the earlier work done on a project is rampant in project management, say its weathered team leaders, and it's always because the predecessor had "no idea what they were doing."
"Rearchitecting, it seems, is every engineer's wet dream," the software project manager behind the blog The Cranky Product Manager, tells ZDNet. "How could an engineer possibly be expected to understand the code their predecessor wrote? Better to tear down the entire house--even though its residents are perfectly sheltered--in order to remodel the bathroom or put a cover over the patio."
4. "This new [fad] technology would be perfect." Some project managers cringe at the words "fits perfectly," because in most cases, is rarely is.
Says the Cranky Product Manager, those obsessed with the newest technologies often forget about little things like deadlines. This thing needs to be DONE in two weeks and we don't have time for the developer to learn the latest resume-enhancing technology on the job while that clock is ticking," she explains.
This phrase often goes hand-in-hand with "Let's use this new, untested method instead," when "untested" anything can be the bane of any project manager's existence, says Thomas Cutting, a project manager who blogs at Cuttings Edge.
5. "I was too busy firefighting to finish." More than a 'dog ate my homework'-level excuse, employees assigned to projects that are only one piece of their grueling jobs is an unfortunate reality that project manager constantly deal with.
"I'd hear all the time that they had to put out a fire in their day job and they couldn't meet the deliverable on your project," explained Nehme Abouzeid, who spent more than four years as project manager before becoming the assistant director of business development at Las Vegas Sands. "At the heart of it, most people on your projects don't report to you all the time, and you can't control their schedules or blame them if they are stuck doing their other work... You will really need to use every trick in your arsenal to work around these limitations."
6. "I've been reassigned." It always happens to the person you need the most.
"You're on a very important project and you come into work one day and your chief architect says 'I've now been assigned to Project X and it's been nice working with you," said Fichtner, something that can set a project back weeks or months while the project manager scrambles to find a fitting replacement.
7. "Let's add more people to this!" Published first in 1975, The Mythical Man Month was written by a software project manager at IBM. The central teaching of the book was that adding more people to a project that is already behind schedule will make it later, but despite these warnings, project managers are often told that this will be the solution to their scheduling problems.
"1 programmer for 12 months does not equal 12 programmers for 1 month," reads the book's introduction. "The performance of programming teams, in other words, does not 'scale'... The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees. "
8. "It would be technically impossible." Phrases like this are all smoke and mirrors, says one project manager.
"When a developer claims that something is 'technically impossible,' in my experience, developers only claim that the really boring stuff is technically impossible," explains The Cranky Product Manager.
"Saying something is 'technically impossible' makes marketing and non-tech types shake in their boots. ... Perhaps the way the developer thinks is the ideal is technically impossible, but almost always the customer requirements can be met via a different, more earth-bound implementation."
9. "Do you want full functionality or on time?" Telling a project manager that they need to choose between quality and executing on time is the quickest way to put them in a really bad mood, says Saeed Khan, a project management veteran who blogs at On Product Management.
"I've heard, look, we can deliver on time or with full functionality, or with high quality. Which ONE do you want?" says Khan. "Answer: I want a new development team that has a clue."
10. "It's not really what I expected." Though it sounds just like that comic strip where the customer is billed for a roller coaster but only needed a tire swing, these words come out all the time in the final unveiling.
"If this happens, you're not doing a good job because it should have happened a lot earlier, first walk-through show preliminary results to customer. Once the house is built, it's a lot more of a disaster, like one of those redecorating shows where people are shown their redesigned living room and hate it," said Fichtner.
Are there any they've missed?
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback
#9 is wrong
In reality, a successful project blends all 3 to get a product with a reasonable level of all.
Nein is wrong...
So I'll say "No" to you, since the GFC principle (your first typo: "principal") was typically related to the automobile manufacturing industry - which is about as akin to IT management as "Ethics, Peace, Hope and Goodwill" are as likely to be the prime agenda for any given Republican Convention.
QUOTE:
"...In reality, a successful project blends all 3 to get a product with a reasonable level of all."
You obviously made your second 'typo' in your final sentence, since "an ideal world" (i.e. a completely fictitious Utopian planet somewhere near Omicron Persei 5) is not spelled "r-e-a-l-i-t-y".
Sincerely.
GFC is also a programming principle
http://www.sixside.com/fast_good_cheap.asp
Re: #9 is wrong
?We can deliver on time or with full functionality, or with high quality. Which ONE do you want??
because it usually comes reasonably early in the project and there is still time to do something about it.
Honestly, answer ?I want a new development team that has a clue.? appears to be very simplistic.
Perhaps the answer should depend on the circumstances, on who did the estimates, what the estimates were based on etc.
Some other, perhaps equally valid answers are:
"Sorry, I don't have a clue how real projects are run and therefore I should let somebody else to do it."
or "I want a dev lead that makes me feel really good even though he lies through his teeth."
RE: 10 things your IT project manager never wants to hear
I'd love to hear someone respond to ?Do you want full functionality or on time?? with "I want a development team that can provide both, if you feel you're not the best for this project, say so now so we can find the right team."
Unless, of course, the project is insane or has been hit with "minor changes" half a dozen times before this is brought up.
<a href="http://www.villanovau.com/certificate-programs/project-management-certificate.aspx">Project management training</a> for the IT PM may be needed.
#9 contradicts #7 (#9 is wrong)
Isn't that exactly like saying "We can deliver on time or with full functionality" (so lets choose ontime)
So basically I agree that #9 is wrong.
Corollary to #10:
This is generally the result, not just in IT but in any technical project, of the usual inability of non-techies to communicate with techies. Non-techies can mentally see the box their wished-for widget comes in, so that's what they specify--they haven't a clue how to usefully specify the content of the box.
Exactly
The requirements: "2 x airport-standard" access points to service wireless users across a 6 acre, flat and sprawled campus ("beam me up Scotty", he says); an in depth Audit of current network media (i.e. copper, fiber optic, etc) c/w comparitive analysis; and finally a complete security review focusing on: policies, procedures and best practices.
After the initial meeting with the college's contracted network support vendor, the Client was looking somewhat 'dazed and pale'. End Result: Projected budget has shot up to the absolute maximum of allocated budgeted funds - with unplanned costs sure to balloon the final tally.
Which brings me back to your statement which just seems to echo so true:
QUOTE: "...Non-techies can mentally see the box their wished-for widget comes in, so that's what they specify--they haven't a clue how to usefully specify the content of the box."
When push comes to shove, the Client (i.e. typically "non-techie") and the IT Project Manager are always somehow speaking different languages when it comes to establishing the DUR, Scope and Objectives of any given IT project. If PM's had a dime for each time a Client said, "We've got $15K to spend, we want to remodel our HQ to match the Google HQ in Zurich." (or a request to similar effect), most would be doing philanthropic work like Bill Gates after retiring early on the subsequent "mountain of cash".
Seriously though, the "curse" that most PM's are afflicted with is having to "carry the can" for the shortcomings of the 'generally' non-techie Clients they are hired by. However, as much as PM's will hate to admit, it simply goes with the territory.
Regards.
Hmmm, as a project manager you should
I know I have said it before but, project management is a very real skill set and not the job you get when you out lasted the other guys.
No Project is Perfect
And have well documented change control procedures
"Fast" means two different things.
To the developer: "two months, 12 hours a day, 7 days a week."
To the customer it means "Next Wednesday".
And the customer is always right...
And if the customer said. . .
See rule #1
Rule 2: When they're wrong, see rule #1.
See how dangerous zero-tolerance policies can be? :)
It all boils down to people who are clueless about actual implementation setting deadlines and not caring their expectations are unreasonable/break the laws of physics.
They have the money, they set the rules and if you don't like it well they can always find somebody else who will work cheaper. Those people will also lie sweetly to them and be incredibly inventive with exuses when the inevitable occur.
They call it "managing expectations". :)
Cynicism 101...
RE: 10 things your IT project manager never wants to hear
When four project managers are each promised 50% of a DBA's time, while the DBA is actually spending half their time on a production system, no one should be surprised to find that a whole bunch of project schedules are going to auto-disassemble.
http.blogs.planview.com/tdoerscher
OK - so its related to number 5 not 4
List is loaded with contradictions.
The contradictions?
Consider #7 and #9:
#7
???1 programmer for 12 months does not equal 12 programmers for 1 month,??? reads the book???s introduction. ???The performance of programming teams, in other words, does not ???scale?????? The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees. ???
[Reduce features.]
#9
???I???ve heard, look, we can deliver on time or with full functionality, or with high quality. Which ONE do you want???? says Khan. ???Answer: I want a new development team that has a clue.???
[Do not reduce features.]
Another, consider #2 and #10:
#2
???The customer often thinks its a small thing but it???s actually a huge change in the philosophy and architecture of the project you???re doing,??? said Fichtner. ???But micro-changes will be exhausting as well??? all of the ???two moves to the left??? and ???a hue bluer??????dozens of little things that require more work.???
[Customer changes are abhorrent.]
#10
???If this happens, you???re not doing a good job because it should have happened a lot earlier, first walk-through show preliminary results to customer.
[Customer changes should be sought.]
As with any human activity, the best solution is the one that works. And an expert can violate every rule and make it work.
That's why experts are valuable.
And there is an important one missing
RE: 10 things your IT project manager never wants to hear
Birth control pills were freely distributed at the office premises. Whenever a secretary or a female assistant stated she didn't need them, my cardiologist did overtime.
Wow, That's Sexist
So what if birth control was available? Are you saying women who work should never have children? Or that they should get your permission first?
I worked on a TEAM. Sure, I had my area of expertise, but someone else could take it over in my absence. And I could handle their stuff. Nobody should be set up to be indispensible. That's an organizational failure.
Quit blaming it on the women. What would happen if a man got hit by a bus tomorrow?