Industrial Project Management (Assignment II)

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 2Chapter 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

Chapter 1. IntroductionChapter 1. Introduction

1


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 Shopkeeper’s job.

The company’s 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 organization’s smooth function.

The objective of the following project is to harmonize the Shopkeeper’s 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 Marwin’s 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.

Chapter 2. Problem Definition and ResponseChapter 2. Problem Definition and Response

2


Project Management is applicable in problematic situations. Those are its “raisons d’être”. 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 Marwin’s 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 company’s vision.

A Mission Statement does not only constitute a written declaration of the project’s direction, but also a political tool, especially when eventual conflicts arise during the project’s 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)

In Marwin’s example, the Mission Statement could look like the following:

3


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 company’s 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 Marwin’s 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 keeper’s 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 project’s 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.

Chapter 3. Documentation and DeliverablesChapter 3. Documentation and Deliverables

4


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 Manager’s tasks could be treated by other project team members and, in particular, by the Project’s Officer. Marwin’s Project Work Objectives (the deliverable items during the project’s 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• Hardware’s & software’s warranties• Evaluation sheets• User acceptance tests• Personal authority guidelines• Daily work reports• Risk assessment• Business case• Training documentation• ROI assessment (Cost/Benefit Analysis)• Cost estimation• End-Item Specifications Report

5


Other deliverable items:

• Software package (CDs)• Server• PCs• Modem/router• Barcode printer• Barcode scanners• Cables

Responsibilities - Business Management What

Approach to Delivery -How Timing - When

BSA Assemble and present integrated business and IT architecture (data, applications, technology) or program architecture documentation.

Project Definition

Project justification Document integrated prioritized projects and justifications for allocated value of the project to the business and IT.

Project Definition

Funding allocation Report on allocation of funds at various phases of the PLF for the entire project

Project Execution

Deliverables approval Manage portfolio of projects deliverables within the funds allocated by program steering committee.

Project Execution

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.

Project Execution

BIS Develop integrated program schedule for IT and business support initiatives.

Project Execution

6

Table 1: Program Delivery Manager Major Responsibilities: Business Management

Source: Integrated IT Project Management, Bainey, 2004


Responsibilities – Project Management What


IT PDLC Advise project managers on applying IT PDLC/phases and PM delivery processes

Project Execution

Scope Management/ Requirements Management

Review project charters for integration, consistency and completeness, and advise on contents and structures

Project Definition & Execution

Scope Management/ Project file

Maintain a project file/repository for all IT projects

Project Execution

Scope Management/ Project planning

Manage projects using integrated project plan as baseline

Project Execution

Scope Management/ Project progress tracking

Monitor project performance at appropriate milestones for schedule, cost, effort, scope and quality objectives

Project Execution

Cost Management Manage integrated business and IT resource plan for business, IT and PM budget and expense authorization

Project Execution

Quality Management Conduct QA reviews of the approved quality management plans

Project Execution

Contract Management Conduct contract reviews for the approved contract management plan

Project Execution

Risk Management Manage risks and evaluate the impact on the current scope, schedule, cost and quality baseline

Project Execution

Change Management Conduct change request reviews for the approved change requests in the change management plan

Project Execution

Issue Management Conduct Issue request reviews for the approved issue requests in the issue management plan

Project Execution

Communications Management

Manage communications management plan and recommend corrective actions

Project Execution

HR management Manage PSM and recommend corrective actions

Project Execution

PMO processes Provide policies, guidelines, best practices and templates to enable cost effective and efficient project delivery

Project Execution

7

Table 2: Program Delivery Manager Major Responsibilities: Project Management



Responsibilities – Technology Management What


Cost Estimating Manage the cost estimates by reporting on the contents and recommended solutions to the appropriate management team.

Project Execution

Resource Allocations Manage the resource allocations by reporting on the contents and recommend solutions to the appropriate management team

Project Execution

DA Manage the integrated DA by reporting on the contents and recommended solutions to the appropriate management team

Project Execution

AA Manage the integrated AA by reporting on the contents and recommended solutions to the appropriate management team

Project Execution

TA Manage the integrated TA by reporting on the contents and recommended solutions to the appropriate management team.

Project Execution

Applications support services

Manage the integrated applications support model by reporting on the contents and recommended solutions to the appropriate management team.

Project Execution

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.

Milestones Phases/ Processes Exit Criteria Deliverable Completion

8

Table 3: Program Delivery Manager Major Responsibilities: Business Management



Date

Selection of Inventory Management Specialist/Consultant

Approach of Inventory Management Specialist

Hiring of a skillful consultant, approved by Shopkeeper

Contract 11/3/2011

Procurement Decision

Selection of SW, HW, Network, Vendor

Approval by CoRIT, Shopkeeper, Consultant, Financial Manager

Contract, SW, HW, Warranties, User Guide Manuals

30/3/2011

Decision to approve Project Plan

Chartering Examination and acceptance of proposed procedures

Signed Business Case

5/4/2011

Delivery of personal authorization directives

Project Team Development

Conclusion of Team Staffing and Member Selection

Personal Sheet identifying authorization levels

12/4/2011

Delivery of training documentation

Training Completion of 2-day training process

Printed Training Notes - User Manual

15/4/2011

SW release delivery Initial App Development

Formulation of SW’s general functionality

CDs 26/4/2011

User Acceptance Project Successful testing from user’s side

Personal sheets depicting acceptable system performance

16/5/2011

Delivery of final SW release

Shakedown Completion of changes and bug-fixings. Initialization of system’s normal function.

1) CDs

2) Signed Approval Document

1/6/2011

ROI Assessment Onward and Upward Final Estimation of actual cost payback time

Financial report 15/6/2011

9

Table 4: Marwin’s Project Milestones & Exit Criteria


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 Marwin’s case, the WBS, following the simplified approach of the project development, is presented below.

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.

In an ERP implementation project, the factor Labor constitutes, in fact, the Project team.

10

Implementation of Inventory & Asset

Management System

Chartering

Presketh of Business Case

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

Project

Development of detailed project plan

Project Team Development

Business modeling and reengineering

Execution of change management

plan

Initial App Development

Installation

Testing

Bugfixing

Rollout & Startup

Training

User Acceptance Testing

Shakedown

Bugfixing and rework

System performance tuning

Problem Resolution

Process and procedure changes

Adding people to accomodate

learning and shakedown needs

Delivery of final SW release

Upgoing and Ongoing

Post implementation investment

audit

Continuos Improvement

Figure 1: Marwin’s WBS


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 Marwin’s example, the human contributors to the project would be the following:

1. Project Manager/Shopkeeper

2. Project Officer

3. Consultant

4. Vendor’s 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.

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

11

Figure 2: Project’s Requirements


12

Figure 3: Resource Usage (1)



13




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 Project’s Critical Path.

Scheduling with overloaded resources is a deemed to fail strategy and a rather common error in project realizations.

The schedule of Marwin’s project is attached in Annex I of this paper.

14



Chapter 4. Monitoring and ControllingChapter 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. What is important for the companyb. What we are trying to accomplishc. Which points of work are more vital to track and controld. 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 scheduleii. Process reviews: Checking on how something is done

iii. Design reviews: Tests

Each Process Review meeting should be followed by a report containing:

1. Current project status through Earned Value Analysis2. Future status: Expected deviations and corrective actions3. Status of critical tasks4. Risk Assessment5. Information usable to other projects6. Constraints of process review

15


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 project’s execution. Status and process review meetings should therefore occupy with eventual obstacles.

The risk assessment of Marwin’s Project is adopted from Marcus and Tanis’ (2000) proposed Project Life Cycle mode and illustrated in Annex I.

16


Annex I. A Recommendatory Report toAnnex I. A Recommendatory Report to Marwin’s Shopkeeper Marwin’s Shopkeeper

TRANSMITTAL LETTER

March 30, 2011

Mr. Antony JenkinsGeneral ManagerMarwin 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

Implementing Wasp in Marwin Tools Ltd

17

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.


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 company’s 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 keeper’s 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 Shopkeeper’s application.2. Interface between the barcode printer software and the Shopkeeper’s 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 Raleigh’s internal auditors.

Scope Exclusions:1. The tracking of assets or inventory outside of the Shopkeeper’s i.e. vehicles etc.2. The formal creation of a Purchase Order.3. An interface between the Shopkeeper’s application and FIS (internal Purchasing

system).

Project Summary:

18


Project’s Life Cycle (per Marcus)Phase I: CharteringConception of Business CaseCurrent State AnalysisApproach of Inventory Management Specialist

Quest for Inv. Management SpecialistSet up of appointments with Inv. Management SpecialistsActualization of appointmentsSelection of Specialist

Definition of key performance indicators and process of measurementSelection of SW, HW, Networking, DB, Vendor

Market ResearchOffer DemandOffer AccumulationOffer EvaluationSelected Products’ PresentationInternal Company MeetingsProcurement Decision

Communication to OrganizationDetailed Information of ShopkeeperInitial Information of related managers

Initial plans for how system will be rolled out, supported, maintained and upgradedDefinition of Organizational changes, incentives relation to system performanceDecision to proceed and approve project plan

Phase II: ProjectDevelopment of detailed project planStatus and Process Review Meetings (Ongoing Project & Risk Management)Project Team Development

Negotiations & PreassignmentsStaffingDelivery of personal authorization directives

TrainingHW Installation – Training Ground PreparationTraining of project team members and acquisition of supportive skillsPrevision of training documentation

Business modeling and reengineeringExecution of change management planInitial App Development

SW configurationSW customizationSystem IntegrationSoftware release delivery

Integration of SW bolt-ons and/or legacy systemsData cleanup and conversionDocumentationTestingBugfixingRollout & StartupUser Acceptance

Phase III: ShakedownBugfixing and reworkSystem performance tuningProblem resolutionProcess and procedure changesAdding people to accommodate learning and shakedown needsDelivery of final SW release

Phase IV: Onward and UpwardPost Implementation investment auditROI AssessmentContinuous business improvement

19

Figure 8: Overview; Project Summary; Elaborate version

Table 5: Project’s Life Cycle Model


Risk Assessment (per Marcus)Phase 1: Chartering

Wrong SW, HW and/or partner decisionDiscrepancy between business plan and tech planUtopian business case and project objectivesPoor performance indicatorsInadequate contracting with vendor and/or consultantLack of post-implementation supportBelittling Change ManagementTaking organizational requirements amiss

Phase 2: ProjectStaffing project team without cross-functional representationLow-quality SW, documents, trainingDifficulty acquiring skills in SW usagePoor knowledge from the vendor’s and/or consultant’s sideUnsuccessful management of scope, schedule and/or budgetErrors in data migrationMistaken assumption that costs will be taken care of by operations budgetsConfiguration and/or customization errorsLack of communication with consultantVendor delivery and SW performance issuesDifficult-to-use SWDiminishing testing and/or training for scheduling reasonsLack of reporting

Phase 3: ShakedownBusiness disruptionWrong issue/problem diagnosisLack of post-training skill buildingInadequate use of systemOverdependence on “key user”Resistance to Change

Phase 4: Onward & UpwardError in outcome estimationNo updatesUnavailability of configuration documentsTurnover of trained staffInability to manage outcomesNo organizational learning about IT projects, enterprise systems

20

Table 6: Project’s Risk Assessment


21

Figu

re 8

: Gan

tt C

hart

& C

ritica

l Pat

h: A

sna

psho

t tak

en fr

om P

PD’s

file

repo

rt


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


ReferencesReferences

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

Industrial Project Management (Assignment II)

Documents

technological

final sw release

conduct spot

program steering

top management

work breakdown

losing precious

asset management