|
Build It, Buy It, or Do Nothing
Wading through the Fleet and Motor Pool Software Options
Perhaps it was a visit to a colleague’s motor pool that did it. Maybe it was an advertisement for fleet and
motor pool management software that you saw in a fleet magazine. Or maybe it was just another unmanageable
Monday in the motor pool. Whatever it
was, you’ve reached a point that you acknowledge that there is no way around it
- you must automate your motor pool management capability. Now what?
Acknowledging that you need to tackle a fleet software
decision is tough. But, just when you get
over that hurdle, your management team asks, “Should we buy an off-the-shelf
fleet and motor pool management system or build our own?” Be careful with your answer. Your answer may have implications that ripple
throughout your organization for years and years. No doubt about it, unless you have total
authority to make your procurement decision, you are bound to hear most of The
Top Ten Reasons People Consider Building Their Own Fleet Software.
- We can
do it better than the experts
- We can
do it faster than the experts
- We
don’t need all those bells and whistles – just something simple
- We
need something different than what’s out in the market place
- We’ll
build an interim solution and do the real software replacement later
- We
don’t know what we want, but we’ll know it when we start building it
- We can
build it cheaper than the cost of purchasing a solution
- We can
build it in pieces so we don’t have a large capital expense all at once
- We can
maintain it cheaper if we build it ourselves
- We can
manage and control the product better if we build it ourselves
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. Consider the following
when contemplating in-house development of a solution.
1.
Perception: We can do it better than the 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
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 also about fixes required and incorporate those into their product. 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 I do?
a. Ask
prospective vendors how often they release new versions of software.
b. Ask
prospective vendors how they receive and prioritize requests for enhancements.
c. 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.
d. When
developing a project budget, plan for fleet management oversight for the entire
duration of the fleet software project.
e. 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.
f.
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.
2.
Perception: We can do it faster than the experts
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 I do?
a. Estimate
the time frame for each of the following activities when considering
implementing time frames for the home-built solution:
i.
Requirements definition
ii.
System specification and approval
iii.
Software development
iv.
Defining and refining the hosting environment
v.
Testing
vi.
Software implementation
b. Ask
prospective vendors how long an average implementation takes
c. Ask
for fleet manager references from the prospective vendor so that you can
inquire about the actual implementation experiences from the vendor.
d. When
developing a project budget, plan for project time frames and also identify
which resources are needed during each time frame.
3.
Perception: We don’t need all those bells and whistles –
just 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 what you hope just one data entry form related to the new capability to
behave like. 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. Ed Smith, the Product Manager for Agile
FleetCommander, states, “Our 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 I do?
b. Start
by documenting a comprehensive list of functions you need.
c. For
each function you identify, list every detail you can possibly list for that
function.
d. Consider
asking a fleet consultant or a prospective fleet vendor if they will scrutinize
your list for completeness.
4.
Perception: We need something different than what’s out
in the market place
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 can not
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 I do?
a. Make
a list of items you feel are unique and may preclude you from using an
off-the-shelf solution.
b. 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.
c. 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.
5.
Perception: We’ll build an interim solution and do the
real software replacement later
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
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 I do?
a. Even
if you plan to start with an interim solution, document a longer-term
plan.
b. Before
starting on an interim solution, get budgets approved for the out-years to
accommodate the eventual replacement of a system.
c. Perform
an analysis of the cost/benefit of replacing a system now versus later. You may be surprised at the results.
6.
Perception: We don’t know what we want, but we’ll know it
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:
- Poor
requirements
- Lack
of, or, poor plans
- 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 I do?
a. Develop,
and get approval (time and money commitments) of a comprehensive list of
functions that your application will ultimately have.
b. Identify
the resources that will develop and support you application before you start.
7.
Perception: We can build it cheaper than the cost of
purchasing a solution
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 of that 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 I do?
a. When
planning your project, identify all costs for the project, including:
i.
Requirements definition
ii.
Specification development
iii.
Software Development
iv.
Server administration
v.
Security administration, audits, and inquiries
vi.
Test cycles
vii.
Documentation
viii.
Training
ix.
Maintenance and Configuration Control
b. 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.
c. Ask
prospective software vendors for references and contact the references to
identify if there are any hidden costs that were not anticipated.
8.
Perception: We can build it in pieces so we don’t have a
large capital 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 out on day-one.
In fact, there is merit in tackling a large project in pieces. However, nearly every piece that is
contemplated to be build 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 the
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 I do?
a. If
your spending profile is a consideration when looking at alternatives for fleet
and motor pool management software, do this:
i.
Identify your available budget and time frames that
funds can be allocated to your fleet projects
ii.
Layout your budgets, including timing for your
internally developed solution
iii.
Speak with prospective software vendors about how they
can help meet your budget profile
iv.
Make an informed decision
9.
Perception: 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 I do?
a. Analyze
maintenance costs on another similar project and compare those costs to the
maintenance costs for an off-the-shelf solution.
10. Perception:
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 in to 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.
Summary
Building a software product or buying a software product –
it’s a big decision. Fleet managers have
new tools in their arsenals. Free,
fully-capable trial software is now offered by many vendors. 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!
|
Home