coneblog

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.

In this type of quick turn-around environment, things are wild and wooly. The nature of the relationship is that you are done when the Client says that you are done, regardless of what the Spec or Estimate might say. After all, they are the International Big Pharma company, and you’re not. Also, The Client would prefer to wait as long as possible to make decisions of look, content, and functionality. Being risk-adverse, they want to reserve the right to change things at the last minute. It is your job as the implementer to capture the many little decisions made along the way. In this way you can gradually (or not so gradually) constrain the Universe of possible systems into the one that you will end up implementing.

And it ultimately falls to you, the implementer, to insure that the system will work operationally. Users are legendarily unable to envision how a system will work from any known Software Process Documentation; Unified, Rational, or Otherwise. User Management is worse. Communication (or lack of it) is the CORE PROBLEM in systems development and delivery.

It is the rare user who can see the whole future system from the cut out pattern pieces that we review with him or her during design reviews. It is you, the Manager of the Implementation, who (hopefully) has seen a few systems, who can mentally piece the garment together, and make a guess as to how well it will fit. A skilled team can do some tailoring late in the game for a better fit, but if you left out a sleeve, no amount of tailoring during testing is going to make the system work.

So you must know business as well, whatever the business is. If it is Tugboats, you need to understand Lightering, Ullage, and Trip Segments. If it is Locomotives, walk around the shop and learn about traction motors and the baking of armatures from the old-timers. Let them drive you out to the traction motor graveyard, solemnly view two or three hundred lumps of metal rusting in neat rows in a gravel yard, and listen to them wax philosophic about long gone Traction Motors and the Locomotives that they drove. If it is foreign exchange trading workstations, well don’t even start, because you will never, ever understand the Options and their Settlement.

Point being, your best Risk Management strategy is to talk to the people doing the work, and really understand what they are doing, and why. Then you are in a position to design the system for them. Don’t risk all on hoping that they know what they need, or will recognize a necessary and sufficient system when they see it; because they don’t, and won’t.

Plus, there is a wonderful benefit hidden in all this walking around the shop and chatting up the workers. As they come to understand that you are genuinely curious and interested in what they do, they will give you every benefit of the doubt, and will not grumble up their management chain when you make the errors you will inevitably make.

And there, in the midst of the dark roiling mass of requirements, personalities, processes, and politics, at the meeting of a reasonably good system and a user group willing to suspend disbelief, is the main golden chance for delivering business advantage through software. Grabbing that chance is what I’m all about.

But we aren’t there yet on the 483 project.