Systems Development (3)
"Perhaps the reason for most of our problems lies within the nature of systems development itself, since we find ourselves today building a system that was defined yesterday but will be implemented tomorrow" ...
[Legal & Financial Guardian, 19 March 2007] Systems Development (2).
--------------------
Someone might argue that every building effort in the world exhibits the same kind of pattern, but I would reply that we are talking about the only information-processing building effort. The fastest element to change in our world is information, so our problem bears no resemblance to any other building process. On the other hand, why don't engineering works have the same type of standards? For example, why are there not common procedures in, say, designing a new car or bringing any other new gadget to life? The effort in building any kind of management and financial information system is made much more complex than traditional structures because of the human factor.
As a simple example, consider house building standards. There are many books that describe the process of building a house, so that we can predict the actual cost and time it takes to build one square foot of wall. But, there is no standard to predict the cost of satisfying someone's personal choice of co-ordinated curtains, furniture, floor-plan, garden layout, etc.
At systems level we have exactly the same problem. We can predict the cost of writing 100 lines of code and compare performance to any standard we wish, but actual systems building and implementation is much more than that. In fact, coding is accepted to be no more than 20% of the actual time and cost (and probably also no more than 20% of problems arising from systems design and implementation), so we see that fairly good estimating standards exist for only about 20% of our project. So, how do we budget for the other 80%? How do we estimate the time the user will take to reach a fairly good user specification? How, for example, do we handle the ever-present change requests?
At this stage it is probably worth addressing some of these problems in more detail:
User Evolution in Time –
The user who defined the system some time ago is normally not the one that derives the benefits. Also, and more importantly, today we work with a third user and when we reach implementation stage yet more people will be handling our system. In other words, we build according to instructions from somebody that has gone and we expect the next customer to accept the finished goods.
Technology –
Technology, for example, that was available when the system was requested may now be obsolete. It is likely that a different technology, or variations/adaptations to the existing package will be available either when the system is implemented or at a later stage.
Change -
As time passes, new technology and fresh users will generate changes. The organisation as a whole will also request changes, as it is forced to adapt and adjust to a changing environment.
As a quick guide there are generally three elements under permanent potential change during the development of any system: the client, the problem and the available tools. This particular issue explains, in basic terms, the requirement and need for a Project Manager - who himself must be prepared to face continual changes within the systems process. A colleague once suggested to me that a Project Manager should be prepared to face anything.
A quick way out of this difficulty is to freeze requirements. However, this is not only impractical but may even be suicidal: changes are inevitable, and all of us must accept that some of them might well be outside of our control. In fact, we ourselves should expect to operate in any organisation as 'change agents'.
On ending this topic today, I would like to draw readers to the feature that is becoming so important within any systems development programme: it is a SERVICE. This means that when a client comes to us, he has a problem that probably requires a dedicated approach to problem solving. It doesn't necessarily mean a quick-fix approach as this philosophy generally renders weaknesses in itself. As a service, whether it be within systems development or within certain areas of finance, we are somehow doomed to varying degrees of criticism.
I will now offer a definition:
... In my opinion systems development is a service intended to implement a technological change in a highly dynamic environment, a change that is necessary in maintaining a competitive edge. This should not necessarily imply a cost-base that is increasing because, by definition, systems should be designed in creating economies and greater effectiveness.
