Lesson №6. More and more software tools are reaching into the small and medium-sized (SME) manufacturing markets to help companies synchronize enterprise.

Lesson №6

More and more software tools are reaching into the small and medium-sized (SME) manufacturing markets to help companies synchronize enterprise systems with lean-manufacturing processes.

The goal - to achieve real-time communication and integration of material and information flows. Even though the initial price points of these software tools are becoming attractive, a system implementation requires much more than just buying "Lean- Enabled" software.

Implementing any new business information system or updating a current system is a drain on a company's most valuable resources…time and people, to name a few. If you are in the planning stages, or even in the middle, of enhancing your Lean

Manufacturing environment by addressing your information systems needs, take a look at the following action bullets. Sound planning of the implementation is crucial to its success as poor planning and inadequate resourcing are often primary causes of system implementation

failures. Careful planning and efficient management of the implementation are vital to success and to negate the threats of spiralling costs, extended timescales, losing

key personnel and general dissatisfaction with the outcome.

2

The scope of a pan-organisational software system implementation can be huge. Not only does it include installation of the new software and the hardware it is to run on, but also precipitates a panoply of potentially difficult and unavoidable human factors. Appreciating the conflicts that may arise will enable the organisation’s management to predict likely trouble spots and mitigate accordingly and in good time.

The key skill is for the company’s management to understand that the new system by itself is not some sort of silver bullet. The entire implementation process involves the complete business process and/or pedagogic practice, customer service, interaction with suppliers and a bond with all other interested stakeholders.

3

Many less tangible activities are crucial and those involved must: Have a sound understanding of the organization, particularly in terms of its culture and values; Understand the rationale behind any new system implementation; Should have thoroughly considered how the system is likely to help provide a better service to all concerned with it; Undertake a very comprehensive review of all business processes and, where necessary, pedagogic practice, and begin to develop and introduce new policies and procedures before

tuning the system to meet the agreed requirements; Have a complete appreciation of the complexity and flexibility of the system; Have an understanding of the inherent dangers of customisation of any software and how these can be mitigated against; Conduct a thorough set of system testing procedures, whilst accepting the potential need for software 'bug fixes' and upgrades; Budget for the real costs of staff time for their training and development; Train all users to use the live system and to fault-find and correct autonomously.

4

5

Identify unique business requirements, before they become "fatal flaws”;

Validate the selection of the candidate software solution against key business objectives;

Balance the implementation of a totally new "integrated" system versus utilizing new technology to integrate legacy systems;

Tie specific implementation project goals to operational business objectives;

Chose a software solutions supplier you can "live" with;

Balance re-engineering business processes with system functionality versus customized solutions;

Reduce, or at least understand, risks;

Work within company culture and set operating ground rules for the project team;

6

Gain commitment from the boardroom to the lunchroom;

Encourage functional ownership;

Keep credit and blame in-house;

Use consultants to "think outside the box" or expand resources for one-time needs;

Report progress to the boardroom and the lunchroom;

Follow a well thought out project plan, but always have a contingency plan;

Utilize milestones and mini-projects to conquer and divide a massive undertaking;

Understand the power of a conference room pilot, trade-offs on parallel processing, and the positive investment in testing and reporting environments;

Understand the total cost of ownership and the learning curves of maintaining operational software;

Keep to the training plan, but plan more training.

7

A good plan of action is useless unless it is executed efficiently. Good project management methodology is crucial in following through on the planning of a project.

Some project managers are very good at planning a project but fall short when it comes to the implementation of the project. Controls, checks and balances keep the project on track. Since the follow-through from the scope and design phase is so important for the success of a project it is vital to consider the second two project management phases in more depth.

Now that the project management implementation phase has been entered into and the groundwork is complete, implement or roll out the project as per project plan. The following will need to be done during this phase: Project Meetings and Minutes

Hold regular meetings as required by the project communication protocol guidelines. This would have been defined in the “scope and design” phase. These meetings should be properly minuted. Create a “meeting minutes” template which should include apologies, points discussed, what action needs to be taken and attendees. Circulate these minutes as soon as possible after the meeting. Implement predefined sanctions, if any, for those who fail to attend.

8

Implement other communication and reporting protocols as defined by the project communication protocol guidelines. These could include things like “memo acceptance” forms, read receipts for e-mail, regular reporting to supervisors or managers. This might also include certain types of request requisition forms and the like.

While the Project Manager would not want to micro-manage, a certain amount of documented procedures and bureaucracy is vital for the success of the project.

Some projects require ongoing testing of a product or products. This is particularly true of software development and roll-out projects. Implement predefined procedures for the testing and remediation of the project.

Document testing: Under what conditions When By whom With what objective How Conclusion report Sign off of testing if successful

9

Remediation if testing failed: Send the product back for remediation with all test documentation along with a "test failure" form. Communicate with remediation team. Estimate delay. Adjust project plan Reporting: Report on possible delays and the reason for such and how long it will take for the remediation.

Analyze the Project for Scope Creep Scope creep can adversely affect the outcome of the project if it is not kept in check. Scope creep and how it will affect the project needs to be reported on immediately. Report on how scope creep can be handled in line with any planned for "late start" for the particular task contributing

to it. Contractors and staff who are not meeting deadlines need to be dealt with as set out during the planning phase of the project. It is advisable to use a good project management software package to manage tasks and resources and how scope creep will affect the overall project. There is a wide range of good quality software tools available.

10

Important Factors During Implementation Phase: The following of predefined communication protocol is vital during this phase of the project. If something goes wrong it needs to be addressed as quickly as possible to avoid impacting too severely on the

rest of the project. Scope creep should be addressed immediately by using the proper communication protocols. Testing and remediation protocols should be strictly adhered to. Communicate continually.

Obtain Approval and Sign Off: Now that the project has been rolled out successfully, there are just two things left to do before moving into the “commissioning and hand over” phase: Obtain approval for the “commissioning and hand over” phase to start. Sign off the implementation” phase.

11

Risk assessment and risk management are regarded as key activities during preparation, critical reviews and implementation of a major application system like a VAT system.

The risks that may impede the implementation covers a much broader spectrum than that of the information system itself as depicted below.

The scope of the implementation strategy should reflect this fact in order to safeguard the system implementation.

Risks are categorized in three major groups: Requirement risks Organizational risks Technical risks

The section also briefly describes impact, assessment and counter measures or contingencies which may reduce the likelihood and/or cushion the impact.

12

General uncertainties ◦ Acceptance criteria not described, or with no links to requirements ◦ Requirements not defined as mandatory or preferred ◦ Formal description are used instead of prototypes to document requirement ◦ Requirement-writers lack of understanding of the business area ◦ Poor structure of requirement description ◦ Uncertain level of user acceptance of requirements

Uncertain or unfeasible functional requirements ◦ Legal framework unclear or unsettled ◦ Administrative procedures/user handbook not drafted ◦ Scope of information system (in scope/out of scope) unclear ◦ Evolving requirements ◦ Interfaces to other systems unclear ◦ Application standards (if any relevant) not prescribed

Unclear or missing implementation requirements ◦ Implementation and roll-out strategy unclear ◦ Training requirements not defined ◦ Unclear responsibility for administrative procedures and forms ◦ Documentation and help requirements unclear ◦ Implementation flexibility and maintainability not defined ◦ Quality assurance measures unclear ◦ Use of interim systems and/or conversion or data take-on unclear

13

Unclear or missing operational requirements ◦ Technical standards unclear ◦ Data entry concept unclear ◦ User interfaces (users, operators, system administration) not defined ◦ Security, reconciliation and auditability - requirements unclear ◦ Volume of transactions, users and locations unclear ◦ Distribution and service availability concept unclear ◦ Service levels (availability/continuity, response time, turn-around times) not defined ◦ Service level monitoring not specified ◦ Storage and archives requirements not defined

Unclear or missing contents in contract agreement and conditions ◦ Roles and responsibilities unclear ◦ Delivery plan unclear ◦ Delivery and payment not tied together ◦ Acceptance procedures unclear ◦ Quality assurance procedures unclear ◦ Dispute escalation and settlement unclear

14

Customer participation unclear ◦ Customer and other stakeholders not defined (right parties involved ?) ◦ Customer involvement in specification and test not agreed ◦ Preparedness of user organization unclear ◦ General acceptance by stakeholders unclear

Expectation management unclear ◦ Expectations (requirements, parties and tasks) not clearly described ◦ Schedule not clear and acceptance by parties (stakeholders) unclear ◦ Unclear if all parties are informed and involved (including taxpayers)

Project resources uncertainties ◦ Project office and facilities not described ◦ Computer development and test environment not described ◦ Human resources available to the project not specified

Project management uncertainties ◦ Project Manager(s) (management team) not capable ◦ Project Organization (roles, authorities, responsibilities) undefined ◦ Project Plan lacks quality (is not comprehensive, feasible, or with unrealistic schedule) ◦ Subcontractor management shaky or non existent ◦ Management of other externally performed tasks critical to the implementation shaky or non existent ◦ Quality management not specified

Operation and support uncertainties ◦ Strategy for operation of the system unclear ◦ Strategy for maintenance and support unclear

15

Technology and infrastructure uncertainties

◦ Use of unproven technology

◦ Use of outdated system software or hardware

◦ Stance on technical standards (use of commercially viable standards) untenable

◦ Level of integration to other systems and/or other platforms untenable

◦ Technical infrastructure unavailable

◦ Buildings and premises not ready

Technical skills and resources - uncertainties

◦ Use of unfamiliar methodologies and tools

◦ Skills within implementation project and user organization questionable

◦ Skills and abilities of vendors and subcontractors questionable

◦ Availability of spare parts questionable

16

Loss of control of project ◦Unpredictable costs

◦Delays in the implementation

◦Waste of time and resources

◦Wrong or not working information system

Business implications of project failure ◦ Loss of revenue

◦ Loss of credibility with taxpayers

◦ Loss of credibility for Department within Government

Loss of credibility for sponsor and consultants

17

Each identified risk has to be assessed for:◦ Likelihood ◦ Likely impact period ◦ Severity of impact

Counter measures or contingencies to minimize the likelihood and severity also have to be described as:◦ Counter measures in project plan (agreed action) ◦ Other counter measures

Planned counter measures will typically be expressed in tasks and their related deliverables for inclusion in the project plan. As an example, the formulation of a policy for operation and support will deal with a number of organizational and technical risks.

18

Finally, it is crucial that the “go live” day causes as little disruption to the day-to-day business as is reasonably practicable. Issues that only arise at this juncture become magnified and will undeniably adversely affect the organisation's reputation, sometimes irrevocably, with all stakeholders. It is important to remember that poor project management and lack of communication at this crucial stage can ruin an otherwise faultless implementation.

Of course, there will always be some glitches and problems on the day, but the implementation of the guidance continued in this article will ensure that these are kept to a minimum and remain entirely manageable.

Project Management Commissioning and Hand Over Phase - this stage of the project is basically the “tying up of loose ends” part of the project . The procedure is as follows: Review final product by way of presentation with the project sponsor and the client. Transfer product responsibility by way of a "sign off" and formally hand over the product. Project evaluation and analysis to be completed. Document all findings and get the project sponsor and the project committee to sign off report. Release and redirect staff with the appropriate documentation. Sell, return or redirect tools and equipment along with a report on any damage or problems. Complete and file any outstanding documentation. The hand-over phase will give the project manager the opportunity see what went wrong and what went right during the project; and why .

19