Have you ever had to file "TPS reports"?

Question

No, not literally. Rather, do you have any red tape horror stories of policies that affected your ability to produce quality software? I'm not talking about general human resources or systems administration policies like this question, but policies that were directly targeted at the development process, such as bad source control policies, testing procedures, or bug tracking processes.

Please, no holy wars such as indents vs. spaces or bracing styles, but rather examples of loathsome bureaucracy, like the TPS reports of legend.

This is somewhat relevant to me as I've been reviewing my group's development process, and I'd like to see (for context) some of the worst processes that you've had to deal with. When does a structured policy or process go too far?

Answer 1

I quite literally file TPS reports for one of the systems where I work: http://tps.tmccom.com/

And yes, I am very much aware of how outdated and non-standardized the site is.

Answer 2

As a contractor, I've often had to file three separate time and expense reports.

1. Our official report used for invoicing.

2. Our project-specific fine-grained report. It has to match the aggregate invoicing report. And, it's available to project managers two weeks before the numbers from the invoices.

3. Out customer's activity reports. These have to match the aggregate invoicing also. THe customer's accounting folks need this to confirm our invoices. Wait, didn't I create the invoices, also?

Let's not forget the need for two status reports (ours and the customers.)

Answer 3

For the last several years we had to fill out a leave slip, signed by our first line supervisor, in order to take sick time or vacation.

Recently we were given access to a fancy web-application. It allows workers to request leave and allows supervisors to approve leave. It rolls up into our time sheet and it's the basis of our payroll system.

Despite tremendous success in rolling out the new leave request system, our office manager still required us to submit the paper leave slip, in addition to doing it on-line.

It took months before the office manager realized the new system provided just as much oversight as the manual system.

Answer 4

No, but a few years ago I wrote the bulk of the MLI (Mandatory Liability Insurance) system for the State of Alabama...

Every report that the system generated was a TPS report :)

E.g. The Monthly Transaction TPS Report, The Daily Volume TPS report etc.

It was most amusing when someone from the State would call us up asking about the TPS reports :) I don't think they ever figured out why they were called TPS reports.

Answer 5

At a previous job at a large old computer company we had a CRT process. I wouldn't say it was a completely awful over the top idea since the software product involved high-availability computing and was thus very risk adverse. But it was annoying at times and certainly slowed down developement.

Basically, the system was, after having your code peer reviewed by 3 people, you filled out a CRT form (which at some point I converted to a web application).

The CRT (Change Request Team) would review all the requests a few times a week and discuss with management, team leads and the coder in question to ensure all the hoops had been jumped through: All the tests written... appropriate people had reviewed it ... QA informed of new tests... etc.

Thankfully the web application version was well accepted and the old manual form... which was really detailed and over the top was dropped. At least from our organization......

Answer 6

I currently have to outline my time in three separate utilities:

• I enter my time at a high level (consulting time vs. holiday vs. vacation vs. sick, etc) for a period one week, showing hours worked per day on each. This one is for billing the client.

• The client has a time tracking system that they just rolled out in which we have to enter our time at the request level. Admin time for client-related things (meetings, training, etc) has it's own general purpose bucket. Non-billable items have another. This one is for a period of one month, showing hours per week.

• My company also has a time tracking tool, detailing everything we did in a given week. Time is tracked on the quarter hour, and is extremely fine grained. i.e. "For request 12345, I spent 0.25 hours writing an estimate, 0.50 hours writing a requirements document, 0.50 hours coding file x." Estimates also have to be entered into the system, and effectively locked down (Waterfall FTL!), before we send anything to the client for approval (long before anything is coded).

We also have a very strict peer review process. Anything official that we send to the client (requirements documents, change requests, code, etc) have to be peer reviewed first. The client also has a Change Control Board which meets once a week to approve anything that will be installed into production.

I once explained to some friends from college exactly how much process and paranoia surrounded my work. By the end of it, I'd figured out that the hypothetical situation where (in a non-emergency, non-production support situation), the estimate for adding a single field to an existing report, after all the process was taken into account, was three hours at the ABSOLUTE MINIMUM for what would essentially be adding a single field to an existing select statement (or something similar as we use a tool which doesn't use SQL for DB queries). Additionally, since the estimate for this would be so small (since that three hours represents ONLY the required 0.25 hour minimum for each required item, plus half an hour for the production change control meeting), I'd need to get my team lead to sign off on it first, since I'd be going so far against what our estimating tool says it should take me to change the code (this tool is largely based on LOC).

*sigh*

I think that's enough ranting for today.