Application software development has always been viewed as a massive challenge by companies that view IT services as a support function rather than a core function. The term “core” here implies that IT plays an enabler role to facilitate technology and services that support users to meet set business objectives in an efficient way. Furthermore, IT development is perceived by many managers as a burden; hence, they prefer the fast track implementation of specialized packages to deliver the majority of service levels over the long wait for systems to be built in-house, even though the latter option is more advantageous in the long run, as it offers a much better fit to all user requirements. With this dilemma in mind, this case is an example of how an in-house development solution was implemented. The case touches on positive and negative aspects of the decision to build the application and covers a range of issues encountered during every phase of the development life cycle.
TopBackground Of The Business Requirements
The Medical Services unit of the company required a system that would enable its Medical Officers to offer the expected service levels to all employees and contractors with emphasis on aspects such as personal health, particularly for employees suffering from “chronic diseases” and “allergies” as well as hazards caused by the nature of the job or job location.
Due to the fact that the system was to be developed in-house, a number of project pre-requisites were not completely adhered to. One such critical pre-requisite was the “Project Charter,” where the project team accepted to start the project from the point when the project plan was prepared.
The system was expected to deliver the following:
- 1.
A simple user interface with minimum use of the keyboard by all users.
- 2.
A seamless user workflow, which triggered users to do their role automatically.
- 3.
A colored graphical representation of patient queues and service queues (service here being laboratory, x-ray, pharmacy, etc.).
- 4.
An easy to use reporting facilities based on user privileges.
- 5.
A monitoring and control tool for privileged staff members providing them with a bird’s eye view of the status at the different sites.
Different Views
Stakeholders had different views pertaining to the requirement, the involvement of others, the overall objectives, and the points that could be scored from such a case. There were other parameters relating to risks involved and stakeholders were striving to isolate themselves from risks such as failure to deliver. The section below addresses the different views applying the Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis technique and. understandably, one could argue that this case is based on an internal implementation; hence, SWOT would be rather restricted with limitations applicable to the organization. This is true but SWOT was used to establish some common grounds for the different view of the stakeholders. This common ground enabled the project manager oversee some of the hurdles that would be encountered with different flavors (depending on the stakeholder’s view).
IT Management Point of View
That project was a golden opportunity for IT management to assign a few graduates to the project. This would give these graduates the opportunity to enhance their skills in a number of areas such as Systems Analysis, Design Techniques, Data and Process Modeling, as well as applying the design tools. It also meant that the IT team assigned was capable of utilizing more resources to conduct more tasks in parallel hence optimizing delay, and of course that was seen here as a strength. On the other hand, the risk of having resources assigned as part time members of the team would encourage slackness particularly during the light workload period. This threat was genuine as employees have the tendency to minimize workload whenever possible. From the management point view, the threat of failure was the biggest challenge.