coneblog

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.

On this Incident Reporting and Analysis System for a large Pharma Manufacturer, we were on a tight schedule and almost done with a prototyping iteration. I had sketched out the logical data base model, and my developer had a set of screen prototypes in Visual Basic ready to review with the Client.

Click to read more ...

Systems done for a regulated pharmaceutical manufacturing environment have some unique characteristics. They must emulate the older paper form information management techniques. In this approach, all entry was done in pen. There were no erasures allowed, just strikethroughs and neat re-entry right above, initialed and dated.

That way, you could see both the original entry and the changes. In a system, however, this means rethinking normal user interface approaches. No editing of fields in a way that looses the original value!

There are both data base and user interface implications to this requirement. In the data base, you could change a record, but you had to keep the original record. In the User Interface, both the “final” value and the “original” value, and any values in between had to be displayed. In the printed version, the form was printed in the top half of the page, and a change log was printed in the lower half. It was a challenge to mimic the paper strikethrough process throughout computer storage, presentation, and input.

Here is a great example of a subtle but real status field. Clearly, it was unworkable to prohibit a free entry and change process during the origination of the document. It was not reasonable to log every error, misspelling, and change in the initial data entry. So, we used a two step form creation process – Entry and Commit. Before the document was Committed, the fields could change freely. After the document was Committed, every change to a field was logged and retained. And, of course, we needed a status field to tell the system whether the document could be edited freely or not.

This “Entry Status” was critical to the proper functioning of the system, but didn’t show anywhere in the business flow analysis or the existing forms. This design element popped out of the prototyping process.

There is a role for both iterative prototyping processes and sequential “waterfall” processes in software development. I find it is not “either – or”. The trick is to know which mix, or “recipe” to use for any given project.

But that is a whole ‘nother topic.

We were deep into design in the “483” project. As described, in this project process the Design Document is done last. So, once we had a good idea of the data design, we started building screens. We used an iterative process with multiple client reviews in short order, as time was limited. The Tech Writer started to document the data model, and build a Glossary – the most overlooked part of project documentation. And I worked on the Issues List, which later ended up saving my butt.

Click to read more ...

The Client was in a big hurry, so I turned around the software development project estimate in less than a week. The ball was in their court. So I was surprised when the Client called only two days later.

“You have the Job, but you have to deliver on the dates that you quoted,” Said the Client. No mention of the original eight week deadline. Great! We had the job, in record approval time. Now we had to deliver.

Click to read more ...