Fleet Management Software: Build or Buy?

Transcription

1 Fleet Management Software: Build or Buy? So you ve decided to automate your motor pool management. Now what? You ask yourself, should we buy an off-the-shelf fleet and motor pool management system or build our own? Be careful with your answer. It may have implications that ripple throughout your organization for years and years. While there may be a small percentage of organizations with the software development bandwidth, fleet management expertise, money, and time to build a solution, the task should not be undertaken without careful consideration. Top Ten Reasons Fleet Managers Consider Building Their Own Fleet Software No doubt about it, unless you have total authority to make your procurement decision, you are bound to hear most of the following: Top Ten Reasons People Consider Building Their Own Fleet Software: 1. We can do it better than the experts 2. We can do it faster than the experts 3. We don t need all those bells and whistles just something simple 4. We need something different than what s out in the market place 5. We ll build an interim solution and do the real software replacement later 6. We don t know what we want, but we ll know it when we start building it 7. We can build it cheaper than the cost of purchasing a solution 8. We can build it in pieces so we don t have a large capital expense all at once 9. We can maintain it cheaper if we build it ourselves 10. We can manage and control the product better if we build it ourselves Let s examine each of these top ten reasons a little more in depth. Reason 1: We can do it better than experts Confidence is good. But being overly confident about your fleet management and software development prowess may be dangerous and limiting. Consider two completely different aspects of this decision. First, consider what expertise an outside software vendor brings to the table when they develop, sell, and support fleet and motor pool management software. They bring years of experience gained from interacting with fleet managers in your type of environment, as well as other types of environments. They are exposed

2 to the challenges faced by fleet managers managing many different types of fleets. Most vendors are probably members of organizations such as the National Association of Fleet Administrators (NAFA) and they participate in fleet conferences and seminars. Day-in and day-out, fleet software vendors receive input regarding possible enhancements, suggested changes, and required fixes to be added into their solution. A reputable vendor may have dozens or hundreds of fleet managers providing product input that ultimately gets incorporated into their software in regular software updates. So, an off-the-shelf solution is likely to grow over time. Next, consider whether you really can do fleet software development better than the experts. Do you have a development environment? How about a test environment? Do you have all of the tools you really need? Only you know the capabilities of your engineering resources. But engineering resources are only the tip of the iceberg. The task of specifying and managing the thousands of requirements that must be ultimately incorporated into software, tested, released, and maintained takes fleet resources. That can be a tremendous drain that you must be prepared to tackle. 1. Ask prospective vendors how often they release new versions of software. 2. Ask prospective vendors how they receive and prioritize requests for enhancements. 3. Ask for fleet manager references from the prospective vendor so that you can inquire about how progressive the vendor is in the areas of fleet management. 4. When developing a project budget, plan for fleet management oversight for the entire duration of the fleet software project. 5. Analyze the turn-over rate of your IT and fleet staff. The loss of a key player during a software development project may delay or cripple a project. 6. Get a written commitment for response times for software development and test time from your IT staff for the time frame well after your first product is released. Reason 2: We can do it faster ourselves Years ago, implementation of fleet software in even a moderate-sized fleet may have taken weeks or months - on top of a development cycle that would be months or years. The nuances of point-to-point communications, unique security considerations, lack of standards in relational databases, and native development languages in your environment may have all balanced the build versus buy debate. That is, an organization s IT staff may have had an advantage over an outside software vendor with respect to developing a custom fleet solution due to the uniqueness of the organization s IT environment. Today, using web-based technologies, fleet software vendors can offer fully-functional software for evaluation within hours or days and even at no cost! Standardization of web hosting environments, web browsers, and relational databases has paved the way for rapid development and deployment to fleet organizations. Some fleet software vendors can literally have an enterprise fleet application up-and-running within hours and will provide a no-cost, evaluation of the software so that you can prove the viability of the product in your environment. And, consider this - reputable, well-established software vendors will even import your fleet data during your evaluation process so that you are dealing with the software in a realistic environment. So, even skipping the consideration of months or years of anticipated development time, an off-the-shelf solution can most often be implemented in a much quicker time frame relative to a home built solution. 1. Estimate the time frame for each of the following activities when considering implementing time frames for the home-built solution: requirements, system specifications and approvals, software development, defining & refining the hosting environment, testing, and software implementation. 2. Ask prospective vendors how long an average implementation takes 3. Ask for fleet manager references from the prospective vendor so that you can inquire about the actual implementation experiences from the vendor. 4. When developing a project budget, plan for project time frames and also identify which resources are needed during each time frame

3 Reason 3: We just need something simple Be careful what you plan for you just might get it. Take this little exercise if you are contemplating a simple solution. Write down how you hope just one data entry form related to the new capability will behave. For example, consider an on-line vehicle request form. Next, write down the following: What will it look like cosmetically? Will all users of the system see the same information on the form or will it be customized based on user or access privileges? What data fields will exist on the simple form? How will date fields be entered? If pull-down data entry methods are used on that form, will your fleet staff be able to maintain the list of valid data in the pull-down? For example, if a user requests a vehicle type on the form, how will the types of vehicles be managed administratively? What error-checking is required for each field on the form? What validation is to be performed when the form is submitted to the fleet staff? Will an confirmation be sent after the form is submitted? Who will maintain the content of s? How many different types of s are related to this form, e.g. New Request, Modified Request, Approved Request, Cancelled Request, etc. Who gets each type of just the initiator or perhaps the initiator s supervisor, scheduler, or perhaps the manager of funds for that initiator? What happens if the person wants to change the request after it has been submitted? The list of considerations for this one simple vehicle request form could well exceed 100 different topics. It is true that some capability could probably be built in a week or a month. However, that system would be so limited in its capabilities that it would be marginally beneficial relative to a commercial product. FleetCommander s initial on-line vehicle request capability took approximately 1,500 man hours of development time. To date, I would estimate we have expended more than 7,000 man hours implementing critical validation, error-checking, and user interface enhancements to just that one process. I can appreciate that it seems like a simple function, but it really goes a lot deeper than you could ever imagine. 1. Start by documenting a comprehensive list of functions you need. 2. For each function you identify, list every detail you can possibly list for that function. 3. Consider asking a fleet consultant or a prospective fleet vendor if they will scrutinize your list for completeness Reason 4: We need something different Need something different? That should not be a challenge for competent fleet software vendors. Need something really different? That should not be a challenge either. If the candidate software package you are evaluating was developed within the past ten years, the chances are good that it is built using a very flexible software architecture that accommodates a high degree of configuration from fleet to fleet and user to user. A good example is again, a vehicle request form. Your non-technical administrators should be able to customize the fields and prompts on a vehicle request with ease using configuration screens provided in the application. If the system cannot accommodate such a simple change, be wary. If you have something very unique, good software vendors should be able to bolt it on to an off-the-shelf capability using flexible software hooks. That is, the off-the-shelf product will work as-is. Your unique function will just work in conjunction with it. Vendors

4 can handle this in a variety of ways. Ask them about your unique solutions. Chances are, they ll have examples. 1. Make a list of items you feel are unique and may preclude you from using an off-the-shelf solution. 2. Ask your vendor to review your list of unique items and let you know 1) if they can accommodate your function, and 2) how much would they anticipate the change would cost. 3. Ask your prospective vendors to provide references for clients that have had custom solutions developed. When speaking with these references, ask about the extent to which the solution met their needs as well as how well the vendor did with respect to delivering on-time and within budget. Reason 5: We ll build an interim solution So, you only have a little problem that absolutely needs to be solved today. So, you get a little budget and build an interim solution. What are the chances the following conversation would occur the next time a new change is needed? Fleet Manager: We need to replace our motor pool management capability with a new solution. Fiscal Officer: We spent money on a solution last year. Does that get thrown out? Why not just build upon what you already started. An interim solution, by definition, will not be forwardthinking in the approach with respect to database architecture, security architecture, graphical user interface consistency, and more. Interim solutions tend to be just that. Unless a significant effort is spent up front designing the incremental solution, odds are that it may be a hindrance more than a solution. 1. Even if you plan to start with an interim solution, document a longer-term plan. 2. Before starting on an interim solution, get budgets approved for the out-years to accommodate the eventual replacement of a system. 3. Perform an analysis of the cost/benefit of replacing a system now versus later. You may be surprised at the results. Reason 6: We ll know best what we want when we start building it According to a study of failed engineering projects, a leading researcher identified the following as the top 3 reasons a project fails: 1. Poor requirements 2. Lack of, or, poor plans 3. Failure to validate original specification and requirements Whether you ultimately decide to build a solution or buy a solution, planning and documenting your long term strategy should not be under-estimated as a key ingredient for success. If you need help, look to resources such as NAFA. Also, consider evaluating products to find out what works for you. Never start building without a long-range plan. 1. Develop, and get approval (time and money commitments) of a comprehensive list of functions that your application will ultimately have. 2. Identify the resources that will develop and support you application before you start. Reason 7: We can build it cheaper There is a perception that the cost of a product is $0.00 if you have the staff on board to develop it today. When evaluating the true total cost of building a solution, consider the hours that will go into the planning, the specification development, the documentation, the hosting and administration, and the maintenance. You should think in terms of the staff that you have today. But, also consider what the cost would be if you, or another key member of the project, were to leave in the middle of the project. Also, deal with the reality that the resources that you consume

5 full-time may not always be available to fix or modify the system unless a consistent funding stream is available to support that person. Let s assume you develop an initial-capability system that solves an immediate need. What are the true costs you incur for maintenance the day after the first capability is implemented? Will your development and support team be there at 5:00 p.m. if there is a problem? Are they available at night or at 6:00 a.m.? What are the lost costs associated with the time that the support person could be doing other work? Whose time will be consumed organizing requests from users for new capabilities? When there is a server issue or security audit, who will respond to the requests for information? Who will perform testing each time a new change is made? All of these costs add up. When planning your project, identify all costs for the project, including: Requirements definition Specification development Software development Server administration Security administration, audits, and inquiries Test cycles Documentation Training Maintenance and configuration control 1. Identify budgets for each phase of the project. Beyond the initial implementation, projects with no further enhancements typically consume up to 40% of the initial project cost in order to resolve bugs, make minor adjustments, and wrap up loose ends. 2. Ask prospective software vendors for references and contact the references to identify if there are any hidden costs that were not anticipated. Reason 8: We can build it in pieces so we don t have a large expense all at once It is safe to say that the big-bang approach to developing a new fleet and motor pool management package isn t wise. That is, if the new system will have twenty new capabilities, the most prudent approach is not to deploy twenty newly developed capabilities all on Day One. In fact, there is merit in tackling a large project in pieces. However, nearly every piece that is contemplated to be built for the foreseeable future must be thought of, specified, and considered into the end-state design before the first piece of software is written. Given that getting past the detailed specification phase of a project may represent as much as 60% of the project costs, one must carefully consider what the true costs are to roll-out the initial pieces. When the cost versus benefit analysis is considered, the return on investment of a third-party vendor may compare favorably. If your spending profile is a consideration when looking at alternatives for fleet and motor pool management software, do this: 1. Identify your available budget and time frames that funds can be allocated to your fleet projects 2. Layout your budgets, including timing for your internally-developed solution 3. Speak with prospective software vendors about how they can help meet your budget profile 4. Make an informed decision Reason 9: We can maintain it cheaper if we build it ourselves Maintenance costs for internally-developed applications, unless managed very tightly, may rapidly spiral out of control. Do you require staff to be available 24 x 7? To cover this inevitability may have just increased your staffing costs. Can you prevent the end-user community from directly requesting support and maintenance services from the maintenance personnel? Having management oversight ensures that true costs of the maintenance are captured. Are you in an environment such as a university environment that may have frequent turnover of staff that support the application or the server environment? If so, training and re-training may be very costly. There are many intangibles associated with maintaining your own application.

6 Analyze maintenance costs on another similar project and compare those costs to the maintenance costs for an off-the-shelf solution. Reason 10: We can manage and control the product better if we build it ourselves I want it and I want it now! That s a natural conviction to have when you spend money for either a buy-it or build-it solution. The truth is that, once a project is installed in to your environment, you need to identify how much management and control you really have. Consider the phases of a project: The honeymoon phase: Everyone is excited at the beginning of a project. Expectations of what could be are high, engineering teams are in place, budgets are approved ahead of time, and there is a common focus for all involved defining, building or buying, implementing and maintaining a new fleet system. Still want to build it yourself? Building a software product or buying a software product it s a big decision. Fleet managers have new tools in their arsenals. Arm yourself with the knowledge gained from a detailed specification and experience gained from third party product evaluations. It s easier than ever to make the right decision if you plan ahead. For more information about choosing fleet software solutions, call us a , or visit our website at The reality phase: Reality sets in when software components begin to be built or installed, and it is identified that additional user features or support capabilities are required. More resources and additional funding may be required. Schedules may slip. This phase of accepting the reality of building or installing something that isn t living up to everyone s expectations may result in lowered morale. The reaction phase: After initial implementation, project teams are often put into a reactionary mode. That is, staff must react to problems, prioritized list of changes, and changing budgets. Priorities lists may not always start with fleet at the top. Consider each phase of a project when evaluating control. Managing and controlling a project is a timeconsuming task. While fleet managers are well capable of managing day-to-day fleet tasks, the myriad of details that must be juggled when dealing with security, technology, and requirements challenges may be more than you bargained for.