BIL used Microsoft’s .Net Framework for development of the project using C# language.
3.3 Kick off meeting and initial settlements: The kick off meeting was organized. It included the CEO of both the companies, MR. Surana, for HEG and Mr. Sanjeeva Dubey, for BIL, along with the full marketing team of HEG and the team of programmers of BIL. The price of the project was settled very nominal, as it was the group company and the sole owner of both the companies was same, Mr L. N. J. Money just had to go from the accounting books of one company to the accounting books of another. Duration of the project was kept six months, with no logical reason, as at this point of time, nobody was actually sure about the scope of project.
4.0 BIL started working on project: For BIL, it was not very big project. They didn’t see much profits coming out of it. They appointed the team consisting of one project leader, three programmers and a trainee. Their detail is as follows:
1). G. A. Kanna: Team Leader: A Software engineer by qualifications. That time, he had four years of development experience. His position was “Software Engineer” but just for this project he got the role of “Acting Project Leader”.
2). Chanderpreet: Programmer: She had three years of programming experience and had done Masters in computer application.
3) Vyom Agrawal: Programmer: He had four years of programming experience. He had done his degree in Mechanical engineering.
4). Vikramjit Sharma: Programmer: He had two and a half years of programming experience and had also done Masters in computer application.
5) Pancham Gupta: Management Trainee: He was in final year of Bachelor of Engineering degree. He was the part of the team, as it was the part of its curriculum of the university.
As we can see, it was not very week team in terms of experience and qualification. But they all chose to develop this project in “.NET Technology”. It was the very new technology introduced by Microsoft Corporation Ltd., only few months before. None of the members of team had ever worked in this technology but still they chose to so that they get the working knowledge of one of the very new and hottest technology.
5.0 Quality System at BIL:
BIL is a Software Engineering Institute-Capability Maturity Model (appendix 1) level 4 compliant company. Software engineering encompasses:
- Combining comprehensive methods for all phases in software development
- Better tools for automating these methods
- Better techniques for software quality assurance
They have one full department on Quality Management in the company called “Software Engineering Process Group at BIL”(SEPG). It serves as a means of providing defect free software and services that conform to the specified requirements.
The Quality Management System at BIL conforms to:
- IEEE standards (which form the backbone of Quality Management System documents)
- ISO 9001: 1994 standards
- Software Engineering Institute's Capability Maturity Model
The meaning of Software Quality:
- Meets user requirements: It is the primary measure of software quality. No matter how good or sophisticated the software is, it is of no use if its not as per the requirement of the end user.
- User friendly: User should be comfortable while using the software. It should avoid unnecessary complexities.
- On-time delivery: If the client doest get the software when they needed it most, it is either of very less value or sometimes it is of no value at all to them. So software quality also includes on time delivery.
- At reasonable cost: It is very difficult to find out the reasonable cost of the software though. But in any case, it should not be more than what the client is expecting to get out of it.
- After delivery support: Quality is the on going process. It doest stop at the time of the delivery of the project. It also included assisting the client with the usage of it, correcting the minor defects etc.
- Compliance with established standards: It includes the documentation of all the stages, proper coding and indentation etc.
5.1 Cost of Quality: It can be argued that quality is the cost to the company. The figure below shows the various head under which the quality can cost to any company.
Fig: The cost of Quality
As shown in the figure above, quality may cost the company a bit in the form of salary of staff, training and maintaining the procedures but saves the lot of rework and gives the assurance, to a major extend, about the successful completion of the given project.
The Software Crises
- Schedule and cost estimates are often grossly inaccurate
- Customer dissatisfaction with the “completed” product is encountered too frequently
- Software quality is often suspect
- Existing software can be very difficult to maintain
6.0 Literature Review:
6.1 The cost, feature, product spiral
Economics determines the success of any software project and its value to a company. The amount of money spent on development determines the cost of the asset. The return generated by the product is its value. The difference between the return and the cost is the return on investment (ROI).
Economics of Adding Features
Figure 1. The ROI of a product is the difference between its cost of production and its return. If the return is greater than the cost of production then it is said to possess a positive ROI.
Organizations must consider the cost of adding features to a product. Figure 1 shows a software project whose returns outpace the cost of production, thus producing a positive ROI.
Figure 2 depicts a product that initially has a positive ROI, but whose added features cost (marginal cost) more than the amount of return generated by the features. This initially profitable product becomes a drag on the company.
Figure 2. ROI is said to be negative if it costs more to product a product than it generates.
Figures 1 and 2 are deceptive because under most software processes, the cost of changing software is not linear, but exponential. Brooks (1) attributes the exponential rise in costs to the cost of communication. Changes to software include new features, bug fixes and scaling.
The effects of exponential cost of production can be characterized by three properties. First, new projects are successful because the cost curve is flat. Second, once the costs start increasing, they quickly overcome any additional value added from the new features. Finally, if changes are made after the costs become exponential, the additional costs will quickly overwhelm all returns garnered from the product to date. Figure 3 details the effects of an exponential cost of change.
Figure 3. Exponential costs of change can quickly subsume the worth of any product.
Software processes are designed to manage the cost of change. Briefly, processes that follow waterfall and iterative models control costs by reducing need for change as costs increase. In contrast, processes based on the spiral model ensure that the cost of change is fixed.
Maximizing ROI means expanding the market and the addition of features which, in turn, increase the investment in the product. If the next version is successful, this increased investment leads to an even greater desire to maximize returns. If the cost of change becomes exponential, high cost makes adding features impractical and development must stop. Unfortunately, most companies do not realize this point exists and spend huge sums on dead products.
6.2 System failure: An information system that either does not perform as expected, is not operational at a specified time, or cannot be used in the way it was intended, could be called as a failure.
6.3 Measuring System Success: “Projects are there to fulfil the needs not desire”. It’s not very easy to agree about the value or effectiveness of a particular information system. Individuals with different decision-making styles or ways of approaching a problem may have totally different decision-making styles or ways of approaching a problem may have totally different opinion about the same system. Nevertheless, the following measures of system success are suggested by MIS researchers are considered as most important.
- High levels of system use, as measured by polling users, employing questionaries, or monitoring parameters such as the volume of on-line transactions.
Fig: Measures of information system success.
-
User satisfaction with the system, as measured by questionnaires or interviews. This might include users’ opinions on the accuracy, timeliness, and relevance of information; on the quality of service; and perhaps on the schedule of operations. Especially critical are managers’ attitudes on how well their information needs were satisfied.
-
Favourable attitudes of users about information systems and the information systems staff.
-
Achieved objectives, the extend to which the system meets its specified goals, as reflected by improved organizational performance and decision making resulting from use of the system.
-
Financial payoff to the organization, either by reducing costs or by increasing sales or profits.
6.4 Causes of Information System Success and Failure
Systems are developed in the first place because of powerful external environmental forces and equally powerful internal or institutional forces. Many systems fail because of the opposition of either the environment or the internal setting.
The concept of Implementation
Implementation refers to all organizational activities working toward the adoption, management, and routinization of an innovation. Figure given below illustrates the major stages of implementation.
Some of the implementation researchers focuses on actors and roles; the belief is that organizations should select actors with appropriate social characteristics and systematically develop organizational roles, such as “product champions” to innovate successfully.
A second school of thought in the implementation literature focuses on strategies on innovation. The two extremes are top-down innovation and grassroot innovation.
A third approach to implementation focus on general organizational change factors as being decisive to the long-term routinization of innovations. Actions to increase organizational learning and overcome barriers to acquiring new knowledge and practises are also useful.
6.5 Causes of implementation Success and failure:
Implementation outcome can be largely determined by the following factors:
- The role of users in the implementation process
- The degree of management support for the implementation effort
- The level of complexity and risk of the implementation project
- The quality of management of the implementation process
These are largely behavioural and organizational issues and are illustrated in the figure given below.
Fig: Factors in information system success or failure.
Lets look into each and every factor individually:
1) User involvement and influence: user involvement ain the design and operation of information systems has several positive results. First, if user are heavily involved in system design, they have more opportunities to mold the system according to their priorities and business requirements and more opportunities to control the outcome. Second, they are more likely to reach positively to the competed system because they have been active participants in the change process itself.
2) Management Support and Commitment: if an information systems project has the backing and commitment of management at various levels, it is more likely to be perceived positively by both users and the technical information services staff. Both groups will believe that their participation in the development process will receive higher-level attention and priority.
3) Level of Complexity and Risk: systems differ dramatically in their size, scope, level of complexity, and organizational and technical components. Some systems development projects are more likely to fail or suffer delays because they carry a much higher level of risk than others. Three key dimensions that influence the level of project risks are Project size, project structure, and Experience with technology.
4) Management of the implementation process: the development of a new system must be carefully managed and orchestrated. Each project involves research and development. The conflicts and uncertainties inherent in any implementation effort will be magnified when an implementation project is poorly managed and organized.
Figure: Consequences of poor project management.
But the benefits of an information system may not be totally quantifiable. Moreover, tangible benefits cannot by easily demonstrated for the more advanced decision-support system applications.
6.6 Project Failure – Root Causes
-
Improper estimates: Once the estimate is given to the clients, it’s very difficult to get it changed. Most of the time, either because of lack of understanding of the project or in a mad race to bid lower than others to get the project, the estimation is not proper. Which later on becomes the cause of concern. It not only de-motivates the staff but also sometime become the sole reason for the failure of the project.
-
Poor understanding of user requirements: Understanding the client’s requirement is not a easy job. Some time the projects are that much big or they involved lot of complexities that the project managers are not able to understand it properly. And if they are not sure what is to be done, there is no way to get it done properly from the team.
-
Tight schedule agreed under pressure: Working under the tight schedule is some time healthy for the organization. It stimulates the employee to work faster. But setting some sort of unrealistic target may become the reason for the failure of the entire project. In a hurry to complete the project in time, programmers start compromising on the quality, which eventually leads to the failure of the project.
-
Poor monitoring of schedule programs: It’s very necessary that the project is monitored through out its tenure. In absence of proper monitoring or poor monitoring of it, can become the reason for its failure.
-
Undue optimism, tendency to ignore risks: Too much optimism can also become the reason for the failure of the project. In this process either you totally ignore the risk or don’t give it the deserved attention. One small tiny problem can later on take the shape of big monster like problem and can ruin the whole project.
-
Poor programming: Projects depends on humans and their skills. If the programmers are not very efficient in their programming skills or they are not exposed to that particular technology, in every way the project is bound to fail.
7.0 HEG Project: The project was completed after eight months of its start. But it was never successful. In the light of literature review we have done above, lets examine the factors that went against the HEG Infoway project. The following problems came immediately after the implementation of project.
1) Half-hearted implementation of software by HEG marketers: HEG marketing department was using some sort of small Access software to do their normal marketing jobs for ages. Now they got so used to it that they showed their reluctance in using the new software. It was painful job for them to first understand each and every part of the software and then start using it. More over, the way this project progressed; they didn’t have much confidence in it.
2) Key programmers left the company: Out of the team of four programmers, two of them left the company. They wanted to leave the organization even before the delivery of the product because of some personal reason, but were held by the company till the completion of it and as a moment it was finished, they left the company. Of course new programmer didn’t know anything about the project.
3) Difficult bug fixing in absence of proper coding standards: As stated above, this project was not properly documented. And in absence of adequate time, it was badly indented and not many comments were provided. In absence of all these, it was very difficult for the new programmers to fix even a small bug.
4) Incomplete functionality: Although all the modules were completed by the development team, but the client was expecting lot more functionality from the software. Like, some ten reports making facility were included in the software but the client was expecting the reports in the range of hundred or more. In absence of it, they lost the interest in the software.
I
7.1 Reasons for the failure of HEG Project:
-
Bad project management: Projects depends on people and their talent. Project management skills plays as important role as programming skills in the development of project. Kannan, who was working as a software engineer, led this HEG Infoway project. He played the role of Acting Project Leader. This was his first time and he could not do justice to the role assigned to him. He was too soft and could not handle the aggressive clients and their ever changing requirements.
-
Poor documentation: Neither the client nor the programmer understood the actual importance of documentation and role of Quality management system. When the “System Requirement Specification” was send to the client, which was having the full scope of the project, they just signed it without even reading it properly. They might have thought it’s the group company and they will keep the requirement changing as and when required. And for the programmers, it was very small project and they had to complete it under the time stress. So they didn’t want to waste this time for documenting each and every part of it.
-
Bad estimation: The cost of the project was fixed too low. For this reason, the management of BIL, never had real interest in the progress of the project. They just wanted to get rid of this project at the earliest. That is the reason, when ever kannan approached them with his genuine problem, they always advised him to choose the short cuts.
-
Poor client involvement: As discussed above, clients involvement is very important for the betterment of the project. But it is a headache for the client to leave their important jobs and spend time on the description of the project. Programming team at BIL faced lot of problem in getting the appointments from them to understand the project in a better way. So whenever they got an appointment with any of the marketer, the team cleared their doubts form him. But the fact was, every marketer had his own ideas about the project and the others never appreciated that.
-
No processes were followed: No actual process was followed in the making of the project. Team kept on working on what ever came in their way. It is not very healthy for any project. It was a failure on BIL part that it happened that way inspite of such a robust quality department in the company.
-
New technology: For their own interest, the team suggested to do this project in the latest technology called “.Net”. Client in the good faith accepted it. But the fact was that, none of the programmer had actual experience in this technology. Because of this, they came up with lot of extra problems and always chose some simple way out without giving the thought of its later severe consiquenses
-
Bad requirements study and analysis: The requirement study and analysis of the project was very bad. Team didn’t know how to handle the customer and his ever evolving and changing requirements.
8.0 Conclusion
As a conclusion, this report can state that, there was nothing wrong with the project. It was good project to do, and the fact that they tried to do that in the latest technology made it even more interesting. But the whole idea of it was wrong. As BIL decided to do that just to give favour to its group company. They estimated the project quite low, inspite of their financial crises, just to oblige the group management. That was totally unprofessional act. And their biggest blunder was to loose interest in the project in the mid of its development. Ideally speaking, once they had taken the responsibility of the development of the project, they should have taken every care in the successful completion of it. By this way, they could have used this software to convince the other clients for the purpose of getting more and more projects of that kind. More over, they would have listed themselves in the list of very few companies, who had developed the project in .NET environment using the C# language.
This report puts the whole blame of the failure of the software on BIL. It was failed because of the negligence of managers and thoroughly unprofessional and totally unorganised management skills.
9.0 Recommendations
The following recommendations can be made to the companies on the bases of analysis:
Instead of following the Standard System Development Life Cycle, SDLC, -“Waterfall approach” (Appendix 2), they should have followed the SDLC “Prototyping approach”. SDLC Prototyping is nothing but making a prototype during the High Level Design stage and showing it to the customer and accordingly change it as per the customers requirements. This process helps in saving a lot of effort in rework during coding phase. Here the team first coded the software and then made changes, which was the wrong approach.
As stated above in the conclusion, the companies should set their basic requirement for the project. Not matter what happens, they should stick to at least these basic requirements. Like in this case, they estimated very low, just to oblige the group management.
It was not a bad idea to give Kannan the role of “Acting project leader” for this project. Infect it was very encouraging not only for kannan but also for other members of the team, as it was purely on merits. But it is recommended, even in such cases, there should be active involvement of some senior and experienced project manager from time to time. This project could have been successful had kannan got the support and advice of any senior member of the management.
Bibliography
The Mythical Man Month, Brooks, F.P., Addison-Wesley, 1995.
Managing the Development of Large Software Systems, Royce, W.W., , IN Proc. WESTCON, San Francisco, 1970
Management information systems, sixth edition, Kenneth C. Laudon, Jane P. Laudon
Electronic References
[online:1] http://www.bhilwarainfo.com/group_profile.htm
Bhilwara Infotech Limited
[20 March 2003]
[online: 2]
HEG Limited
[21 March 2003]
APPENDIX
Appendix A
The scope of project can be broadly divided into seven parts.
- World Database Management
- Customer Management
- Offers, pending offer, offer Feedback
- Tour Report Management
- Order management
- Reports
- Admin module
-
World Database Management
- User will be entering potential customer contact details like company name, address, contact person, plant name, plant address, region located, country agent details, contact telephone number and technical details like each plant capacity, number of furnace, type of furnace, electrode requirement for each furnace, electrode diameter, electrode grade, electrode length and annual consumption.
- User will be able to search the World Database based on defined criteria like region wise, country, grade, diameter, length.
- User will be able to edit the information of particular potential customer.
- Upload from existing database.
- Customer Management
- User will be entering customer contact details like company name, address, contact person, plant name, plant address, region located, country agent details, contact telephone number and technical details like each plant capacity, number of furnace, type of furnace, electrode requirement for each furnace, electrode diameter, electrode grade, electrode length and annual consumption of electrode.
- User will be able to search the World Database based on defined criteria like region wise, country, grade, diameter, length.
- User will be able to edit the information of particular customer.
- Offer Management System
- User will be able create offer templates and auto generate the offer letter based on customer details.
- User up on requisition of pending offer, pending offer report will be generated.
- User can enter the customer feedback (like cost negotiation, competitors and their price etc) for the particular offer.
- User can edit the particular offer.
- User can view the particular offer.
- Tour Report Management
- User will enter their tour report form like client name, plant capacity, electrode consumption, competitor price, competitor name, contact person and date of visit.
- User can edit the tour report.
- User can search the tour report based on date of journey and customer name.
- Order Management System
- User enters the order details (to database) received from the customer like order no, client name, electrode length, electrode diameter, electrode grade, price, delivery date and status.
- User can search particular order by order number.
- User can edit the order details.
- User can delete the order.
- User can close the order once it has been fulfilled.
- User can view consolidated order for every month.
- User can enter production details and expected order for a month for particular grade, length and diameter.
- Report Generation System
- Customer information report generated
- Country wise.
- Grade wise
- Size wise
- Region wise
- Agent wise
- Top five customer based on volume
- Offer report
- Pending offer report
- Month wise offer report
- Plant schedule report.
- Monthly order status report to plant.
Admin Module
- User (Administrator) interface is provided for Adding, Editing and Deleting of user there by security rights are maintained.
User (Administrator) interface is provided for Adding, Editing and Deleting of masters- diameter, grade and length.
Appendix 2
Classical Waterfall
The lifecycle approach is derived from the waterfall model of system development described by Royce in 1970, a simplified version of which is given below:
Classic System Development Lifecycle - Version 1
There are now many variations on the theme of the waterfall model, an alternative is presented below:
Classic System Development Lifecycle - Version 2
2.1 Waterfall Approach Characteristics
Although there are many variations on the theme of the lifecycle, each approach has its own characteristics:
- specific activities, techniques and outcomes are associated with each stage;
- progression between stages is orderly and proceeds in a linear fashion;
- viewed to be a process driven by technicians;
- monitoring and control takes place at the end of each stage;
- involvement of end users is typically passive and principally in the analysis stage.
The lifecycle model assumes that systems will be constructed from scratch by a team of IS professionals either in-house of within a software house.
Other approaches exist, namely:
- those based on alternative lifecycles e.g. prototyping, evolutionary development, spiral model;
- those which have a different philosophical basis e.g. soft systems and sociotechnical approaches;
- the use of package software to address application areas;
- the development of applications by end users.
2.2 Problems with the Waterfall Approach
- Real projects rarely follow the sequential process illustrated - iteration through the cycles is required.
- It is often difficult for the customer to state all requirements explicitly at the start of the development lifecycle.
- With this approach, the customer must be patient - a working version is not usually available until late in the development lifecycle.