The company where this pilot fish works has had its share of death march IT projects, so it launches a big effort to improve estimating and project delivery.
“As part of that effort, project time would be recorded to provide baseline data for future estimates,” fish says. “Everyone was also trained in function point analysis so there would be some consistency to project sizing.”
Not surprisingly, some programmers don’t like the idea of their productivity being closely measured. But the hope is that the result will be better project size and time estimates — and a lot fewer death marches.
So pretty much everyone gets onboard with recording their project time — at least until the reports start coming out, showing the total number of hours everyone is working.
Turns out there’s a lot of unpaid overtime being worked in IT — and the detailed timekeeping makes that impossible to ignore.
And it’s clear just how unhappy that’s making someone in the management chain when orders come down for a slight tweak to the project-measurement effort: Going forward, everyone is to record 40 hours of work per week.
Sighs fish, “It was less than a year before the entire software metrics program fell into disuse. With incorrect baseline numbers, there was no improvement and no learning.
“The crazy hours and impossible deadlines remained, justified by the numbers that were recorded. Staff were blamed since the numbers ‘proved’ they could complete the work in time — even though everyone knew the numbers were wrong.”
In between crazy hours and impossible deadlines, howzabout sending Sharky your story? Email your true tale of IT life to me at firstname.lastname@example.org. You can also comment on today’s tale at Sharky’s Google+ community, and read thousands of great old tales in the Sharkives.
Get Sharky’s outtakes from the IT Theater of the Absurd delivered directly to your Inbox. Subscribe now to the Daily Shark Newsletter.