The Quality Software Solutions Case

Table of Contents

Page
A. Background

B. Issues and Problems

C. Alternative Courses of Action

D. Recommendations

E. Implementation Steps

The Quality Software Solutions Case

A. Background
Quality Software Solutions (QSS) is a small software development organisation involved
in the design and development of library information systems.
It was founded in the early 1990s and enjoyed some success and expansion, doubling
its staff from 15 to 30 personnel between 1995 and 1998, with plans to recruit additional
software developers.
Early in 2001, as a direct result of the slump in the software development industry, QSS
was forced to retire 10 of its employees. Since then however, the company has been
able to nurture and grow its customer base. Because of this, QSS hired 15 staff on a
contract basis.
At this time, QSS plans to recruit an additional 15 software developers, some of which
may be on a permanent basis. The majority of these new hires are expected to have
relevant experience, also it is also planned to recruit a number of recent graduates.
QSS approach to project execution
The company is made up of three project teams; each one devoted to a separate
subsystem of the product. An independent test team has recently been formed.
Success in meeting deadlines and delivering quality product has been mainly due to the
commitment and experience of a core group of staff who have been with the company
since its inception.
Developments during the last four months
Development during the last four months had a major impact on the operations of QSS.
These developments include:

The resignation of two experienced project managers, who were both on contract, for
permanent positions elsewhere.

The pirating by other companies of five skilled QSS software developers for
specialist development roles.

Experience with Version 3.0 of the Library Orders Subsystem

The development of version 3.0 of the Library Orders Subsystem encountered the
following difficulties:

There was an overrun of three months. Team members had to work an average of
16 hours each week just to finish their work.

There is no record of actual time spent by staff in each activity.

B. Issues and Problems

1. Responsibility for the quality of the work done by the three teams responsible for
creating the library information system is limited not to the entire project but to the
subsystem that they are assigned to handle. While this "assembly line" approach has
its merits, team members do not have the opportunity to gain the experience of
handling all aspects of software development. Thus, when a resignation occurs, a
gap is created, forcing inexperienced staff to fill a position that he is ill-prepared to
handle.
2. There is no clear career path defined for each staff. It is possible for a staff to be
promoted to a higher position even without the necessary requisite training on project
management. An example of this scenario is the assignment of a team leader who
has very little previous exposure in project management to the handle the position of
project manager because the incumbent manager suddenly resigned.
3. Roles and responsibilities are not clearly defined for project activities. As a result,
two significant activities were "forgotten" until near the end of the project. Five people
had to give up their weekend to complete these activities.
4. There appears to be no guide for team members to follow to handle and manage
projects. Indicators of this problem are as follows:
-

A company template for software requirements was never used, because new
staff were unaware of its existence.

A number of requirements that were identified during the requirements phase

were never implemented, as they were omitted in error during software design.

During system testing, it was identified that an incorrect version of software had
been tested. The correct version was re-tested, delaying the project by two days.

An error which had been found in Version 2.0, but fixed in Version 2.1 and
subsequent versions, reappeared during early testing of Version 3.0. This was
quickly rectified.

Just before release, a significant error was found and tracked to a particular
module. The person who developed that module had not used the coding
standards, and had left the company 4 months earlier. It took two developers 2
days to correct the problem, and a further day to re-test the module.

An incorrect version of software was shipped to one customer, causing

considerable embarrassment.

5. Project planning and monitoring of projects appears to be poor. Again, the indicators
of this problem can be gleaned from the following:
-

A number of requirements changed during the project. The effect this would have
on the schedule was underestimated.

No contingency was planned.

The Project Plan was not updated throughout the project.

The Project Plan was not used for managing the project. No one was responsible
for its update.

C. Alternative Courses of Action

The software development business is dependent on the business climate. It is also
affected by rapidly changing technological innovations. Thus, a company has to be
flexible and proactive in continuously scanning the business environment and making
realistic short-term and long-term projections.
To reduce the possibility of the repetition of the difficulties faced by the company, two
alternative courses of action is open: (1) Do nothing, and (2) Institute improvements that
are designed to eliminate the problems now faced by QSS.
The option of doing nothing or status quo is unacceptable because the difficulties are
controllable. Thus the following courses of action may be considered:
1. Consider a matrix type of organization instead of the present functional approach.
2. Formalize policies and operating procedures in an Operations Guide. This
Operations Guide should cover all aspects of software design, coding, testing,
documentation and user training. With the use of this Guide, processes can be
repeated at any time.
The Operations Guide should also include tools and techniques for estimating and
project planning. It can also specify computerized project management software to
use. It should also cover monitoring approaches to ensure adherence to plans and
early identification of project issues.
3. Set design standards and parameters and ensure adherence by everyone.
4. Conduct continuous technical and management training. This training should cover
basic skills which must be attended by new hires, whether experienced or not,
specialized training to be attended by staff who are being considered for higher
positions and responsibilities.

D. Recommendations
In instituting improvements within QSS, a holistic approach is recommended. This
means that improvement initiatives are made on the basis of improving the entire system
and not just a part of it. Using this approach, the following is recommended:
1. Consider restructuring the QSS organization so that a matrix type of arrangement is
attained. This means that every time a project is made, a set of experts and
specialists are assigned to it so that their combined expertise are brought to bear
towards its successful completion.
2. When undertaking project, all stakeholders, from top management down to the code
writer, should be involved and their views taken into consideration. This creates an
environment of taking responsibility for their actions, reducing finger pointing when
things go wrong. Also, a Steering Committee should be formed to provide direction,
guidance and approval to all aspects of the development of projects. This Steering
Committee will be the court of last resort that will arbitrate any issues that cannot be
resolved at lower levels.
1. Design a management and technical training program that will be the basis for
preparing all staffmembers for the next position. This should enable staffmembers to
handle new projects based on experiences gleaned from actual case studies.
2. Initiate the preparation of an Operations Guide and adopt a conscientious effort to
implement and adhere to it. With this guide, QSS staffmembers and managers
should be able to:

prepare realistic estimates and plans.

track costs, schedules and functionalities
follow design standards that are agreed upon

E. Implementation Steps
To implement the above recommendations, we suggest the following steps:
1. Organize an Implementation Team who will be responsible for monitoring and
implementing the reorganization as well as the preparation of the Operations Guide.
2. Organize a Steering Committee composed of top management and selected
members of the Implementation Team and responsible for providing direction and
approvals.
3. Implement the reorganization effort.
4. Brief everyone on the new way of doing things.
5. Assign teams to prepare the Operations Guide. Also assign someone the
responsibility of overseeing its implementation and updating.
ooo