Recycled QWA: project manager dictionary

Wednesday, 18 July 2007

accounting: don’t worry about this, there’s another department that takes care of it.
B2B: what we call our business stuff now.
B2C: what we call our customer stuff now.
business need: a term without any literal meaning used as an idiom to say, “My VP is bigger than your VP.”
communications strategy: the written guides for how to write to each other; the longer the better as the more that you can communicate up front, the less they’ll read and the more you’ll be able to say, “I warned you about that.”
deadline: the chance for you to apply the hard won knowledge behind your liberal arts degree to decide how long it will take 5 guys on HB1 visas to finish and debug 250,000 lines of C++ while building it out properly on DEC, Solaris, and Linux boxes.
deliverable: what others are responsible for at such time as the PM indicates; see deadline, your mini-‌Ouija board and key-‌chain Magic 8-‌Ball for more.
dependency: programmer double-‌talk for “I’m too high and mighty to do that for you.”
documentation: the official record of what happened and how it all works; remember that the messenger makes the easiest target so keep it light—you can always assume the bugs and missed features will be taken care of in version 2 so there’s no reason to go into details in the current documentation.
feature set: a fancy way of saying, “We really don’t know what we need so just whip something up and we’re sure it will be fine.”
human resources: protection; job security; keep their senior manager in lunches and margaritas.
kickoff: the initial project meeting; as in football whence the metaphor is drawn, there will be somewhere around 11 huge, angry antagonists trying to take the project away and run it back, right through you.
milestones: successfully reached ones are résumé bullet points, the others are guidelines for personnel changes following the project.
P2P: what to say to hose down the programmers who bring up a partner’s failure to fulfill contractually obligated data delivery.
post-‌mortem: where you get your next raise; during this “20:20” part of the project you must make sure slippage outweighs milestones for other groups and the reverse for yourself; make these points orally! The documentation phase is long gone.
PowerPoint: that thing that whats-‌her-‌name will always help you with right before a presentation.
programmer: serf.
project: 15 hours of meetings out of the 40 alotted to do an otherwise straightforward piece of work; fluff; filler; corporate pork.
project schedule: the thumb screws; punitive tightening encouraged.
quality assurance: the group that tests drafts of the project; while you’d expect them to have the most power, they’re actually the least well paid and easiest to replace, hence they are easy to bully.
risk management: the process of minimizing the impact of project set-‌backs and failures by ensuring the project manager is the least responsible for key pieces.
ROI: something to do with money; bring it up when the serfs get noisy about new hardware, adding team members, or extending the testing phase.
security: check the budget—if it’s not specifically paid for in there then this isn’t part of the project.
scope: the limits of the project; make sure to nail down your parts of the scope but remember that the technical managers rarely turn in a good or complete technical requirements doc so you’ll be good for blaming any scope creep on them.
scope creep: hostile feature negotiation.
slippage: retaliation.
software development engineer: what to call the serfs to their faces.
stakeholders’ meeting: the meeting of those who will be invited to the launch party.
status report: a frequently updated tallying of where things stand; like all writing based on actual events, it can be improved with minor dashes of fictionalization.
technical requirements: the badly written (step in immediately if it’s turning out to be any good) contribution to the project outline from the tech group manager; make sure the requirements are suitably vague so you can hang it on the techies if things blow up.
triage: the process of assigning priorities to the missed project goals; it’s best to get the low level stuff first because it makes the project look like it’s progressing rapidly; the big stuff will take care of itself and if it doesn’t, you can just point out that you didn’t have enough time.
user acceptance testing: the phase of the project where the shit can go sour—keep the QA and testing documents terse to help head that off.
UAT: something to do with European tax laws; let the biz dev people sort it out.
XML: what to say to rein in the programmers who start talking their RDBMS/UML mumbo-‌jumbo in meetings.