Am 18.08.2016 um 08:50 schrieb scott:

> What happens here:
> 
> They (project manager/planner) will ask the people who know how long it
> will take, get told it will take 18 months. They'll moan at you, tell
> you to cut out stuff and squeeze the schedule to make it 12 months. So
> reluctantly you agree to 12 months with cutting out all this stuff and
> squeezing the schedule to a high-risk one (ie nothing unexepected will
> happen... we all know how that goes).

I think you've just mentioned the key problem with traditional software
project planning: Handling of the unexpected.

In my career as a software development, I have been involved in exactly
/one/ project with really sound planning. I guess it is no coincidence
that this was /not/ a native software company; it was an automotive
engineering company, and the software to be developed was firmware for
one of their products.

It was also the only project I've ever been involved in where people
didn't try to pretend they would have everything under control.

"From our experience, we /expect/ to lose X days to unexpected problems."

And the one particular product I was involved in did indeed run into
problems, due to the customer being way overdue in delivering a
prototype car for testing. Ultimately, a few weeks before the deadline
we had to communicate to the customer that if they wanted us to proceed
with the project, they would have to take the full risk from now on,
even for things /we/ might screw up -- because the buffer we had wisely
set aside for such blunders had been all eaten up by their delays.

(The customer agreed to proceed under these conditions, and the project
did indeed proceed without any hitches from our side, and finished just
in time.)


I think it is this mindset of acknowledging that one /will/ run into
problems, both self-made and external, and that time /must/ be reserved
for such events accordingly, that is crucial for good project management.

Post a reply to this message