coneblog

I was the dinner speaker the other night at a professional society dinner, and I gave my talk on tools for the project manager. One of the tools that I covered had to do with the problem of inclusion.

The issue of inclusion is simply this: have you included the right people in the current discussion or decision?

Click to read more ...

You have seen ugly code. You have probably written some yourself. The Tragedy of Ugly Code has reached epidemic proportions since the advent of Java and object-oriented techniques.

Click to read more ...

Pretty deep into this Incident Reporting System project, I find that the reporting requirements are a large and critical part of the system, yet undefined. I check back to the original estimate document for the size and scope of the reporting effort.

Good news – I had quantified the report count in the estimate. Bad news – it was a big number (20), and I only had 10 Mandays of budget for all twenty.

Click to read more ...

It was a week after the Design Review that I realized that I had a can of worms in the Reporting Requirements. I had the client on the phone. I asked for report samples to start the report building process. There was a brief silence on the other end of the phone.

The report samples weren’t ready. How about the reports from the old system? They were rethinking the reporting. “DingDingDingDing” – off went the worm detector, too late.

Click to read more ...

The Incident Reporting System was moving along well. We had just concluded a review of the Database design and the screen prototypes, with a successful outcome. But in a critical error, I forgot to scan the emerging design with my “worm detector”.

“Can of Worms” [n] ( informal ) a source of unpredictable trouble and complexity .

To open a can of worms in an IT project is to find an unexpected mess. I have always prided myself on my ability to anticipate where the worms are hiding, and to manage accordingly. But I missed the can of worms residing in the reporting requirements.

IT project management is all about managing risk, and you can’t manage the risk if you aren’t aware of it. Thus, the Worm Detector is a valuable tool in the PM’s toolbox. As in many other things, early detection and action is the key.

Find that can of worms, open it up, pull them all out, and sort them out by Size and Shape. Inspect each for a pulse. Separate out the dead ones, and store them in the Issues List as Resolved. Most cans of worms contain a high proportion of dead worms. These can be old problems no longer current; opinions not problems; things resolved but never documented; or undefined areas that have been “severed” with the scope axe.

But worms that you thought were dead have an annoying property of spontaneously re-animating themselves. The Issue List with the Resolution column completed is the tombstone that keeps a dead worm dead. And often, just an energetic cycle of identifying and documenting the worms, alive or dead, makes everyone feel better.

Back to the project: My can of worms here was the reporting requirements. I didn’t think to scan this area with my worm detector, because the reporting portion of the system is usually not a hiding place for worms. In the Modern Era (that’s after “banded” report writers like Crystal Reports arrived), report generation has not been a problem. The tools are so powerful and easy to use that 95% of needed reports can be laid out in the “WYSIWYG” (what you see is what you get”) tool in an hour or two each.

So what was the problem with the reporting in this project? To quote scripture: ““Legion,” he replied, for they were many.” – Luke 8:30.