Technological Educational Institute of Piraeus

MSc ADVANCED INDUSTRIAL AND MANUFACTURING SYSTEMS

Module: Industrial Project Management

Assignment: Implementing an Inventory & Asset Management System in Marwin Machine Tools Ltd

Module Leader: Dr Georgios BESSERIS Students Names: Georgios G. ROKOS & Ioannis KOUROS

Students Signatures: ___________________________

Date: March 2011

Technological Professional Institute of Piraeus

Table of Contents

Chapter 1. Introduction ........................................................................................................2 Chapter 2. Problem Definition and Response .....................................................................3 Chapter 3. Documentation and Deliverables ......................................................................5 Chapter 4. Monitoring and Controlling .............................................................................15 Annex I. Report to Shopkeeper .........................................................................................17 References ..........................................................................................................................28

Technological Professional Institute of Piraeus

Chapter 1. Introduction

Marwin Machine Tools Ltd is a small-to-medium sized manufacturing company, employing approximately 120 people. Although the company operates in a highly competitive business field, namely in that of small hand tools, it has not yet implemented a reliable Inventory and Asset Management System. The Inventory Database is currently handled through MS Access, thus Inventory Management tasks aggravate the Shopkeepers job. The companys Shopkeeper is currently the person in charge of entering the input-output information into the Access DB. That is because such information are of vital importance and the company does not risk their management by an employee other than the Shopkeeper himself. As a result, Inventory Management tasks displace the rest of activities a Shopkeeper should normally shoulder and a General Management gap threatens the organizations smooth function. The objective of the following project is to harmonize the Shopkeepers activities, without undermining or misplacing Inventory Management Control. The latter may only be attained with the adoption of a new Inventory and Asset Management System. Inventory and Asset Management Systems are both parts of a wider corporate Management Information System (MIS), also known as Enterprise Resource Planning (ERP). In Marwins case, there already exist some modules/parts of an ERP system that do not call for modifications. For instance, the company possesses a Purchasing System, identified as FIS, which is not to be either incorporated in the new system or replaced by a new module. The goal of this project is uniquely to ameliorate Inventory and Asset Management related processes which will, in terms, affect other sectors of the organization. The project is deployed from its conception to its closeout, which is the normal adoption and operation of the project plan. Two distinct versions of the project are displayed in this paper. The first one follows an elaborate approach of ERP implementation projects, broken down into approximately 75 tasks and subtasks and the second one is a simplified and diminished illustration of the first. The second version was developed due to space limitation appearing in the version version; the WBS as well as the Gantt Chart would not be presentable in 75 tasks.

Technological Professional Institute of Piraeus

Chapter 2. Problem Definition and Response

Project Management is applicable in problematic situations. Those are its raisons dtre. Dr. Juran, one of the fathers of JIT and a Quality Management guru, defines project as a problem scheduled for solution (Juran & Godfrey, 1999). In fact, a project is a step-by-step problem resolution approach. A project plan consists of the following elements (Lewis, 2007, pp. 37-38) A Problem Statement A Mission Statement Project Objectives Project Work Objectives/Requirements Exit Criteria End-Item specifications. Work Breakdown Structure (WBS) Schedules Required resources Control System Major contributors Risk areas with contingencies, when possible

The very first step of a project is the identification of the problem, so as to know what we are dealing with. In Marwins case, the problem can be resumed as follows (Problem Statement): Marwin Machines Tools operates in two shifts and its current inventory tracking system is operated manually by the shopkeeper. The employees make their requests for clothing or equipment by completing a sheet and then the Shopkeeper mitigates the data from the sheet to an Access database, losing precious time and risking the accuracy inputted data. The inventory system is not updated automatically and the company is mandated to conduct spot checks in the warehouses every now and then to ensure that the data are in accordance with the actual inventory status. Once the Problem is Stated, the Mission Statement may be concluded, based on the musts, the wants, the secondary desires of the company and inspired by the companys vision. A Mission Statement does not only constitute a written declaration of the projects direction, but also a political tool, especially when eventual conflicts arise during the projects rollout. As the project proceeds, changes of its plan may be required by certain stakeholders. In that case, the Mission Statement will ensure that the project will not be disorientated, acting as a negotiation principle (Cobb, 2006)

Technological Professional Institute of Piraeus

In Marwins example, the Mission Statement could look like the following: The mission for this project is to develop a new Inventory & Asset Management System that will facilitate tracking procedures. The target audience is primarily the companys Shopkeeper and secondarily other Top Management members as well as people belonging to the category of project clients. The Project Objectives constitute the goals of the mission and a more elaborate presentation of the answers to the problem. Project objectives should me SMART (Specific, Measurable, Attainable, Realistic, Time-limited). (Lewis, 2007). In Marwins project, the Project objectives would be the following: Provide the Shopkeeper with: An automated tool to aid in the tracking of inventory, rather than missing 15 minutes of work time every time a spot checkup is performed. A networked solution, accessible out of the keepers office, which will enable ubiquitous Inventory management, diminishing hence Inventory errors. An application with flexible reporting capabilities, delivered by July, this summer.

The Problem Statement, the Mission Statement and the Project Objectives sketch the problem and an outline of the answers to the problem. Mistakes or modifications to the above should not be permitted, since they would fundamentally restructure the projects concept and orientation. The Problem and Mission Statements, as well as the Project Objectives should be treated as beacon, showing the way to success to the Project Stakeholders.

Technological Professional Institute of Piraeus

Chapter 3. Documentation and Deliverables

A project is a group of tasks and a sum of work. If it is to be controlled, the project should be accompanied by tangible elements at points that signalize the completion of tasks. The most rational path to Project Time Management is setting up points that will act as progress beacons. Such points, also identified as Milestones, should be scheduled to be reached at given moments so as to facilitate progress tracking. Milestones can be placed at both Phases of a PLC and Processes and may be combined with Exit Criteria. The latter constitute verbal notes that describe which phase or process is completed when a milestone is reached and how. Milestones include the surrender of documents, software, hardware and other tangible elements, known as Deliverables. Deliverables are a crucial part of a project, not only for monitoring and control reasons but also for functional purposes. Bainey (2004) suggests that a special role for Deliverable Management issues should be guesstimated when launching a project. Tables 1, 2 and 3 describe the activities of a Project Deliverable manager per management frame. His work commences concurrently with the Project Definition. Nevertheless, in simple projects like that of Marwin Ltd, Deliverable Managers tasks could be treated by other project team members and, in particular, by the Projects Officer. Marwins Project Work Objectives (the deliverable items during the projects deployment) are explicitly described below.

Documents: Current analysis report Contracts with consultant, vendor Benchmarking reports Change management plan Change requests Organizational restructure report Key performance indicators report Software and hardware user manuals Contract with vendor Hardwares & softwares warranties Evaluation sheets User acceptance tests Personal authority guidelines Daily work reports Risk assessment Business case 5

Technological Professional Institute of Piraeus

Training documentation ROI assessment (Cost/Benefit Analysis) Cost estimation End-Item Specifications Report

Other deliverable items: Software package (CDs) Server PCs Modem/router Barcode printer Barcode scanners Cables

Responsibilities Business Management What

BSA

Approach to Delivery -How

Timing - When

Project justification

Funding allocation Deliverables approval

Steering committee

BIS

Assemble and present integrated business and IT architecture (data, applications, technology) or program architecture documentation. Document integrated prioritized projects and justifications for allocated value of the project to the business and IT. Report on allocation of funds at various phases of the PLF for the entire project Manage portfolio of projects deliverables within the funds allocated by program steering committee. Report to the program steering committee with direct accountability to the PM executive, and keep program working committee informed of current direction of the projects. Develop integrated program schedule for IT and business support initiatives.

Project Definition

Project Definition

Project Execution Project Execution

Project Execution

Project Execution

Table 1: Program Delivery Manager Major Responsibilities: Business Management Source: Integrated IT Project Management, Bainey, 2004

Technological Professional Institute of Piraeus

Responsibilities Project Management What

IT PDLC Scope Management/ Requirements Management Scope Management/ Project file Scope Management/ Project planning Scope Management/ Project progress tracking Cost Management

Approach to Delivery -How

Timing - When

Quality Management Contract Management Risk Management Change Management Issue Management Communications Management HR management PMO processes

Advise project managers on applying IT PDLC/phases and PM delivery processes Review project charters for integration, consistency and completeness, and advise on contents and structures Maintain a project file/repository for all IT projects Manage projects using integrated project plan as baseline Monitor project performance at appropriate milestones for schedule, cost, effort, scope and quality objectives Manage integrated business and IT resource plan for business, IT and PM budget and expense authorization Conduct QA reviews of the approved quality management plans Conduct contract reviews for the approved contract management plan Manage risks and evaluate the impact on the current scope, schedule, cost and quality baseline Conduct change request reviews for the approved change requests in the change management plan Conduct Issue request reviews for the approved issue requests in the issue management plan Manage communications management plan and recommend corrective actions Manage PSM and recommend corrective actions Provide policies, guidelines, best practices and templates to enable cost effective and efficient project delivery

Project Execution Project Definition & Execution Project Execution Project Execution Project Execution

Project Execution

Project Execution Project Execution Project Execution Project Execution Project Execution Project Execution Project Execution Project Execution

Table 2: Program Delivery Manager Major Responsibilities: Project Management Source: Integrated IT Project Management, Bainey, 2004

Technological Professional Institute of Piraeus

Responsibilities Technology Management What

Cost Estimating

Approach to Delivery -How

Timing - When

Resource Allocations

DA

AA

TA

Applications support services

Manage the cost estimates by reporting on the contents and recommended solutions to the appropriate management team. Manage the resource allocations by reporting on the contents and recommend solutions to the appropriate management team Manage the integrated DA by reporting on the contents and recommended solutions to the appropriate management team Manage the integrated AA by reporting on the contents and recommended solutions to the appropriate management team Manage the integrated TA by reporting on the contents and recommended solutions to the appropriate management team. Manage the integrated applications support model by reporting on the contents and recommended solutions to the appropriate management team.

Project Execution

Project Execution

Project Execution

Project Execution

Project Execution

Project Execution

Table 3: Program Delivery Manager Major Responsibilities: Business Management Source: Integrated IT Project Management, Bainey, 2004

The Inventory and Asset Tracking System implementation project at Marwin Ltd is composed of four phases (PLC) and various processes and tasks. The milestones set for the project are depicted in table 4.

Technological Professional Institute of Piraeus

Milestones

Phases/ Processes

Exit Criteria

Deliverable

Completion Date 11/3/2011

Selection of Inventory Management Specialist/Consultant Procurement Decision

Approach of Inventory Management Specialist Selection of SW, HW, Network, Vendor Chartering

Hiring of a skillful consultant, approved by Shopkeeper

Contract

Approval by CoRIT, Shopkeeper, Consultant, Financial Manager Examination and acceptance of proposed procedures Conclusion of Team Staffing and Member Selection

Contract, SW, HW, 30/3/2011 Warranties, User Guide Manuals Signed Business Case 5/4/2011

Decision to approve Project Plan

Delivery of personal Project Team authorization Development directives

Personal Sheet identifying authorization levels Printed Training Notes - User Manual CDs

12/4/2011

Delivery of training documentation

Training

Completion of 2-day training process

15/4/2011

SW release delivery

Initial App Development Project

Formulation of SWs general functionality Successful testing from users side

26/4/2011

User Acceptance

Personal sheets 16/5/2011 depicting acceptable system performance 1) CDs 2) Signed Approval Document 15/6/2011 1/6/2011

Delivery of final SW release

Shakedown

Completion of changes and bug-fixings. Initialization of systems normal function.

ROI Assessment

Onward and Upward Final Estimation of actual Financial report cost payback time

Table 4: Marwins Project Milestones & Exit Criteria

Technological Professional Institute of Piraeus

The Work Breakdown Structure (WBS) is among the first reports to be delivered. It illustrates the family tree of a project in a graphical and hierarchical format. In Marwins case, the WBS, following the simplified approach of the project development, is presented below.

Implementation of Inventory & Asset Management System

Chartering Project Development of detailed project plan Project Team Development Business modeling and reengineering Execution of change management plan Initial App Development Shakedown Upgoing and Ongoing Post implementation investment audit Continuos Improvement

Presketh of Business Case

Bugfixing and rework

Current State Analysis Approach of Inventory Management Specialists Definition of key performace indicators Selection of HW, SW, Networking, DB, Implementation Vendor Communication to organization Initial Plans for how system will be rolled out, supported, etc Definition of Organizational changes, incentives Decicion to proceed and appove project plan

System performance tuning

Problem Resolution

Process and procedure changes Adding people to accomodate learning and shakedown needs Delivery of final SW release

Installation

Testing

Bugfixing

Rollout & Startup

Training

User Acceptance Testing

Figure 1: Marwins WBS

Once the tasks are identified, the resources required to bring them off should be recognized. Labor, equipment, facilities and capital are the most common resources needed in a project. 10

Technological Professional Institute of Piraeus

In an ERP implementation project, the factor Labor constitutes, in fact, the Project team. According to Nah, Lau and Kuang (2001), an ERP implementation project presumes the constitution of a cross-functional team composed of both external consultants and internal staff. In Marwins example, the human contributors to the project would be the following: 1. Project Manager/Shopkeeper 2. Project Officer 3. Consultant 4. Vendors Technician 5. Financial Manager 6. Production Manager 7. Inventory Manager 8. CoR IT 9. Accountant 10. Workers The general requirements (including equipment) for the Marwin Project are depicted in Figure 2.

Figure 2: Projects Requirements

11

Technological Professional Institute of Piraeus

Figures 3, 4, 5, 6 and 7 are snapshots taken from the PPD file demonstrating the resource usage.

Figure 3: Resource Usage (1)

Figure 4: Resource Usage (2)

12

Technological Professional Institute of Piraeus

Figure 5: Resource Usage (3)

Figure 6: Resource Usage (4)

13

Technological Professional Institute of Piraeus

Figure 7: Resource Usage (5)

The use of resources should be scheduled in a time efficient manner. If certain tasks can take place concurrently without affecting the overall cost, the plan should be adjusted to resource availability per chronic period. Tasks that may not be displaced or retarded without prolongating the delivery of the overall project form what is called the Projects Critical Path. Scheduling with overloaded resources is a deemed to fail strategy and a rather common error in project realizations. The schedule of Marwins project is attached in Annex I of this paper.

14

Technological Professional Institute of Piraeus

Chapter 4. Monitoring and Controlling

Monitoring and Controlling are two procedures that should be treated as one. As described in the previous chapter, milestones facilitate the control of a project. Yet, they are not the only progress tracing means. Lewis (2007) argues that prior to formulating a control system, the Project Champion should: Clarify to project team members their proper objectives Make sure that team members have a personal plan aligned with the project plan Provide team members with adequate resources and skills Feedback performance assessment to performers Set authority framework for each member

The design of a Control System presupposes that the Project Leader has straightened out: a. b. c. d. What is important for the company What we are trying to accomplish Which points of work are more vital to track and control What are the critical points in the project at which control should be placed

Although monitoring performance is of major importance in a Project, taking corrective actions on time is equally crucial. Response to control should be prompt. This can be attained though: 1. Asking team members for daily work reports. 2. Applying the KISS (Keep It Simple, Stupid!) principle and checking whether reports are read by their recipients or not. 3. Establishing reviews i. Status reviews: Checking on the schedule ii. Process reviews: Checking on how something is done iii. Design reviews: Tests

Each Process Review meeting should be followed by a report containing: 1 . 2 . 3 . 4 . 5 . 6 . Current project status through Earned Value Analysis Future status: Expected deviations and corrective actions Status of critical tasks Risk Assessment Information usable to other projects Constraints of process review

15

Technological Professional Institute of Piraeus

The Earned Value Analysis usually includes the following computations: Cost variance: Compares cost deviations of work performed Schedule variance: Compares planned and actual work performed BCWS (Budgeted cost of work scheduled) to be done in a given moment or effort level supposed to be performed in that period BCWP (Budgeted cost of work performed) in a given period, or the Budgeted level of effort actually performed ACWP (Actual cost of work performed) at a given moment Cost Variance= BCWP-ACWP Schedule Variance= BCWP-BCWS

Forecasting risks associated to the project through a Risk Assessment report is also a critical as well as trying issue. Risk identification should start as soon as the project is conceived and continue throughout the projects execution. Status and process review meetings should therefore occupy with eventual obstacles. The risk assessment of Marwins Project is adopted from Marcus and Tanis (2000) proposed Project Life Cycle mode and illustrated in Annex I.

16

Technological Professional Institute of Piraeus

Annex I. A Recommendatory Report to Marwins Shopkeeper

Implications: The project manager will be the Shopkeeper himself. The author of this report will be, on the other hand, the project officer, also referred to as project charter. The project is currently at the end of the first phase of its PLC, awaiting approval by the shopkeeper to proceed. As aforementioned, due to space constraints, two versions of the PPD file are developed.

TRANSMITTAL LETTER

March 30, 2011 Mr. Antony Jenkins General Manager Marwin Tools Ltd Dear Mr. Jenkins: I am submitting to you a report to let you know the benefits and the procedure of an Inventory and Asset tracking system implementation. The report is entitled Implementing Wasp in Marwin Tools Ltd. The content of this report concentrates on a plan to implement an ERP system in Marwin. If you should have any questions concerning my project/paper recommendation, please, feel free to contact me at 6945454544. Sincerely, Anthony Frisk

17

Technological Professional Institute of Piraeus

Implementing Wasp in Marwin Tools Ltd

Problem Statement: Marwin Machines Tools operates in two shifts and its current inventory tracking system is operated manually by the shopkeeper. The employees make their requests for clothing or equipment by completing a sheet and then the Shopkeeper mitigates the data from the sheet to an Access database, losing precious time and risking the accuracy inputted data. The inventory system is not updated automatically and the company is mandated to conduct spot checks in the warehouses every now and then to ensure that the data are in accordance with the actual inventory status. Mission Statement: The mission for this project is to develop a new Inventory & Asset Management System that will facilitate tracking procedures. The target audience is primarily the companys Shopkeeper and secondarily other Top Management members as well as people belonging to the category of project clients. Project Work Objectives: Provide the Shopkeeper with An automated tool to aid in the tracking of inventory, rather than missing 15 minutes of work time every time a spot checkup is performed. A networked solution, accessible out of the keepers office, which will enable ubiquitous Inventory management, diminishing hence Inventory errors. An application with flexible reporting capabilities, delivered by July, this summer. Scope Inclusions: 1. Interface between the Employee Database and the Shopkeepers application. 2. Interface between the barcode printer software and the Shopkeepers application. 3. The tracking of Shopkeeper inventory including both equipment and clothing. 4. In addition to reports and forms used by the Shopkeeper, there is a requirement to provide inventory reports for the City of Raleighs internal auditors. Scope Exclusions: 1. The tracking of assets or inventory outside of the Shopkeepers i.e. vehicles etc. 2. The formal creation of a Purchase Order. 3. An interface between the Shopkeepers application and FIS (internal Purchasing system).

18

Technological Professional Institute of Piraeus

Project Summary:

Figure 8: Overview; Project Summary; Elaborate version

Projects Life Cycle (per Marcus)

Phase I: Chartering
Conception of Business Case Current State Analysis Approach of Inventory Management Specialist Quest for Inv. Management Specialist Set up of appointments with Inv. Management Specialists Actualization of appointments Selection of Specialist Definition of key performance indicators and process of measurement Selection of SW, HW, Networking, DB, Vendor Market Research Offer Demand Offer Accumulation Offer Evaluation Selected Products Presentation Internal Company Meetings Procurement Decision Communication to Organization Detailed Information of Shopkeeper Initial Information of related managers Initial plans for how system will be rolled out, supported, maintained and upgraded Definition of Organizational changes, incentives relation to system performance Decision to proceed and approve project plan

Phase II: Project

Development of detailed project plan Status and Process Review Meetings (Ongoing Project & Risk Management) Project Team Development Negotiations & Preassignments Staffing Delivery of personal authorization directives Training HW Installation Training Ground Preparation Training of project team members and acquisition of supportive skills Prevision of training documentation Business modeling and reengineering Execution of change management plan Initial App Development SW configuration SW customization System Integration Software release delivery Integration of SW bolt-ons and/or legacy systems Data cleanup and conversion Documentation Testing Bugfixing Rollout & Startup User Acceptance

Phase III: Shakedown

Bugfixing and rework System performance tuning Problem resolution Process and procedure changes Adding people to accommodate learning and shakedown needs Delivery of final SW release

Phase IV: Onward and Upward

Post Implementation investment audit ROI Assessment Continuous business improvement

Table 5: Projects Life Cycle Model

19

Technological Professional Institute of Piraeus

Risk Assessment (per Marcus)

Phase 1: Chartering Wrong SW, HW and/or partner decision Discrepancy between business plan and tech plan Utopian business case and project objectives Poor performance indicators Inadequate contracting with vendor and/or consultant Lack of post-implementation support Belittling Change Management Taking organizational requirements amiss Phase 2: Project Staffing project team without cross-functional representation Low-quality SW, documents, training Difficulty acquiring skills in SW usage Poor knowledge from the vendors and/or consultants side Unsuccessful management of scope, schedule and/or budget Errors in data migration Mistaken assumption that costs will be taken care of by operations budgets Configuration and/or customization errors Lack of communication with consultant Vendor delivery and SW performance issues Difficult-to-use SW Diminishing testing and/or training for scheduling reasons Lack of reporting Phase 3: Shakedown Business disruption Wrong issue/problem diagnosis Lack of post-training skill building Inadequate use of system Overdependence on key user Resistance to Change Phase 4: Onward & Upward Error in outcome estimation No updates Unavailability of configuration documents Turnover of trained staff Inability to manage outcomes No organizational learning about IT projects, enterprise systems Table 6: Projects Risk Assessment

20

Figure 8: Gantt Chart & Critical Path: A snapshot taken from PPDs file report

Technological Professional Institute of Piraeus

21

Technological Professional Institute of Piraeus

Conclusion/ Recommendation Given that the cost of the project is approximately 100000 (all resources taken into account), the fact that Inventory related errors will be eliminated and that the Shopkeeper, the head of the company, will save many hours from his everyday work, proceeding with the implementation is highly recommended.

22

Technological Professional Institute of Piraeus

References

Bainey, K. R. (2004). Integrated IT Project Management: a model-centric approach. Norwood: Artech House. Cobb, A. T. (2006). Leading project teams: An introduction to the basics of Project Management and Project Team Leadership. Thousand Oaks, California: Sage Publications. Juran, J. M., & Godfrey, B. A. (1999). Juran's Quality Handbook (5th Edition ed.). McGraw Hill. Markus, L. M., & Tanis, C. (2000). The Enterprise Systems Experience-From Adoption to Success. In R. W. Zmud, Framing the Domains of IT Research: Glimpsing the future Trough the Past (pp. 173-207). Cincinnati: Pinnaflex Educational Resources. Nah, F.-H. F., Lau, J. L.-S., & Kuang, J. (2001). Critical factors for successful implementation of enterprise systems. Business Process Management Journal , 7 (3), 286-296. PMI. (1996). Project Management Body of Knowledge (PMBOK). Sylva, North Carolina.

23