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."
"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, 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?

Topics: CXO, IT Employment

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

29 comments
Log in or register to join the discussion
  • #9 is wrong

    The actual principal for #9 is the GFC principal, Good, Fast, Cheap, pick any TWO.

    In reality, a successful project blends all 3 to get a product with a reasonable level of all.
    ridingthewind
    • Nein is wrong...

      ... - well, actually it means "No".

      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.
      thx-1138_
      • GFC is also a programming principle

        Actually, Good, Fast, Cheap pick any two is a broadly applicable and this link explains why:

        http://www.sixside.com/fast_good_cheap.asp
        wolf_z
    • Re: #9 is wrong

      I agree. Most projects are, at the end, compromises. It's probably GOOD to hear the line

      ?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."
      response42
      • RE: 10 things your IT project manager never wants to hear

        @response42 I like your take, imagine what would happen if people answered these questions honestly?
        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.
        ClaudiaVandermilt
    • #9 contradicts #7 (#9 is wrong)

      In #7 you quote "The way to get a project back on schedule is to remove promised-but-not-yet-completed features"

      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.
      adinas
  • Corollary to #10:

    "It's just what I asked for, but not what I wanted."

    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.
    Henrik Moller
    • Exactly

      I've just taken the PM role for a college with 2000 users, 500 workstations and just over 100 notebook PCs.

      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.
      thx-1138_
  • Hmmm, as a project manager you should

    anticipate things going wrong and be monitoring the project close enough there are no surprises.

    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_Ax_to_Grind
    • No Project is Perfect

      In my project management training, they made the point that you can't just plan a project using requirements and milestones. You must also have contingency plans. If you plan for problems, you can still succeed. Expect the unexpected.
      MichP
    • And have well documented change control procedures

      including estimates so that if the customer asks for a "minor" change, you can respond with the impact(s) to cost and schedule. On many of the projects which I have worked, the client was presented with that information, they were able to decide intelligently and many times it was to put the "minor" change into the next release.
      dinosaur_z
  • "Fast" means two different things.

    For the *same project* fast means:

    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...
    wolf_z
    • And if the customer said. . .

      that he didn't want any blacks or women working on his project is he right then?
      pueblonative
      • See rule #1

        Rule 1: The customer is always right.

        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...
        wolf_z
  • RE: 10 things your IT project manager never wants to hear

    Re: #4 - The reason so many IT projects fail is because of failure to understand that project management is a subset of comprehensive work and resource management. Focusing myopicaly on projects alone is like trying to manage the household budget by only considering the mortgage and car payment - sure they're big items individually, but in total they make up only a small part of where all the money/resources go.

    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
    tdoerscher@...
    • OK - so its related to number 5 not 4

      OK - so its related to number 5 not 4
      tdoerscher@...
  • List is loaded with contradictions.

    That's not surprising. The way to solve one problem is often inconsistent with the way a different problem is solved.

    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.
    Anton Philidor
    • And there is an important one missing

      #11 "All I know about project management I learned from Deb Perelman"
      response42
  • RE: 10 things your IT project manager never wants to hear

    The one I feared most was when a female employee came in to tell she was expecting a baby. It happened 22 times in my career and every single one was catastrophic as she proved indispensable at the time. In Belgium it means at least 4-5 months of maternal leave, enough to sink any project.

    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.
    lvolders@...
    • Wow, That's Sexist

      Last time I checked, human pregnancies last 9 months. I gave my managers six months notice. That should be enough time for anybody to make arrangements.

      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?
      MichP