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
Fleet Management Software:
Build or Buy?
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.
What can you do?
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.
What can you do?
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, andsoftware 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
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 email confirmation be sent after the form is submitted? Who will maintain the content of emails? How many different types of emails are related to this form, e.g. New Request, Modified Request, Approved Request, Cancelled Request, etc. Who gets each type of email – 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.
What can you do?
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 somethingdifferent? 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
can handle this in a variety of ways. Ask them about your unique solutions. Chances are, they’ll have examples.
What can you do?
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 alittle 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 forward-thinking 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.
What can you do?
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.
What can you do?
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
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.
What can you do?
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 largeproject 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.
What can you do?
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 turn-over 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.
What can you do?
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.
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 time-consuming 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.
Still want to build it yourself?
Building asoftware 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 408-213-9555, or visit our website at