coneblog

I’m working the problems in this Incident Reporting System project. I’m using a Punchlist to try and define and manage the remaining scope on the one area that refused to Jell – the Reporting Requirements.

I’m having twice-weekly sessions with the Client to review the Punchlist, check off completed items, and add new ones. And I’m gaining ground, until some changes to a management report must be reversed back to the way they were originally.

It was one of these situations where the Users wanted more information on a report. When they saw the results, they realized that the report had become crowded and unworkable, and decided that indeed they liked it the way we had it originally.

How to handle this? Can I refuse to change it back? Can I smile and make the changes back to the original? Can I complain?

I chose to invoke one of the rules of IT Project Management – the “No U Turns”, or “No Backsies” rule. This rule, as documented in the undocumented manual of IT Project Management, reads something like this:

“Yes, Mr. Customer, we will make whatever changes that you request, providing that such changes do not cause us to redo work that you have already requested, or specified. In the situation where your requests cause us to redo already requested or specified work, we will still make the changes, but we will consider such changes additions to contracted scope, and bill you accordingly.”

Most systems require a good bit of last minute tailoring and fitting. This is because, in most cases, it is prohibitively expensive to have EVERY LAST DETAIL documented as part of the design process. So, many of my “Punchlist” items represented minor layout details, changes in column widths to accommodate wider data, addition of summary items at control breaks. A natural part of the “fitting” process, and, with modern reporting tools, usually cheaper that specifying the layout in detail in advance. Also, many of the Punchlist items were thinks that were just wrong, and needed to be corrected.

But for those few items which represented a “change of mind” on the part of the Users, we added them to the scope change list, and charged for the incremental hours to do them. This, paradoxically, speeded up the process, because it gave my Client PM counterpart some ammunition to stop thoughtless changes from the Users (“I’ll make them change that, but then you will have to live with it, because they will charge us to change it again!”).

So with the invocation of the “No U Turns” rule, we were sprinting towards the finish line.