Writing on the Malay massacre in Maybank series allowed us to learn few basic matter on IT system development.
It is not as easy as customer want this, this and this and voila it is done. It is as complex and problematic as depicted in the picture above.
At the height of the Internet boom and we had pursued a portal idea, it took our younger sibling to get us to understand that IS development planning is not similar to conceptualising business planning.
In business planning, there is the luxury of looking at a macro level before fine tuning it at a more micro level. IS development require s the whole business process and nitty gritty workflow must be known and planned out before the developer comes in.
Part of that portal idea is what is today blogspot.com.
In the course of writing the series, we realised that both government and commercial entities may have wasted lots of money in IS development in this country.
Commonly heard is the wasteful redoing of the entire system development to meet the bosses fascination for new technology and application. As a result, the major core and essential effort in the knowledge on the business process and workflow is lost.
Usually customer do not know what they really want. Seldom the case they are not clear what they want. To the developer, customers could be redefined as end user and client.
End user will be the front end people using the supposedly user friend system. Seldom the case, end users only wants a certain features or gadget as used by others but not bother with the whole requirement.
While client are manager having control or influence over the initiation, direction or progress of the project. They are important because clients hold the purse to pay developers. Client requirement have to be made known to the developer. Client's can be fickle minded too.
An inexperienced and lacking knowledgeable client only will assure the eventual failure. A 2005 study by The Standish Group concluded that 70% of software project fail.
Seldom the case, the problems in software development (for that matter system development too) arise from "Poorly written requirements, unrealistic schedules, inadequate testing, adding new features after development is underway and poor communication." [read it on here]
The problem is not so much technical as in the machine, programming, software or integration but the bulk of the problem lies with the people and management issue. The responsibility lies with the final decision maker among the clients.
Did he or she made well informed decision? Have they taken account of all the factors and risk possibilities? Does the decision maker listen well or heed warning or issues raised by their subordinates?
We use to be a shareholder in an SI company. It is common to hear clients say things really irritating on a latter date. "If I’d known the real price, I’d never have agreed,” they say.
There are those that said, "It’s no use delivering it now, we needed it last so and so date!” Another version of their complain sounded like this "OK, so it works, but the installation was such a mess my staff will never trust it.” or "I didn’t want it in the first place.”
New bosses enter a government organisation and they come in with some new idea/s or ulterior motive/s. It is common in Malaysia to hear "Everything has changed now, we need a completely different system" so spent some more of peoples' money.
The IT companies will react. “We built what they said they wanted." It is quite common to hear they say, “There wasn’t enough time to do it any better.” Most common would be “Don’t blame me, coz it is them that listed the requirement in such manner."
In certain cases where client came to developers for problem on a system designed by other, the answer would be “How can I fix it? I don’t know how it’s supposed to work."
The IT management in Maybank was a client that would have the vendors scream, "We said it was impossible, but no-one listened." It is also possible that "The system is fine. The users are the problem." That will be the issue to be raised on system supplied to government.
So one of the most common recurring problem in development is knowing what the client want. Taking out of a website here, their advice is:
Clear Initial Requirements
Before starting any development project one must clearly know what the client’s requirements are. Unfortunately sometimes what the client wants is not what the client needs. It is the job of the system analyst to identify the requirements.
This does not mean that the client does not know what he wants from a system but it’s often the case that the clients describes the system how it can solve the current problem.
The system analyst must make sure to clearly understand the problem, the workflow that is leading to this problem and to identify ways how the system can work to solve the current problem while optimising other workflows.
The solution is to have one person who is in charge to write the requirements document, .... sometimes taken for granted due to time constraints or budgets.
Read on here.IS development
From an operational viewpoint, we move to IS development itself. A website on a thesis written [read here] highlighted the problems that lead to The Standish Report claim that 75% of all IS development failed.
The important issues are low productivity, a large number of failures, and an inadequate alignment of ISs with business needs.
Low productivity in IS is in the areas of development backlog and maintenance problems. Demands for building new or improved ISs have increased faster than the ability to develop them.
A large number of outright failures are due to economical mismatches, such as budget and schedule overruns. Often it is due to poor product quality and insufficient user satisfaction.
The Standish Group survey for 1995 found only 16% of all projects are delivered on time and within their budget, 31% of projects were canceled prior to completion and the majority, 53%, are completed but over budget and offer less functionality than originally specified.
From the business point of view, there has been growing criticism of the poor alignment of ISs and business needs. An increasing part of organizations’ resources are spent on recording, searching, refining and analyzing information.
Then, each generation has brought new application areas as well as extended functionality leading to larger systems, which are harder to design, construct and maintain.
All in all, it seems to be commonly recognized that IS development is not satisfying organizations’ needs, whether they are technical, economical, or behavioral.
In conclusion, IS problems goes back to human and knowledge. So it is not so much about machine, or technology but the management by human to put knowledge and machines to work in synchronicity.
All leads back to the Maybank issue [read here, here, here and here for an active on-going debate] and a return to an issue this blog had pursued before at the tender stage.
The other issue to come next week. Which organisation now?