Customizing Acquisition Module Of Integrated Library System (ILS) For Multiple Item Coding

Objective of ILS Development and Implementation

Integrated library system (ILS) is a library community’s equivalent of an enterprise resource planning system that manages a lot of business operations. Previously, a home-grown system combined with a vendor supported system was used for library management but later it was planned to replace with an integrated Library solution. The objective of the project is to develop the new ILS solution in a manner that it fulfils all the operational needs of the library system including cataloguing, acquisition, circulation, serial control, indexing, bar code generation, and membership management.

The new ILS system was developed and is in the phase of implementation. However, during implementation, it was discovered that the acquisitions module did not work as expected as it was unable to handle multiple copies of books efficiently. Unlike the previous software in which a collection of same book could be entered by the staff in the single go, the new software demanded entries to be made 12 times which could become cumbersome for the staff as there were countless items to be coded.

As the standard module of the software does not already has this feature of simultaneous coding of multiple items, There is a need to revise the acquisition module to make a way for allowing multiple books to be coded collectively in a single go. Thus, the acquisition module of the software has to be customized.

• Customization of acquisition module would allow multiple items coding at one go saving the time of staff and thus, enhance productivity
• The new system would integrate all the operations in the single system and thus, the system would be less complicated and fast
• Being an enterprise system, several library operations can be automated which would increase the efficiency and accuracy of work

The key problem with the new system developed is that it does not allow coding of multiple items at the same time which means that if multiple copies of the same book have to be coded in the system, it would require multiple entries instead of one unlike the previous software in which multiple books could be coded simultaneously. Thus, the acquisition module of the new software needs to be customized to satisfy the need for multiple item coding.

The objectives of development and implementation of an integrated library management system

The new software would help the organization improve the productivity of its employees and simply its operations such that the system would be able to deliver its services to customers better. This would enhance the value of the library services in the market.

The organization aims to save on its administrative costs. As the ILS system would simplify the work of employees as well as automate time consuming processes making them fast such that with the speed and automation, the company would save on the operational and administrative costs which would increase the productivity of the organization.

Key Problem with the New ILS System Developed

The aim of this project is to customize the acquisition module of the enterprise management solution for the library management system and develop a system that is capable of integrating all the library operations and bring operational efficiencies to the organization through standardization and automation of library management processes. The system is expected to bring in efficiency, accuracy, and improved member experience by making the system seamless across the organization through integration of all library management processes (Abrahamsson, Corral, Oivo, & Russo, 2015).

	From	To	Channel	Date/Frequency
Project Plan, Project Schedule, Project Proposal	Project Management Organisation (PMO)	Project Sponsors Library Stakeholders	Physical document	Before initiating project
System Requirements	Library System Analyst	Project Manager ILS Developer  Internal Stakeholders	Emails Physical Document	After initiating project
Development Contract with Developer	Company Legal Counsel	PMO Developer	Physical Document	After requirements approval
Project progress reporting	PMO	Stakeholders Project Sponsors	Email	Twice a month
Request For Proposals (RFP)	PMO	Developers	Email	As per milestone dates (Antón, 2003)

Business Analysis of Library

The project would involve analysis of the library management system which was used earlier and which is developed recently to identify if the functional and business requirements of the organization are met by the new software such that gaps can be identified and a revised development requirement can be formulated. The information for the analysis would be taken from the internal stakeholders of the company that include the staff of the company and it’s CEO. The interviews would be taken of the people from each level of the hierarchy in the organization to understand how the system is being used by them, what challenges they face and what their functional needs are.

Business Process Reengineering

The project involves analysis of the existing processes used by the organization with the old software and identifies what needs to be changed in the system to improve it. Based on this analysis, the system proposed for development has to be tailored to the customer requirements. A major customization is required to be done in the acquisition module of the library management system. The new system would bring in changes in the organizations and the way its employees would be working and thus, change management and control mechanisms have to be implemented to ensure smooth adoption of the new system by the company staff (Acuna, Juristo, Moreno, & Mon, 2005).

Training Users and Stakeholders

The users of the new library system would have to be trained on the internal processes while the external stakeholder including library members would be trained on how to use the library for their needs. This training would be carried out using documents for reading, presentations and sessions for face to face training. Personal support would also be provided to the internal users in case they are facing difficulties with the software while using it.

Migration from legacy systems

The data that is present in the legacy system of the business has to be migrated to the new software which would need collaboration from the employees during the transition phase at the time of implementation.

Business Analysis of Library

Training Documentation

The developer organization is expected to provide the training documentation as well as personal training for users along with the software solution.

Infrastructure

No major changes would be required in the hardware or standard software used by the organization and it is assumed that the new software would be able to work with the existing hardware used by the organization.

An issue tracking tool would be used by the project management team to identify any requirements for change and for posting change requests. The same has been used for placing a request for the change of acquisition module to enable multiple items coding at the same time. The PMO has a change control committee that reviews change request and takes decision on whether to make the changes based on how the change would affect standard processes and company policies (Chang, 2012).

The change control committee (CCC) is responsible for ensuring that only the changes that align with business and project objectives are approved and would have the required authority to take these decisions. The Committee has following members:

• Project Manager
• PMO
• Library Management experts.
• Project Sponsor(Acuna, Juristo, Moreno, & Mon, 2005)

Once a change request gets approved by CCC, the change is brought to practice and the notification of the same would be provided to all the major stakeholders highlighting the changes to be made and how they are going to affect the business operations of the organization (Bego, et al., 2006).

	Project Sponsor	Project Team	Support Staff	External Stakeholders	Vendors
Designation	Library Owner	PMO Staff and Developers	Internal	Members	Developers
Communication Channels	Email	Project Collaboration tools	Email	Email	Email, Call
Interest	High	High	High	Medium	High
Influence	High	High	Low	Medium	High
Relationships Management	Must be updated with major milestone achievements	Weekly meetings should be carried out between them	Lead notice of 2 weeks should be given while seeking support	Regular communication should happen	Daily communication and coordination is required (Bruegge & Johnstone, 1997)

	Data requirement	Collection	Responsibility	Medium & Format
Schedule Tracking	Gantt Chart	Fortnightly	PMO	Electronic and paper documentation
Progress Reports	Project progress metrics	Weekly	PMO	PDF
Decision  memos	Minutes of the Meeting and emails	Weekly	PMO	Post on Collaboration tool
Performance & Value Forecasting	Gantt Chart, Progress reports	Weekly	PMO	Post on Collaboration tool (FENEMA, 2002)

	Purpose	Frequency	Attendees	Reporting Requirements
Progress Review	Review and coordination	Weekly	Project Manager Team leaders Project sponsor, Developer Organization  Rep	Minutes of the Meeting Minutes, Decision Memo(s) (Antón, 2003)
Performance Review	Forecasts	Once in two weeks	Project Manager, Project Sponsor, External Stakeholders, Developer Organization Rep	Forecasting documents, minutes of the meeting (Farrell, 2007).

Depository/Tools	Location	Data	Purpose
Document Management	Cloud Service Provider	PMO documents	Documents would be shared and worked between developer and project team
Office Documents	Internal Network Cloud	Office documents including PDFs, word files, and spreadsheets	Files would be exchanged and created between employees (Cusumano & Smith, 1995)
Messaging & Scheduling	Internal Network Cloud	Collaborative tools	Real time collaboration between teams for updates
Time & Task management	Internal Network	Project management schedule and milestones	Coordination and collaboration between project team members
Real-time Collaboration tools	Cloud and/or Internal network	Teams integration with cross-functional integration.	Coordination and collaboration between project team members
Backup	Internal Systems	Operational Data	Cold storage for company to ensure business continuity in the case of a failure (Ramsin, 2005).

WBS	Task Name	Duration	Start	Finish	Predecessors
1	Library Management System	683 days	Mon 28-08-17	Wed 08-04-20
1.1	Requirements analysis	30 days	Mon 28-08-17	Fri 06-10-17
1.1.1	Functional requirements	20 days	Mon 28-08-17	Fri 22-09-17
1.1.2	Non-Functional requirements	10 days	Mon 25-09-17	Fri 06-10-17	3
1.2	Software Acquisition	20 days	Mon 09-10-17	Fri 03-11-17
1.2.1	Refine Functional Requirements	10 days	Mon 09-10-17	Fri 20-10-17	4
1.2.2	Define Application requirements	5 days	Mon 09-10-17	Fri 13-10-17	4
1.2.3	Assess hardware requirements	5 days	Mon 09-10-17	Fri 13-10-17	4
1.2.4	Consult internal Stakeholder	3 days	Mon 09-10-17	Wed 11-10-17	4
1.2.5	Procurement contract with developer	10 days	Mon 23-10-17	Fri 03-11-17	6,7,8,9
1.3	Technology Acquisition Process	86 days	Mon 06-11-17	Mon 05-03-18
1.3.1	Software Requirements Specification	3 days	Mon 06-11-17	Wed 08-11-17	10
1.3.2	Contract Terms	5 days	Thu 09-11-17	Wed 15-11-17	12
1.3.3	Stakeholder Confirmation	2 days	Thu 16-11-17	Fri 17-11-17	13
1.3.4	Request for Proposals (RFP) submission	10 days	Mon 20-11-17	Fri 01-12-17	14
1.3.5	Proposal evaluation	50 days	Mon 04-12-17	Fri 09-02-18	15
1.3.6	Contract Negotiation	14 days	Mon 12-02-18	Thu 01-03-18	16
1.3.7	Project Plan	2 days	Fri 02-03-18	Mon 05-03-18	17
1.4	Implementation	415 days	Tue 06-03-18	Mon 07-10-19
1.4.1	Customization of Acquisition Module	105 days	Tue 06-03-18	Mon 30-07-18	18
1.4.2	Testing Acquisition module	100 days	Tue 31-07-18	Mon 17-12-18	20
1.4.3	Supportive system implementation	80 days	Tue 18-12-18	Mon 08-04-19	21
1.4.4	ILS System Implementation	100 days	Tue 09-04-19	Mon 26-08-19	22
1.4.5	Integration with existing systems	10 days	Tue 27-08-19	Mon 09-09-19	23
1.4.6	User testing	20 days	Tue 10-09-19	Mon 07-10-19	24
1.5	Business Process Reengineering	44 days	Tue 08-10-19	Fri 06-12-19
1.5.1	Analysis of Process Adaption	20 days	Tue 08-10-19	Mon 04-11-19	25
1.5.2	Process Definition	5 days	Tue 05-11-19	Mon 11-11-19	27
1.5.3	Approval of Process Change	4 days	Tue 12-11-19	Fri 15-11-19	28
1.5.4	Process Implementation	15 days	Mon 18-11-19	Fri 06-12-19	29
1.6	Training for Users (developer)	42 days	Mon 09-12-19	Tue 04-02-20
1.6.1	Users Identification	2 days	Mon 09-12-19	Tue 10-12-19	30
1.6.2	Training content development/specification	10 days	Wed 11-12-19	Tue 24-12-19	32
1.6.3	Training Processes	10 days	Wed 25-12-19	Tue 07-01-20	33
1.6.4	Training implementation	20 days	Wed 08-01-20	Tue 04-02-20	34
1.6.5	Training Completion	0 days	Tue 04-02-20	Tue 04-02-20	35
1.7	Data Migration	30 days	Wed 05-02-20	Tue 17-03-20
1.7.1	Migration plan	5 days	Wed 05-02-20	Tue 11-02-20	36
1.7.2	Preparation for Downtime	5 days	Wed 12-02-20	Tue 18-02-20	38
1.7.3	Notification	5 days	Wed 19-02-20	Tue 25-02-20	39
1.7.4	Migration	5 days	Wed 26-02-20	Tue 03-03-20	40
1.7.5	Testing	10 days	Wed 04-03-20	Tue 17-03-20	41
1.7.6	Migration complete	0 days	Tue 17-03-20	Tue 17-03-20	42
1.8	Project Review And Closure	8 days	Wed 18-03-20	Fri 27-03-20
1.8.1	User acceptance testing	5 days	Wed 18-03-20	Tue 24-03-20	43
1.8.2	Go Live	3 days	Wed 25-03-20	Fri 27-03-20	45
1.9	User Feedback	3 days	Mon 30-03-20	Wed 01-04-20
1.9.1	Project team feedback	3 days	Mon 30-03-20	Wed 01-04-20	46
1.9.2	Members feedback	3 days	Mon 30-03-20	Wed 01-04-20	46
1.1	Project evaluation	3 days	Thu 02-04-20	Mon 06-04-20	47,48
1.11	Lessons learned	2 days	Tue 07-04-20	Wed 08-04-20	50

 

The project budget is $44.52 million for the complete development as well as customization of ILS.

This money would be utilized as follows:

Task	Amount	Unit	Cost of Unit	Totals
Human resource Estimate	120	Days	$10,000.00	$1,200,000.00
Consulting	2000	Hours	$600.00	$1,200,000.00
Requirements analysis and evaluation	15	Days	$8,000.00	$90,000.00
New Technology Acquisition	1	Developer Service	$12,000,000.00	$12,000,000.00
Service Delivery and Maintenance	10	Months	$100,000.00	$1,000,000.00
Implementation	60	Days	$120,000.00	$720,000.00
Training	20	Days	$60,000.00	$1,020,000.00
Business Process adaptions	60	Days	$100,000.00	$6,000,000.00
Data Migration	30	Days	$400,000.00	$12,000,000.00
Staff Resourcing (internal)	5	Packages	$200,000.00	$1,000,000.00
Staff Resourcing (specialists)	6	Specialists	$500,000.00	$3,000,000.00
Exit strategy	1	Process or Project	$4,000,000.00	$4,000,000.00
Risks Management	0.1	of total costs (Dhlamini, Nhamu, & Kachepa, 2006)	$43,230,000.00	$432,300.00
Funds reserved	0.2	of total costs	$43,230,000.00	$864,600.00 (Giles & Barney, 1995)
Total				$44,526,900.00

The cost of the project is majorly influenced by the contractual arrangement between the developer and the library organization and the estimate presented in this project plan is only an estimate based on the high level expectations of the client organization. Upon commencement of the project, a costing committee would be involved to analyse cost estimates and provide detailed cost control plan (Bego, et al., 2006).

Role	Name	Key Points
Project Sponsor	Andrew Johns	Takes decisions on funding and approve it
CTO	$43,230,000.00	To be kept updated with milestone achievements
End Users	Library Members	Must be notified of the new changes in library systems and provided with training material for guidance.
Business Analyst	Albert Taylor	Must have all the needed information for development requirements to allow analysis
Supplier	Developer	Must be given detailed requirements for development
CFO	Andrew Johns	Performance and cost metrics must be provided for taking decisions (Bruegge & Johnstone, 1997)

As a majority of Human resource would come from the developer, the human resource cost and resource negotiations would be done between developer and the internal project team of the library organization.

Risk can belong to many categories some of them are listed below as follows:

Category	Acronym	Description
Management Risk	MR	Management issues like approval delays, decision problems, conflicts of interest, lack of support, etc.
Financial Risk	FR	Exceeding of Budget
Technology Risk	TR	Functional risks
Environmental Risk	ER	Political and economical risks (Pescatore, 2003)
Human Risk	PR	HR issues such as performance problems, lack of resources, lack of competence, lack of motivation, interpersonal conflicts, etc (Afaq, Qadri, Ahmad, Siddique, Baloch, & Ayoub, 2014).

The table below presents assessment of identified risks with respect to their probability of occurrence and impact on the project.

ID	Risk	Category	Mitigation/ Avoidance	Probability (P)	Impact (I)	Total Risk Score
1	Natural Calamity	ER	Emergency Training for the Staff	0.01	10	0.1
2	Lack of Funding	FR	Keeping Contingency funds	0.1	6	0.6
3	Undiscovered Bugs	TR	Testing (A, 2004)	0.2	6	1.2
4	Insolvency Of Developer	ER	Background Check	0.1	10	1.0
5	Staff Shortage	PR	New Hire	0.4	4	1.6
6	Delays in delivery	ER	Progress check	0.6	6	3.6
7	Wrong Requirement or Specification	MR	Refer Lesson Learned	0.4	7	2.8
8	Political Issues	ER	Legal Consultancy	0.1	6	0.6
10	Scope changes	MR	Change Control Process	0.4	7	2.8
11	Lack Of Acceptance	MR	Quality Control	0.3	7	2.1
12	Emergencies	TR	Contingency fund (Avdoshin & Pesotskaya, 2011)	0.2	8	1.6

Project Need	QUALITY STANDARDS
Requirement Analysis	The requirement document must be kept updated always
Status Reporting	Project manager must closely monitor project progress and check against planned milestones
System Documentation	Every detail of project activities, requirements and other things must get recorded
Communication	Timely communication with stakeholders
System Issue Tracking	IT system Monitoring
Behaviour Code	Develop codes for expected behaviour supporting project
Staff Performance	Staff should coordinate and collaborative efficiently within team (Mansharamani, 2011)
Office Equipments	Safety Procedures
Planning	Develop standard project plan
Administration	Stakeholder involvement
Ethos	Stakeholder values and goals consideration (Franch & Carvallo, 2003)

Project Deliverables	QUALITY METRICS
User Satisfaction	The user rating on satisfaction from new ILS must be higher than 7.
System Maintainability	Software updates and progressions must be handled by developer
Project Plan And Schedule	Project plan should be developed consulting subject matter and project management experts
Progress Reporting	100% on time delivery (Geagea, et al., 2010).
Milestones	Gantt charts to measure achievement
Staff Performance	Clarity of roles and duties of staff
Cost Control	Cash flow analysis
Testing	Test artefacts
Behaviour Codes	Ethical and productive (Giese, 2005)

The project must develop a system that is maintainable, reliable and fulfils all the functional needs of the company as defined in the requirements while maintaining highest quality of outputs, performance and delivery (R.VENUS, 2012).

Business Process Reengineering

An iterative approach would be taken for development and testing would be carried out post each iteration. If any bugs are found, the same would be rectified in the next iteration.

Support would be obtained from the top management and the project manager would act as leader who would guide and motivate the project team by using collaborative approaches.

The industry best practices used for library management system development projects would be used in the current project.

Total Quality Controlling (TQM) and Software Quality Function Organization (SQFD) would be used for the management of the software development to ensure maturity of IT systems is achieved.

References 

A, A. (2004). Whose Bug Is It Anyway? The Battle over Handling Software Flaws. IEEE Software.

Abrahamsson, P., Corral, L., Oivo, M., & Russo, B. (2015). Product-Focused Software Process Improvement. 16th International Conference, PROFES, (pp. 24-40). Bolzano, Italy.

Acuna, S., Juristo, N., Moreno, A. M., & Mon, A. (2005). A Software Process Model Handbook for Incorporating People’s Capabilities (Vol. xxvii). Springer.

Afaq, S., Qadri, S., Ahmad, S., Siddique, A. B., Baloch, M. P., & Ayoub, A. (2014). Software Risk Management In Virtual Team Environment. INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH , 3 (12), 270-274.

Antón, A. I. (2003). Successful Software Projects Need Requirements Planning. North Carolina State University.

Avdoshin, S. M., & Pesotskaya, E. Y. (2011). Software Risk Management: Using the Automated Tools. Russian Federation.

Bego, S., Coset, R., Leeuwestein, R., Leijten, M., Linden, I. v., Moreaux, J. M., et al. (2006). Software Project Management Plan. SPINGRID.

Bruegge, B., & Johnstone, J. (1997). Software Project Management Plan: JAMES Project. Pittsburgh, PA: Carnegie Mellon University.

Chang, C. (2012). Selecting an Appropriate Software Development Lifecycle (SDL) Model in an Agency Environment. Retrieved November 12, 2015, from https://www.metia.com/seattle/chong-chang/2012/08/sdl-model-in-an-agency-environment/

Cusumano, M. A., & Smith, S. (1995). Beyond the Waterfall:Software Development at Microsoft. International Business Machines.

Devedzic, V. (2000). Software Project Management . Yugoslavia: University of Belgrade.

Dhlamini, J., Nhamu, I., & Kachepa, A. (2006). Intelligent Risk Management Tools for Software Development . Polytechnic of Namibia .

Farrell, A. (2007). Selecting a Software Development Methodology based on Organizational Characteristics . ATHABASCA UNIVERSITY .

FENEMA, P. C. (2002). Coordination and Control of Globally Distributed Software Projects. Erasmus University Rotterdam.

Franch, X., & Carvallo, J. P. (2003). Using Quality Models in Software Package Selection. Universitat Politècnica de Catalunya.

Geagea, S., Zhang, S., Sahlin, N., Hasibi, F., Hameed, F., Rafiyan, E., et al. (2010). Software Requirements Specification: Amazing Lunch Indicator. Chalmers.

Giakoumakis, E., & Xylomenos, G. (1992). Evaluation and selection criteria for software requirements specification standards. CSEWEB.

Giese, H. (2005). Software Quality Assurance:VI Standards. University of Paderborn.

Giles, A. E., & Barney, D. (1995). Metrics Tools: Software Cost Estimation. STHC .

ISBSG. (2012). Software Development Projects in Government -performance, practices and predictions. ISBSG.

Mansharamani, R. (2011). Performance Testing. Free Software Foundation.

Pescatore, J. (2003). Taxonomy of Software Vulnerabilities. Gartner, Inc.

R.VENUS. (2012). DESIGN AND IMPLEMENTATION OF LIBRARY AUTOMATION USING KOHA (Open Source Software) AT BHARATHIDASAN UNIVERSITY COLLEGE, PERAMBALU. TIRUCHIRAPALLI: BHARATHIDASAN UNIVERSITY.

Ramsin, R. (2005). Software Development Methodologies. Sharif University of Technology.

Vogel, P. S. (2012). Ngotiating Software Contracts for Enterprise Resource PLanning. Gardere.

WALLMÜLLER, D. E. (1993). Risk Management for IT and Software Projects. Zürich: ITQ.

Welsh, W. D., & Black, D. (2010). Engaging stakeholders for a software development project: River Manager model. Australia: International Environmental Modelling and Software Society (iEMSs) .

Wiegers, K. E. (2003). So You Want To Be a Requirements Analyst? Software Development magazine.