Thursday, October 12, 2006

Suburbia And Downtown

01/14/2006

Suburbia And Downtown

Oh boy, how cold these evenings are. Today has been one of those days when the temperature drops below zero (Celsius of course) at five pm. Coming home in the cold enhances the feeling of tiredness

At home, Poldina noticed my state of mind, and asked me why. The answer was simple. That day I planned to go on with a project of mine, but I was unable because we received a lot of support request from our customers. Many of them were urgent, and I had to leave everything behind to sort out the calls.
As usual, Poldina dropped a pearl of wisdom:
“Do not complain about that, it’s only your fault.”
“Why?” I replied.
“Because you, as a consultant, can not take charge of your customer’s daily job.”
“Maybe you’re right, but in this way they feel that we provide a good service.”
“They would be happier if they had not to call you.”

True.

Let’s start from the beginning.
Shrinkwrap software development is a difficult exercise to all aspects, but consultingware opens an entire new class of problems.
As usual a customer asks you to build a system (not a micro one, of course). With diligence, you go through the analysis. After that, you write down detailed specs. After that you plan carefully all your development and testing. Let us suppose you do your homework and start developing.
Of course, despite your best efforts, in this phase you will have to face unexpected issues and specs refinement or changes. This is normal.
Experienced project managers all agree with the immutable law that software is like wine, it requires an exact amount of time to be ready to be delivered.
The late shrinkwrap software developer has the choice to leave out some features from the next release and often the luxury to announce the release date when there is each reasonable guarantee to meet it.
The consultant who is developing a custom system must meet the deadlines, because the risk is not to be paid and start losing money while struggling to complete the project.
An experienced project manager does not fall in the trap of start coding like crazy throwing away the schedule or adding people to a late project, but scraps his head, browses the specs and the contract, and picks the tasks which can be left for last and can be delivered a bit late without spoiling the whole.
What are the candidates for such a choice?
Often, among the others, they are the tasks which pertain to the management of slowly changing data. They may be user security settings or some data quality constants. Maybe some translation tables are left unmanaged. Anyway, it is always possible to use a database utility or a file editor to change them, if required.
The final result is a system delivered in time, and this is good, but it is not under the customer’s complete control, and this is very bad.
Worst of all, this is bad for you, the consultant, not for the customer. The customer will simply call in and will ask you to do the job.
Often, once people start moving to the next project, these gaps are never filled and the customer calls remain an extra amount of maintenance for a long time. Worst of all, again, this activity often goes unpaid because what has been left should have been included in the system.
The net result is made of days like today, days of retard on your following projects. A small amount of applications like this may spoil your potential to complete more projects.

Then, what should be done to avoid this pitfall?
Well, the first answer is obvious: plan carefully enough not to risk being late.This is easier said then done, of course, but you should try to do it anyway, is it?
A second option is to accomplish these tasks first. Often these parts pertain to interfaces and security, and setting them up early may be considered as a part of your overall risk reduction strategy. Your boss, also, will perceive them as a preliminary and will not press you to produce “measurable progress” as the true work has not begun yet. Going late will not produce a lame system as you complete the core.

We may generalize this approach. “Top-down” and “bottom-up” approaches are often discussed, but the “suburbs-downtown” approach is hardly mentioned in development and project management texts.
“The kernel is ready; we must only trim and had a bunch of interfaces”
“The core works ok, I must only throw in only few functionalities and the system will be ready.”
I’ve head this phraseology so many times that I can’t count them. This sounds also as a reassuring statement for non experienced managers, both on customer and consultant side. Well, this does not mean for sure that the job is on the other side of the hill.
In well-organized town, with an acceptable life quality, you’ll find a downtown where the productive life is concentrated (the town hall, public and private offices etc) and suburbs where people live quietly and confidently with the services they require located near them.
So is any reasonably large system.
Do not expect customers be comprehensive about the roughness of system management and interfaces; they will expect it to run smoothly most of the time. Sometimes, when in hurry, they’ll say to be ready to accept roughness but be sure that they will soon start complaining about shortly after deployment.
A not-so-happy customer, of course, is likely not to ask you for more consulting twice.

So, as usual, Poldina was right. It was up to me and my coworkers to reduce the constant flow of incoming calls. I’ll keep in mind
.

0 Comments:

Post a Comment

<< Home