Implementation of ShipManagement Systems Project Management

Editor's Notes

• #2: T his presentation is a high-level overview of the system selection process.
• #3: The slides that follow will discuss the details needed to determine how to analyze each package and determine how well it meets your requirements.
• #5: Companies come in all shapes, sizes, and styles; big and small, owning tankers and bulk carriers, owning 2 vessels and fleet, etc. No matter the shape or size, some processes are identical for all companies (i.e., accounts receivable) whereas others are company specific (i.e., inventory control). The one thing your company has in common with all other companies is that you will benefit by using the "right" software package to improve your business. On the other hand, choosing the wrong software package can be a catastrophe.
• #6: Selecting the wrong package can be worse than not selecting a package at all. The wrong package can lead to: To make a long story short, most companies end up of struggling to implement the system. Either because the package are not meeting certain requirements and modifying the package is very expensive. We end up having Low users' morale, over budget and time or worse shelfware application. If we can only spend an additional month or two performing a good package selection phase we would save enormous time later on in the implementation. More importantly, we would have a successful implementation instead of shelfware (a package that sits on the shelf instead of being used).
• #7: Selecting a software package is like selecting a house. There are five important criteria that need to be considered. They are: Current Requirements: What do you want in the house? What type of house, neighborhood, number of rooms, etc.? Technical Requirements: How easy will it be to make changes to the house? Is it in a historic district? Is there room on the lot to expand? Implementability: How easy will it be to move into the house? Will there be trouble getting a mortgage? Is the house in move-in condition? Supportability: What type of maintenance will the house require (the older the house the more likely something will need to be fixed)? Is the exterior wood or aluminum siding, etc.? Cost: Total cost of the house including purchase price, mortgage, taxes, maintenance, etc.
• #8: With regard to choosing a software package, the criteria can be defined as the following: Current Requirements: Ability of the package to meet the company's current business requirements. Future Requirements: Ability to modify the package to meet the company's new requirements as they become known. Implementability: Ability to implement the package easily. Supportability: Ability of the vendor to support both the package and the company in the future. Cost: Total cost to purchase and implement the package as well as ongoing maintenance and support costs. If employees will quit or there will be more employee absenteeism, the impact should be translated into the dollar impact on the company. Although the list may seem simple enough, because of the criteria interaction with each other it therefore becomes complicated. Your company's goal is probably to have a package that not only meets all your current and future requirements, but is cheap, easy to modify and implement, and is fully supported by the vendor. Unfortunately, this is usually an unrealistic expectation. Before you choose a software package you must determine, based on the company's vision and strategy, the relative importance of each criteria. For example, a company may want a package that meets their future requirements and is easy to implement. But meeting future requirements often requires purchasing a package that uses the latest technology. A package that is based on the latest technology can be problematic to implement. Because the package is new and has not been successfully implemented by other companies, it will likely contain bugs. This will cause the package to be difficult to implement.
• #9: As part of my work I developed worksheet will help in determining which package is right for us, and here's how we fill it in. That means that the average rating for a criteria is twenty. If a criteria is extremely more important than the other criteria then you rank the criteria forty. On the other end of the spectrum if the criteria has absolutely no importance rate it a zero (this is very unusual). Remember, the total of the criteria must total 100. This ensures that you have relative ratings.
• #10: The criterion that the company cares most about is the Current Requirements. Relative to the other criteria, it considered it more important that the other criteria. It considered the Techinal Requirements Below-average importance. Implementability was of above importance. Supportability is slightly below average importance when compared with the other criteria, whereas Cost had relatively little importance.
• #11: Identifying business Requirements, I will describe how you can develop your current requirements and prioritize them based on your need. you will ask the vendors how they rate against your current requirements. we will analyze the vendors' responses and rate each vendor. Finally we will ask the vendors to show you how they meet your current requirements
• #12: If you're not sure where you're going, you're liable to end up someplace else - and not even know it. To determine if the package meets your current requirements and hits your target, you need to know exactly what you need the package to do and you must be able to articulate it. This may sound obvious but you would be surprised at how many companies have problems determining what they need. One company thought that its requirements for a new package were the thirty requirements that their current package did not perform. When asked about the thousand or so other requirements that their current package performed, they said, "every package does what our current package does." They failed to realize that the system they were using had been modified over the last ten years to meet their specific needs.
• #14: Business area requirements Determine business areas i.e. crew & payroll, marine accounting, PMS, all departments Prioritize business areas there are current requirements that are critical to the business and others that are important to the business. There are other current requirements that would be nice to have and others that might be used if the package had the functionality. a particular package may meet the requirements of certain business areas better than those of other business areas. To ensure that the package selected best meets your company's overall current requirement, determine which business areas are most important. This is done by rating each business area in its importance to the company. Best of Breed When a package needs to cover multiple business areas, there is the possibility of choosing different packages, or modules from different business areas, and then integrating them (make them work together). This is known as best of breed . It can lead to a solution that most closely meets the current requirements. This complex method is much more expensive, and there is considerable risk involved in completing the integration successfully. Deciding if best of breed is the right solution for your company can be determined in the same way you analyze any other single vendor packages, giving it its own R2ISC rating. Keep in mind that to consider a best of breed solution, your R2ISC ratings should be very high for both Current Requirements and Future Requirements and very low for Implementability, Cost, and Supportability. When you develop the current requirements you should include all requirements that you know you will need, even if you do not need them now but will need them in the future. In order to be able to determine the requirements you will need in the future more accurately, make sure that management has given you their vision and strategy for the future of the company. Application requirements To determine the current requirements for a process you should create a flow chart. This will greatly reduce the number of overlooked requirements. The first step is to define the objective of the process, the next step is decomposing the process into the steps needed to accomplish the end results. By following the grouping for each business area, the required functionality and the associated data can be identified. Prioritizing Once you have identified the current requirements you are ready to prioritize. Requirements are a wish list—some are needed to run the business whereas others are nice to have. Prioritizing the current requirements helps set the target in determining which vendors should be finalists.
• #16: The best package does you no good unless it is used. To reap the system's rewards you must use it! Implementability is made up of the following components: The vendor's background can play a part in the implementability of the package. The items in the vendor's background that you should look at are: Type of Customers— if the vendor has customers similar to you (industry, size, and has similar process) there is a better chance that the package will fit your company. The vendor will know your industry terminology and idiosyncrasies. Number of Years in Business— the longer the company is in business the likelier the company's process will be able to better service you. Size of Organization— if you are a large company with many locations that will be implementing the package then you will need a vendor who can support all those locations. Software and Technology Maturity If the platform and the software are both new, chances are very good there will be problems during implementation. You may find a software package that matches your business requirements perfectly but is difficult to implement. The package may never have been implemented at a company before, or the software has been changed to run on different computers. The software may have only been beta-tested at only a few locations. If this is the case, you will probably find bugs during your implementation, and there may be a poor response time of the vendor fixing the problems, because the vendor may be overwhelmed with problems being reported by other companies. Any of these problems can slow the implementation process and cause users to complain that the software does not work. Modifications The more modification the package requires to meet your company's current requirements, the greater the risk that there will be problems during implementation. Documentation Documentation spends most of its time just taking up shelf space. But when it is needed it can be invaluable. Packages come with different types of documentation (installation, user, system administrator, etc.). Having the manuals is not the only important thing; they must be understandable and well-organized. Training One of the often overlooked but imperative steps for a successful implementation is the training of users and data processing personnel.
• #17: Although many companies feel that the cost of the package is a large part of the total project cost, you must also consider the ongoing costs. One-time costs are those associated with selecting and implementing the package. Ongoing or recurring costs are the annual operating expenses that you incur by running the software. he first step in developing your cost criteria is to allocate 100 points between the one-time cost and ongoing costs. For example, if you are as concerned about the up-front cost (cost of acquiring the package and its installation) as you are about the ongoing costs then allocate the 100 points equally to each of the two cost categories (50 to up-front cost and 50 to ongoing costs). If you are more concerned about the one-time cost, then rate it higher. This can be if you need to conserve cash now but will not have the same financial constraints in the future. O
• #18: Other cost like setting up the system. Depending on the companies level i.e. inventory, PMS
• #19: What the system should do? Users should be involved in developing the detailed business' current requirements. Holding a workshop is the best way to pool the knowledge of users from multiple departments and locations, allowing them to brainstorm together and make a complete requirements list. It is important to include users in the development of the current requirements, because getting the users to "buy-in" to the process and the selected package will make the implementation easier.
• #20: we identified our requirements. Next you will narrow the candidate packages to between two and four finalists. Never have only one finalist because it does not allow for a comparison and limits your ability to ensure that the one package is really the correct choice. It is also not a good idea to have five or more packages; that can become very confusing. The finalists should be the packages that most closely meet your requirements.
• #21: . You will analyze each of the vendors' response to the RFP to determine their R2ISC scores. This process is similar to browsing through the house listings with a realtor. The goal is to weed through the numerous listings and find just the few houses with good potential to visit. The more houses (vendors) you eliminate up front the less work you'll have to do. Just make sure you have two or three houses (vendors) to compare. To determine your key distinguisher, review your must have requirements i.e. intercompany transactions, multi-site. A key distinguisher can also be the operating system. If there are packages that do not meet your key distinguisher, eliminate them immediately.
• #22: Analyzing the Vendors' Responses to the Request for Proposal We narrowed the field of vendors to ten or less. Here, we will narrow the field to between two and four of those that potentially have a package that can meet your requirements We will analyze each of the vendors' response to the RFP to determine their scores . Divide the responses into sections (i.e., current requirements, cost, etc.) and make a person or team responsible for analyzing and rating the same section of all the responses.
• #23: Analyzing the Vendors' Responses to the Request for Proposal We narrowed the field of vendors to ten or less. Here, we will narrow the field to between two and four of those that potentially have a package that can meet your requirements We will analyze each of the vendors' response to the RFP to determine their scores . Divide the responses into sections (i.e., current requirements, cost, etc.) and make a person or team responsible for analyzing and rating the same section of all the responses.
• #24: After you have completed entering the rating onto the Analysis Matrix you can determine which of the vendors will be your finalist. To make the determination we will determine which of the vendors has the best fit. To do this calculate the Weighted Percentage Fit for each package We narrowed the field of vendors to between two and four. In this chapter you will start the process of narrowing the field to one finalist.
• #26: So far in the process the vendors have been comparing the criteria to their packages. But the vendors may not always understand your requirements as they are stated in the RFP, so the information you received from vendors in the RFP may not be completely accurate. The only way to really know if the package actually works as the vendor claims in their response to the RFP is to have them show you how the software meets each of your current requirements. This way you can determine for yourself how closely the package meets each of your current requirements. This is done through the use of a demonstration. The salesperson will try to control the demonstration by showing off what the package does best and glossing over its imperfections. If a question is asked about a feature or function that the software package does not have, the salesperson may say let's leave that for later, but unfortunately later may never come. Scripted Demo In order to change the demonstration from a glorified sales presentation into a real tool for determining whether the package meets your current requirements and also to be able to compare the different packages on an equal basis, you must take control of the demonstration. In a scripted demonstration you give the vendors identical, precise directions (a script) detailing what they are to show you. Vendors are then graded on each requirement as it is demonstrated to you. In order to ensure the vendors do not try to skip over features that they do not have or use the "trust me" line they receive zero points for any feature they do not show regardless of whether or not the package could perform the operation. The scripted demonstration is like walking through a house. Without the script you need to rely on the realtor and the written description of the house. You may have asked for a house that was light and airy and the description of the house said "beautiful house, light and airy." It sounds perfect. But, when you start walking through the house you see what they mean by light and airy. All the windows are broken and there was a big hole in the roof so the light and air are coming in from all sides. Arrange Your current requirements are arranged by functional area. However, in the real world your business does not work as independent areas, it needs to work as one integrated unit. To show how the package meets your current requirements and how the business areas are integrated you need to group your requirements into a complete business flow. The first scenario should be for your most frequent business flow. In other words, it should include the requirements that occur most frequently in the daily operation of your business. The next scenario should be for the business flow that is the second most common. Keep developing scenarios until you have included most of your requirements. You should develop at least three scenarios that go through your entire business flow. Who Should Attend the Demonstration All members of the selection team should participate in the demonstration. You may also want to have additional personnel participate, especially those who have special insight in a specific area of the business.
• #27: T he final step in the selection process is negotiating the contract. This sounds like the simplest step, but it can take as much time as the entire selection process. Many companies think that negotiating the software contract means haggling over the price. Unfortunately these companies later find out that price negotiations don't make up for the cost and aggravation of not changing some of the clauses in the contract` The price of the package is determined in a number of ways including the number of users that have the right to use the software, the number of users that can use the software at the same time (simultaneous users) The vendor will present you with a standard printed contract containing lots of fine print and blank spaces for the price and the name of the modules you will be purchasing. The implication is that the only things negotiable are the price and modules. In reality, every aspect of the contact is negotiable. Clause to watch out for: Non-transferability The license is for a specific ? A catch phrase with vendors today is, "I want to be your partner." Let them prove it. Let them be a partner in the success or failure of the implementation of their package. Payment for the software and implementation assistance can be based on you meeting certain criteria