You’re missing a frame – where the customer comes in halfway thru the project and changes most of the specifications. That’s what most often leads to your last frame.
Which leads to the conclusion that strict project control via a detailed and accurate and AGREED by all parties document is critical. THEN when the changes come in you charge for them and allow a suitable addition of time – The customer agrees and signs – No argument as to WHO is at fault.
I can’t tell you how many times I’ve explained the 1:10:100 rule.. Or how many times I’ve laughed at “agile” programming.. Still we always get blamed for the selection of the 100..
You’re missing a frame – where the customer comes in halfway thru the project and changes most of the specifications. That’s what most often leads to your last frame.
Which leads to the conclusion that strict project control via a detailed and accurate and AGREED by all parties document is critical. THEN when the changes come in you charge for them and allow a suitable addition of time – The customer agrees and signs – No argument as to WHO is at fault.
true story!
True, true. Happens all the time. Hey, that’s why it is called software… development, with a strong emphasis on “development”
For sure the last company I worked for …
Pingback: Life of a Software Engineer | The LOL Yard
Pingback: November 16, 2011 – Links | MarcJStuff
I can’t tell you how many times I’ve explained the 1:10:100 rule.. Or how many times I’ve laughed at “agile” programming.. Still we always get blamed for the selection of the 100..
This is most amazingly true. Got to forward to all programmers in my office
Pingback: Pragmatische Softwareentwicklung | Code-Inside Blog
Pingback: The software engineer’s life | Irene's Internet
Too Good!!