Comment by edw519 | Hacker News Reader

Comment by edw519 | Hacker News Reader

Parent Full thread

The Lifecycle of a Project Manager:

Phase I: (Idealism) Treat building software like building a bridge. Analysis --> Design --> Development --> Testing --> Implementation.

Phase II: (Pragmatism) Realize that Phase I doesn't work. Try to figure out why. Decide that the weak link is Analysis, i.e. we're no good at estimating and hitting deadlines because we never have good enough specs. Devote your life to the art and science of getting the perfect spec. Implement the methodology du jour to make that happen.

Phase III: (Realism) Realize that Phase II doesn't work. Decide that no existing Analysis methodology works because no one knows how to conduct analysis, no matter what the methodology. Focus on optimizing the practitioners with better education and 10,000 hours of real-world experience.

Phase IV: (Enlightenment) Realize that none of the other phases works because we've been focusing on the wrong constraints all along. Instead of optimizing scope, quality, or quantity of the product, optimize the schedule. Adopt a new model: define the deadline first, then build whatever you can by that deadline. Hit your deadlines every time, not by estimating better, but by not caring how pretty your deliverable is. Eliminate the problem of estimating by making the deadline a constant. Eliminate the problem of analysis by replacing it with prototyping and revising. And eliminate the problem of blueprints by adopting a strategy of inventing, not engineering.

Phase 0 (Big Corporate IT): PM is given deadline by business, goes through song and dance of negotiating deliverables (without any analysis being performed or developers consulted for estimates), is forced to start work with a small team of internal people outside of the business area not resourced to any projects currently, but who've coded a few lines of VB so can probably do a web application scaling for 5,000 users. PM then hires outside contractors (probably with even less knowledge of the business) to fill in the resourcing gaps as the deadline looms and the demo still doesn't work.

No real objective measurements for project success are defined or put into place, but at least the executives can say they're "embarking on a technology-driven initiative to improve [area of the business they're responsible for]" and so they meet their bonus criteria for the year, and if they've done everything correctly, the executive's contract will end before the project goes red.

If all doesn't go well, well, that's why you have PMs! They're the "responsibility buffer" - the guys you get to blame and fire rather than the actual executive who initiated the project and failed to provide real support and leadership.

They're the "responsibility buffer" - the guys you get to blame and fire rather than the actual executive who initiated the project and failed to provide real support and leadership.

Sorry I disagree with this. I haven't seen Senior Execs getting fired. In fact its almost always the other way round. The Execs take credit for nearly all success even if they don't move a finger to make it happen. It happens so often Excellence awards and cash rewards go to executives 'for showing leadership and successfully leading team to success'.

If things go wrong its always 'Programmers didn't do their job properly so what can one exec do?'

I think you may have misread the parent. The "responsibility buffer" he was referring to are PMs (Project Managers), who are not senior execs.

Edited : PMs, by nature of their (typically) limited skill-set and solidly middle-managerial roles are highly expendable.

Just to note, proper PMs are rarely without a job, they're pretty hard to find. A good PM is paid more than a good developer, usually silly money, because true project management is a pretty large skill-set.

What you're describing is the enterprise habit of giving a generic middle manager the PM role and expecting them to have all the skills and then firing them when said project implodes.

"they meet their bonus criteria for the year,"

Management gets started so quickly to meet their quarterly bonus - not that they don't get an annual one. The quarterly bonus allows them to synchronize the announcement of initiatives with Wall Street.

I once interviewed a project manager.. asked how he came up with deadlines. He said "ask the programmers and subtract 20%". Talk about a red flag in an interview!

That's funny, because as a programmer I always estimate how long it'll take and add 20%.

Only 20%?

A recent conversation I had with my MD, regarding how long to estimate for a project, involved me adding 6 months for each feature added to the specification.

We're also careful emphasise how inaccurate these estimates are, and we don't really know until we start.

Of course this is the initial "finger in the air" stage. We try to be a little more concrete with more immediate requirements. Of course, we've gotten those badly wrong too.

You still lose x1.20.8 = 0.96*x

Brilliant. So much for 'just take whatever I tell you and multiply it by three'.

That's the line I heard from a previous PM I had too.

I heard somewhere long ago "double the estimate and add a unit". Two weeks ==> Four months.

and then multiply that figure by 3.14 to account for running around in circles

That's a good way of explaining the old addage: Timely, complete, low-defects. Pick two. In software, it does seem like timely and low-defects should be fixed, since "complete" implies some knowledge about what the software should be, and we're rarely right about that ahead of time :-)

" Hit your deadlines every time, not by estimating better, but by not caring how pretty your deliverable is."

I'd kill for some Phase IV PMs. :)

(Actually, it's rare that I meet Phase I PMs. Very few PMs think in terms of developing software across those 5 stages. To them it's Photoshop -> Make Photoshop Mockup Do stuff -> Fin)

Nice. You should make that a blog post so we can send the link to all newbie PMs we encounter.

Most managers would know Phase IV if at all they had done some real work.

As it happens people generally go over to Project Management if they can't do technical work.

This creates a problem, you are asking somebody to manage things which he himself didn't want to do.

But how does that help the customer (be it internal or external)? How is he supposed to align capital, human or financial? For example: when does he tell the marketing team to start the big launch campaign, etc?

An example would be something like a main-stream game, say Battlefield 3. The have marketing videos months in advance, they sell games in advance and by doing so they promise that the product will be available at a certain point in time. It may contain bugs, but, unlike what you say, it cannot just be whatever is ready at that time (say without support for sound, or not controls)...

This may come off a bit cliche... but their is the alternate Blizzard Model (Yes, I know blizzard isn't the only one doing this)... Blizzard has tended towards the "It will release when it's done" model in the past.. and recently with Diablo 3 their model had been identical until the very end where they cut half (maybe less than half but it felt like it) of the game out of the final deliverable to decide when they were going to deliver (They cut the pvp content though they intend to add it back later).

In this way I think blizzard provides a good counter example for A) Setting deadlines at the beginning and B) Not shipping whatever is done.

I like your idea about constant deadlines, but I'd add a twist. In a novel writing course I'm attending, I know what I want my character to say as her last line, so I build the dialogue backwards starting from that.

I should do the same with a deadline: estimate what is to be delivered on that date, backwards. This could be a good method for reaching a consensus on scope with customers, and they would understand that meeting the deadline is a given.

Then there are those who care very much how pretty the deliverable is (Eg Apple) but who also hit their deadlines. How? It's not via Phase IV as stated.

Apple drastically cuts feature scope early and often. The result is products that seem a little feature light to many technophiles and reviewers, yet sell like hotcakes to the real customers. How many companies could resist putting a camera in their hot new phone when they know there will be many negative comments on that exact point?

Apple is willing to wait and get it right in the next iteration.

They are doing a variant of Phase IV. The PMs are disciplined and upper management has the mindset of what we would hope for from sharp PMs.

Reply on news.ycombinator.com