Promises, Promises
By Russ Finney
In system building at the implementation stage, one fact is certain, the promise is always remembered and the conditions of the promise always seem to be forgotten. This is especially true if the team has been living in a construction phase vacuum. The best way to avoid this situation is easy - don't go off to a closet and build the system. When discussing detailed functional issues, create an atmosphere in which a client can participate. This is extremely important if it becomes necessary to fudge on a promise. There is an old saying that bad news does not improve with age, and it is appropriate to consider that fact here. The earlier the client is aware that an alternate approach will be implemented, the easier it will be to arrive at a compromise solution which will meet the business requirements.
Including the client in the decision process during construction also helps to reduce the project risk. In many cases the team may have just walked five steps down the wrong road, and the client brings them back to reality. To experience real tension, surprise a client during the acceptance test with a newfangled change that misses the mark when it comes to handling the crucial business needs. The team motto during construction needs to be: no client surprises!
Keeping promises, especially when faced with actually implementing them during construction, is a challenge. For some reason, technical limitations have a way of thwarting the best intentions. It is at this point that teams develop convenient memory loss. Did we really tell them we would do that? They must have known that it might not be possible. Surely if we do it this other way they will understand. What choice will they have after it is built anyway? This is a risk which is easily avoided. Just tell the truth. Yes, it may be a little uncomfortable, but by involving the client in making the alternate selection, the chance of acceptance increases dramatically. The purpose of Acceptance Testing should be to examine and prove the functionality the client is already aware of, not to see if the client will accept all of the construction imposed changes.
Who is the Real Owner?
The team has spent months or years developing the system. They have all put a little part of themselves into the effort. If things have gone well, the team may even consider the result to be a reflection of themselves and their abilities. No one knows all of the features and capabilities of the software better than the project team. It is truly their system. But is it? Now it has to be given away, to clients who have no real appreciation of what it is they are really getting! This is both a high point and a low point for the System Builder. To some, it is like spending years creating a great work of art, and when it is finally completed, hanging it in someone else's living room, never to be seen or enjoyed again.
Fortunately, the real pleasure comes in watching the system go to work. This is the real reward to the system building professional. The first real check that gets generated, or that first invoice that gets mailed, or the first customer request that gets handled through a new screen, those are the rewards, knowing that you have actually made a difference in the day to day life of the business. But letting go is not easy. It all begins with documentation, training, and acceptance testing.
Copyright © 1999, Russ Finney, All Rights Reserved