FREQUENTLY ASKED QUESTIONS

Software Selection

Why can't we just purchase the biggest name-brand software package, and be done with it?  You can – it’s the laziest and least risky approach in terms of organizational backlash (at least in the beginning).  The problem with this approach is you have no way of knowing whether it is going to actually solve your problems – that it meets your business, growth, and strategic requirements.

There might be some mid-tier solution that is a spot-on match with what you need.  Or, an up-and-comer who doesn’t have much market share, but is hungry and willing to do some tailoring to give you exactly what you want (which is a tactic a number of smaller software companies have used to become bigger software companies at which point they stop tailoring…).  If you choose to just select the best-known solution, you run the risk of spending a gob of money on a package, implementing it, and being no better off than you were in the beginning.  It happens…

Can you define our requirements for us?  Sorry, no.  But, outsiders can be an invaluable resource in eliciting responses and actually outlining the requirements for consistency.  The actual need, the business requirement, must come from inside the organization.  Your organization is presumably contemplating changing to a new software platform for a reason - perhaps the existing platform is no longer fulfilling your needs or allowing your organization to compete in the market place.  The substantive requirements must come from within your organization.

Consider using outsiders to interview key personnel and draft an initial version of the requirements.  The approval and the priority of the requirements should come from your side.

How many people should be on the software evaluation team?  I prefer 5-7 people.  That usually covers all the functional areas of most organizations, and allows for meetings where everybody can be heard without being too long.  As meeting participants grow, so does the length of time to conduct the meeting (particularly if they are poorly run).

Who should be the project team leader?  The answer to this is usually obvious.  There always seems to be somebody who has the right temperament and experience to navigate the myriad of issues and personalities.  Some key characteristics of a good project manager are:

Calm
Organized
Handles difficult people and situations well
Slightly reluctant to have the role
Runs a tight meeting
Is both tough and tender hearted
Respected by the majority of the people to get the job done

What part does the software price play in the overall evaluation?  There are two schools of thought regarding evaluation of price.  One approach is to take it into account as part of the product.  Price gets a ‘weight’ in the overall evaluation.   For example, price could get a 40% weighting and the overall functionality of the software could get a 60% weighting.  In other words, price is evaluated at the same time as the product.

The other method is to evaluate price after everything else has been done.  The team has done all of its work, and then the project manager passes out the pricing matrix.  This may simply decide it.  Members who were on the fence are swayed considerably when all of the costs related to acquiring, customizing, and implementing the software are summarized.  I personally prefer this method because it is less mathematical, more intuitive, gives more room to ask questions, and more room to interpret.  It’s more human and gives rise to terrific discussions and team interplay.

Additionally, price carries a huge bias.  Getting the price information in advance can needlessly close an evaluator’s mind with regard to functionality…particularly when you aren’t contemplating the fact that price is one of the few things that is negotiable in this whole process.  There is little upside to giving out the price information in advance.

Along these same lines, one of the big questions when you get to this point is whether it is the final price or the beginning of the final price.   Be extremely wary of large price discrepancies and discounts.  If one vendor is coming in significantly under what the other vendors quoted, be suspicious.  This may be an immature company who is looking to get market share (a foot in the door) at any cost.  When you choose a vendor, you then become motivated for them to stay in business.  You don’t want a company that is going to give steep discounts to win software engagements unless there is a good reason for it.

Is there a ‘Best Practices’ with regard to software evaluation?  No.  That is a large consulting firm’s way of scaring you into thinking that you are doing something stupid or doing something that is not in your best interests.   When it comes down to it, all of us are essentially doing the same thing, which is some version of the following:

Organization and Infrastructure
Project Planning
Requirements Definition
Preliminary Vendor Pool
RFP Creation
Evaluation Preparation
Creation of Scoring Templates
Product Evaluation
Vendor Evaluation
Final Selection

When making the final ‘vote’ on which software to acquire, should the vote be unanimous or will a consensus do?  I’ve had both happen through the years.  Obviously, unanimous is best – everybody is on board and there are no issues or politics to deal with as you go through the accompanying software implementation.  But sometimes, you have split decisions, and that is okay as well.  What you must do is determine the voting methodology well in advance of the final evaluation and selection meeting.  Really talk through it as an organization.   If you have done your job right, then everybody will have had ample time to give input, your evaluation criteria will be intact, and a natural solution will flow.  The problems occur when the project infrastructure has not been heard.

What does ‘Best of Breed’ mean?  ‘Best of Breed’ means using a specific (the ‘best’) software program package for each particular application or requirement.  To share information between the applications, the information is either printed out from one package and manually input to the next, or the packages are linked either by the vendor or by using a third party “middleware” package to provide varying degrees of integration.  These middleware systems generally require a considerable amount of IT time to set up and maintain.

There is quite a bit of literature written about the benefits of a fully integrated system versus those of buying a best of breed solution.  Two benefits of a best of breed solution are the fact that you are buying a narrow best-fit solution (thus the term ‘best of breed’), and these off-the-shelf products may be easier to use.

What is the downside of a best of breed approach?  There are several:  1) you will be dealing with multiple vendors and multiple implementations.  2) You will have to build interfaces between the various software products.  These ‘bridges’ could possibly affect the integrity of your organization’s data.  3) It is more difficult to measure the total software costs with a best of breed solution.  There are just more moving parts to calculate.

The project team needs to talk about these concepts regarding the possible use of a best of breed solution.  There is no right or wrong here:  what works for you may not work for a similar organization.  But, don’t make the mistake of not talking about the options, and don’t assume everybody on your team has contemplated this.  Have the conversation.

What is the difference between a software demonstration and a software examination?  I have already touched on scripted demonstrations.  The notion of an examination is taking things to the next step.  A software demonstration is where the software vendor sales representative is controlling the process:  setting the agenda, showing you the ‘cool’ features in the software, and, in essence, doing everything in their power to get you to buy.

Be aware that many software sales professionals are very, very good at what they do.  Many times it’s an uneven playing field, as you can quite literally be seduced by the ‘wow’ factor inherent in many software demonstrations.  Almost always, the ‘wow’ has very little to do with solving problems in your organization.

A software examination occurs when you have taken control of the vendor visit.  You have set the agenda, created a scoring methodology, prioritized your requirements, trained your software evaluation team on how they should act, determined your ‘X’ factors, and created a ‘show me’ script for the vendors to follow.  You should also determine which scripts you are going to provide to the salespeople in advance, and which ones you aren’t.  Know that the vendors hate this, because it takes a large portion of the salesmanship out of their hands.  You must be in control of what you want to see.   Do not defer to the software team that is trying to sell you their wares.

What are some good questions to ask software vendors?

Q.  What is your company’s vision statement?

This is different than a mission statement.  You want to know where the company is going from a technological standpoint:  What is their vision?  What is the direction of their product?  Are they a trendsetter?  Do they even have a vision statement?  Who sets the vision?  Good stuff, and very hard to answer.  I have met vendors who could state this vision effortlessly, while others were completely stymied.

Q.  What is your unique selling proposition?

A unique selling proposition is the essence of what distinguishes and differentiates you from your competition.  In essence it should answer:  Why should we buy our product or service?  Ask this question!

Q.  What is your current number of employees and how many are dedicated to our business line vertical?

We want to get a feel for the size of the organization, but more importantly we want to know how many employees are allocated directly to your line of business.   For example, a vendor may tout their base of 900 employees, but their allocation for your particular business line may only be 15.  The 15 number is much more relevant than the 900.

Q.  What software products are you not in, but plan on introducing?

Essentially, you are asking them to tell you what is on the horizon.  This may or may not be relevant, but it’s worth asking.

Q.  What about vice versa – products you currently have in the market but will no longer support or plan on discontinuing?

This may be hugely relevant, particularly if this existing functionality is referenced when they answer the functional portion of the Request for Proposal (RFP).

Q.  Who are your major competitors?

The answers here are always interesting.  The better firms will always know and will be able to discuss this confidently.  Do not ask why the vendor loses deals to the competition.  This will open up a can of worms and the answers are not relevant to your decision.  Interesting?   Sure.  Relevant?  Probably not.

Q.  What is your market share?

This is always an interesting answer, and usually skewed to the vendor’s benefit.  The follow up questions should be where they get their information and how they calculate market share.  A vendor having the most market share is not necessarily the best thing for your organization.  It does mean there are others who have taken this leap before you,  and you will discover the satisfaction level of these customers during the reference checks.

Q.  Describe your percentage of revenue in terms of new sales versus annual recurring revenue?

I really like this question.  What you are looking for is an organization that has some sort of stable annuity coming in through hosting services, license fees, or maintenance revenues.  You want your vendor to stay in your business.  You want them to be successful, and you want to have a stable revenue foundation.  A good recurring sales to new sales ratio should be around 70:30.

Q.  Please list all current lawsuits that your company is involved in.

Do not ask about just major lawsuits, as this gives them control of the question.I  t is possible that the vendor may not want to give you this information.  Stand firm.  This is most relevant to your significant investment of funds.  You’ve signed a non-disclosure agreement that contractually binds your organization to non-disclosure.  You should take that non-disclosure agreement very seriously.  If you are supplied the litigation information you have an ethical and legal responsibility to keep it to yourself.  This is not water cooler talk.

Q.  Do you have plans for any major changes within your organization?

Essentially you are asking the vendor whether they are 1)  downsizing, 2)  acquiring any other companies, or 3)  in negotiations to be acquired.  All are relevant to your evaluation process.

Q.  How many salespeople do you have?

It is healthy to have a good number of sales personnel at a software company.  It is an indicator of overall organizational health.  While the logic is circular, it goes something like this:  Companies with a good sales team will make more sales, which brings in more revenue, which allows the software vendor to improve their product, which allows the sales team to make more sales, which allows them to grow so they can then hire more salespeople so they can make more sales…

Software Evaluation Projects

Who are the best software vendors?  There is no ‘best’ software vendor.  You need to be thinking in terms of ‘best fit’ software vendors.  You want the vendor whose functionality best fits your detailed business and technical requirements at a price that is within your capital investment budget.

What type of scoring mechanism do you use during the software evaluation process?  Over the years we have developed some moderately complex scoring mechanisms.  They are difficult to describe in a question and answer format.  I think the question is the wrong one.  I think the question should be more along the lines of how much of the final decision is based on ‘hard’ scoring and how much is based on impressions and intuition?

So, here is my answer to that question:  Approximately 50/50…and that answer lends itself to the notion of the art of software selection versus the science.  Generally speaking, the “art” relates to working and dealing with people—and with using your intuition and experience to navigate issues.  It’s a process of discernment and trust in your instincts.  “Science” relates more to the mathematical compilation of a functional score for a particular vendor.  It also relates to the creation of an empirical evaluation mechanism.  Software selection involves both of art and science.  You have need both.  Despite what some say, you just can’t come up with a “score” for a vendor and say that the highest scoring software vendor wins.  Similarly, you can’t just go on vibe either. You need both art and science, and you need to know that and accept it going in.

How is choosing software different than purchasing other products and services for my organization?  Software is unique in that it is one of the few major capital expenditures (and maybe the only one) that is critical to your business, BUT is always changing, improving, and therefore making the initial product obsolete at some point.  A change by your competitors to a newer solution, one that has some new functionality that gives them a competitive advantage, might be enough to make your organization lose market share, and force you to make a change yourself.

The smart move is to stay abreast of the software market, and to be thinking at least 18 months out.  To be proactive, not reactive.

What is the hardest, most time consuming aspect of the software selection process?  The hardest part for you is going to be defining your business and technical requirements.  In order to get a requirements-to-functionality match, the requirements definition process is critical…and difficult.  Some companies hire it out to consultants, but the consultants still have to interview key personnel, and you will still have to review their work.  The second most difficult thing to do is to decide to pull the trigger and decide that the sheer cost of the acquisition will necessitate your company to go through the process in a mature and methodical manner.

When hiring a consulting firm to help and provide value during the software evaluation process, what should we be looking for?  I would focus on a couple of key areas:  One, have they done this before and do they have testimonials and references.  Two, do they have a proven methodology and can they explain it to you.  Three, ask if they are willing to only work on the software evaluation, and not on the accompanying implementation.  Four, ask them how many people they are going to put on the engagement – for most software evaluations, one person should suffice.

I am concerned that if I hire a consulting firm, a team of consultants are going to descend upon our workplace.  Can’t this be a one-person consulting job?  You are right to be concerned about this.  In my business, we call this ‘piling on’.  See my answer to the previous question.

What is the best way to conduct software product demonstrations?  Hmm…not sure about the ‘conduct’ part.  But I can tell you the best way to ‘control’ them.

A scripted demonstration is where you tell the software vendors exactly what it is you want to see in their software.  And you lay it out for them in advance…in a script.  If you do not do this, you increase the probabilities significantly that you may not select the vendor that best fits your requirements and needs.

What are the benefits to using this technique?  There are a number of them, and the implications are huge.

You maintain control of the demonstration.  By determining what you do and don’t want to see—and by communicating this upfront—you keep the agenda tight and focused on your needs.  These scripts should flow as if people were doing their normal jobs, except that the software vendor salesperson is showing you how you will be doing it if their product is selected.

It takes some salesmanship out of the equation.  By taking most of the demonstration down to “boring” functional items (which tie back to your business objectives), it takes away from some of the discussion of the newest features that may or may not be relevant to your business.

It will tell you whether the software vendor salespersons are winging it or really want your business.  Are they willing to work for your business by taking the time to create a terrific scripted demonstration?  Are they listening to you?  Will they listen to you in the future?  It has been my experience that they are not interested in doing a scripted demonstration.  It is much easier to do a regular sales demonstration, but it is possible that you have already seen this.  You should be interested in the meat and potatoes.  Hold the flaming dessert for later in the process, thank you very much.

It will clarify whether your business objectives will be handled by the software.

It makes the software vendor salesperson “show you.”  It provides a forum where all statements by the salesperson can be followed by “show me.”  It is impossible for the salesperson to hide in this environment.  If he is representing an inferior product, it will come out in this process.

Is it absolutely necessary to send out a Request for Proposal (RFP)?  In general, you should create an RFP when any of these conditions exist:

1. The price of the software can be negotiated
   
2. There are multiple vendors that can provide essentially the same solutions to your business and system problems
   
3. There are multiple solutions available for your business and system needs
   
4. The lowest price does not necessarily win

Think of the RFP as the intermediary between you and the software vendor.  It is the document that allows for consistency of answers among software vendors and allows each party to work from the same group of rules and understandings.  It is an ongoing interpreter between the project team and the software vendor, and will continue to be used in this regard through the final implementation.  The document sets the framework for everything that happens going forward.

What is a vendor long list and how do I obtain one?  You can’t obtain one…you have to create it.  A vendor long list is the list of vendors who survived the initial round of “tire kicking” that occurs at the beginning when your organization begins talking about needing a new software solution.

At this point, the two efforts—requirements definitions and vendor pool identification—should come together.  Significant work has occurred on both work areas.  It is highly probable that key functional requirements have developed by the folks working on those deliverables and could be included in any work documents that will be created to further eliminate vendors.

Determining which vendors will be on the long list is more of a process of exclusion rather than inclusion.  We are looking to exclude “no chance” vendors based on a high-level review of cost, functionality, technological direction, and vendor maturity.  The number of available vendors in the initial pool will drive some of this as well.  The process of going from the preliminary vendor list to the long list will be a different one if you start with one hundred vendors than if you start with fifteen vendors.  You will be much more motivated to begin striking vendors when the initial search brought in a hundred vendors.

Do vendor reference checks really work?  Mostly, no.  Many companies are unwilling to give direct, unbiased recommendations…and are also unwilling to say what their role may have been if things didn’t go as well as planned.  Also you should be aware that the software vendors are only going to give you their Cadillac implementations as references.  A better tactic is to find references that are not on the vendor-provided list.

I was recently advised to go visit the offices of my software vendor of choice.  It seems like a waste of time – what do you think?  I agree with you.  Not the greatest use of time or money.  I think you can be swayed both positively and negatively by the reactions you get from visiting their offices.  (Do you really care if the lead software developer has a clean desk or a messy one?).  I see this more as a box checking exercise.

Software Implementation Projects

How much transactional history should be converted?  There are different schools of thoughts on this…but here’s mine:  Only convert as much history as you need, not as much as you want.  This advice is contingent on your company having access to your prior system.  From a financial accounting perspective, I would bring over the current year summarized or individual transactions.  If you do prior year comparative reporting, then you will want to bring over the prior year transactions.  Beyond that you have diminishing returns.  Why?  Because the human cost of having to balance these transactions outweighs the benefits received.

Make a point to review your initial knee-jerk reaction of how much transactional history you need to bring over.  Upon reflection, the amount that you think you need is usually less than what you actually need.  Think cost-benefit.

Should these implementations have an in-house, internal project manager or an external, for-hire project manager?  Or both?  The answer to this is usually obvious.  There always seems to be somebody who has the right temperament and experience to navigate the myriad of issues and personalities.  Some key characteristics of a good project manager are:

• Calm
• Organized
• Handles difficult people and situations well
• Slightly reluctant at having the role
• Runs a tight meeting
• Is both tough and tender hearted
• Has the respect of the majority of the people to get the job done

This should not necessarily be assigned by job function.  The IT manager may not be the best person to serve as the foreman of this effort.  Base the decision on the characteristics I listed above.  An IT manager or controller who runs a lousy meeting and is obnoxious will make this effort more difficult than it needs to be.  Instead, for example, use the senior, savvy operations manager who may have no software experience whatsoever.

Consider hiring a consultant to be your project manager when:

• There are no obvious candidates within your organization
• Your organization is “tight” on resources and you don’t want to overload staff personnel
• You want an independent third party to be your project leader

I have been on a number of satisfying engagements where this role was shared.  But even in this scenario, you only want just one leader.

What should the software company’s role be during the implementation?  They should be in charge of the product at a minimum – insuring that it operates as advertised during the evaluation phase.  Some software companies have service divisions that help during the implementation.  This help can come in the form of data conversion services and/or training.  For larger and more complex implantation efforts, I would be wary of employing them to run your project.  You will want an independent or in-house person to be in charge of your project.  At the end of the day, the employee of the software company will be representing his company…not yours.

Are canned implementation work plans available for purchase?  Yes, they are – but not from us.  The reason these canned plans are not a good idea for you is that EVERYBODY’S implementation is different.  Do not accept a software vendor’s canned work plan.  If you do this, you will be fitting into their way of implementing rather than insisting that they custom their approach to you.  Canned work plans are good idea as a starting point for creating your own custom plan.

Do you recommend a manual/data entry process for data conversion or an electronic approach?  It is a function of the number of records to be converted.  If it is a ‘small’ number, then a manual approach is a consideration.  The ultimate answer will depend on the time cost of creating the electronic conversion protocol versus the benefit received (time not spend doing it manually).  Having said this, our preference is electronic.  With the tools available today, this is usually the right call.

Our company is concerned with our operations grinding to a halt while this software migration effort is going on.  What do you suggest?  Good for you – you should be concerned.  A way to think about this is to equate the software implementation to a highway construction project.  You have to keep the traffic moving while you build the new highway.  Orchestration is a key concept to remember.  You want to orchestrate the go-live procedures and process as many times as you need to prior to the actual ‘switch-over’ date.  This methodology will reduce risk and anxiety, and will additionally reduce the amount of down time as you migrate to your new system.  Bottom line – there are proven tactics and techniques for these software implementations.  Your operations should not grind to a halt.

Have you ever participated in a software implementation that failed?  No, but I have had them be more difficult than they needed to be.  

Is there an ideal time during a software implementation to convert data?  It depends on the data.  The conversion of GL (General Ledger) history, for example, will usually start at the beginning of the implementation.  This is because, generally, there is between 12 and 24 months of history that needs to be converted, and it can take a while to validate all of this data – particularly if the chart of accounts has changed between the two systems.  Year-to-date vendor payments are typically converted after go-live, but before January 31 of the next year – the due date for 1099s.  Variable operational data (e.g. tenant balances) will be done during the “go dark” period while end users are being trained.   Static data – data that doesn’t change (e.g. units) – can be completed any time during the implementation process.  However, because time gets tighter the closer you get to go-live; you will want to get this done sooner, rather than later.

If this is a mid-year conversion, is it better to bring over year-to-date vendor payments for purposes of producing 1099s out of the new system, or to produce two 1099s -- one from the new software product and one from the old software product?  We’ve seen this both ways.  It’s easier to do two 1099s, because there aren’t any conversion ramifications.  (You just print a 1099 from each system.)   This is fine with the IRS.  Remember that 1099s are not part of the company’s mission - it is a reporting requirement by the IRS with a $50 fine per vendor if you don’t do it.  If you decide to produce the 1099s for the entire year out of the newer system, then the best use-of-time strategy is to wait until after the implementation is done to import and validate the data.  It’s not necessary to have imported Year-to-Date vendor payments as part of a core go-live strategy.

How many iterations of data conversion orchestration should occur?  You need to orchestrate the conversion of the data until it is right.  That could be 1 time or 20.  In my experience, it usually takes 4-5 times to get everything down correctly.  Time is of the essence when you are going live, and you have to know that the routine is going to work.  You don’t want to be messing around with import scripts when the organization is down for two or three days without a system.  Think of the data orchestration process as a dress rehearsal - you just might have several of them before you are ready for a live performance.

Is there any benefit to converting some of the tenant information early in the process, and then bringing in the remainder of the tenant data later in the process?  It’s an approach that has some merit.  What it allows you to do is to enter or import a minimum amount of information required in order to save a tenant record in your new system.  Once a tenant record is saved, the system assigns a tenant ID.  When tenant IDs are established, you can go work on other areas of the data conversion that relate to a tenant.  It just depends on the implementation plan, and what you are trying to accomplish.  For example, if a primary goal of the implementation is the have the work-order history entered early in the process, then you need to have a tenant record established.  Later on you can bring in the less important information.  It’s a time-saving strategy.  Establishing tenant records early (even if you don’t have all of the desired tenant information) can free you up to work on other areas of the implementation.  The down side to this approach is that you are now doing two imports.

What is the difference between static and variable data, and how does that affect your go-live strategy?   Static data is data that, for the most part, doesn’t change.  An example would be units in residential real estate.  The tenants change, but generally speaking, the units do not.  Static data can be converted at anytime during the implementation process - the earlier the better, since time is at a premium as you near the go-dark time frame.

Variable data is data that is unknown until you go dark (‘dark’ being that brief time period where you don’t have a system), and your final data conversion is occurring.  An example of variable data would be a tenant’s outstanding balance.  This data cannot be converted until you close down the old system.

The variable data conversion should be orchestrated and tested for a couple of cutoff periods prior to the go-dark/live process.  You want to build a conversion protocol that gets executed during the 1-2 days of the final variable data conversion.  The orchestration process allows you to build a conversion routine that is tested for all conceivable scenarios prior to the go-live data conversion.  It is not unusual at all to encounter problems during the orchestration process.  In fact, that’s why you do it…to find and correct data extraction problems in a safe environment where you have the time to think through all of the data issues.

Should the data in the old system be archived?  Yes, it should – particularly the data that is not converted to your new system.  Sometimes, you will have access to the legacy system forever.  If this is the case, then just let the data stay there, and access it as you need it.  As time goes on, you will have fewer reasons to go back to the old system.  If that is not the case (and, especially if you are paying license fees on the old system), then you either need to print reports in hardcopy or save the files to use in an electronic library folder system – this way you can easily go back and find the information.

Is it better to convert summarized GL transactions, each individual transaction, or can just trial balance information be imported?  There is no better or worse.  The ease at which the data is pulled from the source system should dictate your choice.   For some source systems, it may be easier to pull individual transactions.  For others, the best solution would be to bring in a trial balance.  It really depends on the capabilities of the source system, its reporting capabilities, and how that data is stored in the source system.  Know that pulling individual transactions will result in a slower import process because of the sheer number of transactions that will be brought in.  A summarized journal by month by property and by GL account will always go faster from an import standpoint (but the summarized entry might be more difficult to create or ‘pull’ from the source system…)

What is the typical number of consultants you employ on an implementation engagement?  It’s usually one consultant, sometimes two on larger engagements or where certain subject matter specialties are required.  The reason we can keep it so low is - if you’re good at project management and with the subject matter itself, you can fill a number of roles.  All the consultants at Lupine are adept and trained in both classic project management techniques and on most, if not all, of the modules within certain real estate packages.

What are your guarantees on a software implementation project?  There are several things that we do guarantee:

• That you will be led.
• That we will work hand-in-hand with the software organization to be one cohesive unit.
• That we will have the required product knowledge.
• That we have a proven methodology for implementing software.

What is your philosophy regarding the timing of end user training?  We have established a methodology where, in the two days between shutting down your existing systems and going live on the new software, your user base gets trained.   Simultaneous with the training of end users is the final conversion of data.  This way, when the users get back to their desk after the training, they are live on the new system.  All of your properties, units, tenants and recurring charges, along with tenants’ balance at the time of the conversion, have been loaded onto the new system and your staff can begin working in a live environment.  This reduces the amount of time when knowledge gained during the training can be forgotten.

What is the purpose of the discovery meeting?  The discovery process has two main goals.   The first is to get organizational agreement on the project scope.  It is rare that the entire company is in sync with what is going to be implemented, and what the conversion process is going to be.  From Lupine’s perspective, we can’t manage a moving target.  Therefore, a lot of questions around scope get asked.  The second outcome from the discovery process is to create custom implementation materials for our client that are presented during the implementation kickoff meeting.

The goal of the discovery process is not to begin making decisions regarding how the chart of accounts is going to be set up, what the unit type numbering methodology will be, or what the financial statements should look like, etc.  All of that will be handled in the module design and configuration meetings.

How do you communicate project status?  Every week we send out a status report.  For consistency purposes, we send it out on the same day of the week and about the same time.  It is sent to the project team, other relevant people in your organization, and relevant people at the software company.  The simple, but effective, format looks like this:

• a paragraph that gives a summary overview of the project
• a listing of tasks that were completed during the week
• a listing of tasks assigned but not completed
• a listing of key decisions made during the week
• a listing of tasks assigned for next week

What is the biggest reason why a software project fails or is more difficult than it needs to be?  If forced to pick one that rears its ugly head more than others, I would say the third item on the list below – poor resource allocation/lack of an understanding that people have full-time jobs…In the beginning, it’s easy to believe that everything can get done and the deadline will be met.  However, if you don’t take into account that, prior to the implementation, everybody was already working 40-50 hours, burn out is a very real possibility.  When we write the project work plans, we do take this into account, and budget the tasks about 3 to 4 times longer than it would take if nobody had full time job…

Other non-successful behaviors or reasons we have observed are:

• They take too long.
• Lack of executive or managerial buy – in.
• Poor resource allocation – lack of an understanding that people have full-time jobs….
• Lack of a plan.
• Impatience – who wins the tortoise or the hare?  You actually can finish faster by going slower.
• Cancellation of status meetings.
• A perception that the ‘sky is falling’.  If this happens, it is usually at the beginning of the project.  Or said another way – a lack of belief in the project plan.
• Lack of delegation by team members – ‘broad shoulders’ syndrome.
• No organized method for identifying and resolving issues.  Or said another way – a lack of project discipline.
• Project scope creep – or even worse, no scope at all.
• Lack of project leadership.
• People not doing what they say they are going to do.
• Decision remorse – changing your mind after a decision is made and documented.
• No defined project end date (no goal).

Have you ever had a project fail where you and/or the client had to walk away from the implementation?  We’ve had this happen twice in our 18 year history.  And in both instances, it had its foundation in the conversion of the general ledger history.   In both instances the projects moved faster than our clients’ ability to extract, import, and validate this history.  They were trying to convert too much history, and at the various go-live dates, they were always still several years behind, and would not take the remedial steps necessary to bring in the resources to get this history loaded.  If you are bringing over general ledger history you need to make sure that the time/money cost of the conversion is worth the benefit of having the history in the new system.

What, in your opinion, is the most important part of the implementation?  Discovery, kick-off, module design and configuration meetings, weekly status meetings, training, and orchestration of the go-live process – they really are equally important, and they tend to build off of each other.  However, if forced to pick one, I would say discovery - the process of getting of everybody on the same page.   This serves as the foundation for communicating an implementation approach.  It’s key.  If that is done badly, it will resonate throughout the entire implementation process.

What is the cost of NOT being trained properly for your software implementation?  You run the risk of the entire implementation effort being all for naught if the users cannot use the system in the manner it was intended.  Any custom reports that have been created, the entire data conversion effort, and the setup of the individual modules will be a throw away if the users cannot use the system.   You run the risk of the entire implementation being deemed a failure - I’ve seen this happen.  Generally you have about a 45 day window for the user base to say either 1)  they love the software or 2)  they it hate because once they’ve made that emotional decision it is tough to get their minds to change.  Bottom line here is:  don’t go cheap on the training.  It is the last piece to the entire implementation effort, but if it is done poorly then everything that preceded it could possibly be time wasted.

How close to go-live should your end user training be?  Ideally right at the ‘Go Dark’ time period.   Go Dark is when you are taking down the old system and right before you go live with the new one – it is the time period when you are system-less.   There is typically a two to three day period when your data is being converted from the old system to the new.  During that ‘dark’ time period that is the ideal time to train your users.  When the training is over, the data from the old system has been converted and everything is ready to go.   The users can then begin going through the list of items and tasks that need to be covered while they were off at training.  (Because for that 2-3 days there will have been no system and any transaction that occurred during those 2-3 days will need to go into the new system…)  So the final answer is user training should be as close as possible to the go-live timeframe.  If it is more than two week before go-live then they’re probably going to forget what they learned in training and you run the risk of having to retrain.

Should training be held concurrently with the final data conversion effort?  In my opinion -- yes.   And this is something Lupine been able to accomplish a large number of times over the years.  There are two goals:  One, to maximize resource usage – the people doing the data conversion are not the same as the ones who are leading the training effort, so you can have simultaneous efforts.   Two, to reduce the amount of time that end users forget what they were trained in.  Ideally the system users go to training, get out of training, and then go live with the new software package.  If they go right into using the system (and not go back to the original, old system) then everything they learned is fresh.

What is the recommended training class size?  I would say between one and ten.  Once you get over ten then even the most disciplined groups will break down and begin having side conversations.  Once they begin having side conversations then obviously they are not listening to the trainer.  The trainer is now training two to three different groups, all of which are having various conversations.  So the smaller the class, the higher the focus of the attendees.  If you want to train more than ten people, then I recommend that you break it into two or more sessions.  Even though it is more expensive, I would always go towards having the smaller groups…more learning will occur.  If you go through the process and the system users do not learn the software then you run the risk of a failed implementation…

Do you recommend that each trainee have their own computer for the training session?  Definitely.   With software it doesn’t translate to just watch what is being done.  And sharing doesn’t really work either because the ‘buddies’ will talk among each other.  One person in the pair will become the teacher and the other student, while both need to be students.  It is just not a good dynamic to pair up and ‘watch’ a software training session.  You must have hands on keyboards…

What do you think about using quick guides or student aids?  I think it is a terrific idea.   Even though user guides are provided by the software companies the fact of the matter is most people won’t use them   It’s not because they’re not well written - they’re thick and daunting and most people just want a quick guide to show them how to do what it is they are going to be doing day after day after day.  People will use index cards or one page documents that show them how to do repetitive tasks.  This should be part of your training implementation program to have these guides and or aids created.  They can either to be passed out during the training session, or after each training module, or at the end of the entire training process.  When they go back to their desk after going through the software training they will have these guides available to them to use during the first few weeks.  After that, most of the repetitive tasks have been memorized and the materials will no longer be needed.  (But they can be used by new employees – don’t throw them away!)

Should you use your own data during training or utilize a training/sample database?  Ideally you should use your own, but practically speaking this is difficult to do and it’s usually not cost effective.  The reason why it is typically not cost effective is because your database has to be setup to be meaningful in a training environment.  So, the setup would include being able to demonstrate various functionality in the software.  Sample or training data usually has already been setup to demonstrate the software functionality whereas your data will not typically been setup this way.  ‘Your’ data is usually the remnants of the data conversion orchestration effort.

The question is this:  What is the cost/benefit to setting up your database for training just so the users will recognize the properties, units, and tenants?  Yes, they are more familiar with the data, but does it actually help them learn the software faster or better?  My thought is no…. you can spend your finite time and resources in other areas on the implementation.  Just use a training or sample database.

What is the problem with putting beginner and advanced users together in a training session?  All of us have been on one side of this over the years where you’re the smart person and there are newbies in the class and you are bored   Or you’re the inexperienced one and everything is going over your head.  And it’s the same with software - if you make the mistake of combining groups with varying levels of experience or interest, then you run the risk of one side being bored with the other side being overwhelmed.  This is a question and analysis you need to do in advance because your goal is to get everybody trained.  You may think you are saving money by putting everyone in the same class, but only half the class is really being trained.  You have not furthered your goals of getting everyone trained on the new products.  You didn’t really save any money if one group did not get what they need.

Can the training be done remotely or should the trainer be ‘in the room’?  Final end user training must be done in person.  You have to be able see student’s reactions and you must be able to monitor the room to see what’s going on.  They must be able to see your face as you’re teaching the product.  Even with new technology there are some things that still must be done face to face to communicate person to person.  Remote training can be used to work through particular software or user issues, but it’s not a full end user training.   Don’t try and save money by not having the instructor be in front of your people who need to be trained.

In order to get more people trained, does it make sense for some of the trainees to listen in by phone?  This does not work.  Period.  The people on the phone will be checking email and working on their regular jobs.  No training will have occurred.  You are better off not having them attend by phone at all.  If they attended the training by phone then in their mind they will have been trained.  There may be a check box marked off by their name, but they will not actually have the required software knowledge.   Resist the temptation to save money on training.  If you want to cut corners, do it elsewhere.  Invest as much money as you can here – have more sessions, not less.  Have smaller class sizes, not bigger.  Be smart about this.

Are their certain training protocols that should be in place in order to maximize the training process?  Here are some training rules we regularly use at Lupine while conducting training:

• Write down your questions.  Do not interrupt the instructor as they are going through the training.  There are more people in the room besides you.  We will get to your questions at the appropriate time.  (Discussions on the use of a ‘parking lot’ are forthcoming…)
• No side conversations - meaning with your neighbor.  Besides being rude it takes away the person you are talking to from being able to hear training.  Side conversations are extremely disruptive.
• No cell phones for what I hope are obvious reasons:  They are disruptive to you and the entire class when they ring.  And there is no better way to ensure your own failure than to spend your training time texting…You can return calls during break.
• No email.  You need to focus on what the instructor is saying, not on answering your mail.
• Multiple breaks - This is an intense process.  I usually go 50 minutes at a time with 10 min breaks and go on – this leads right into the next point…
• Start and stop on time.  If you’re going to start at 10, then start at 10.  When I run a session that starts at 10, at 10 o’clock I start talking.  You have to keep these things moving at a pretty brisk pace.

What are the pros and cons of having internet connectivity during the training session?  There are no ‘pros’.  There are only cons.  If you give people access to the internet, they will surf, they will check email, they will turn on instant messenger, they will check the news, and they will check their stock quotes.  You get the idea.  If you turn it on, then do so unless you need it for the training session itself.  There is no other upside.

What is a ‘parking lot’ and how is it used during a training session?  A parking lot is a tool to temporarily park a question that while important or relevant is not so at that particular moment.  With the proper use of this tool the training can continue on pace and not get sidetracked by a well-meaning question that is not relevant at the moment.  The valid comment is saved and addressed later.  Typically the parking lot is a white board and I assign somebody (not myself) the role of actually standing up and writing the item down so that everybody sees that their valid comment will be captured and valued.  What begins to happen is the dynamic of training attendees not minding that their question is not being answered because they know it is in the parking lot.  At the appropriate time all issues/questions that have been ‘parked’ will be addressed and discussed by the entire group.  If you use a parking lot for your training sessions then you will have much more disciplined sessions.  You now have a respectful methodology of how to deal with people who ask questions that are either not on point or are premature in the training process.  I usually ask permission at the beginning of a session to use a parking lot.

What is better – ‘Train the Trainer’ or direct end user training?  Good question.  There is not really a better answer.  First of all what is ‘train the trainer’?  This is when the software trainer comes in and trains people within your organization to give them the software product knowledge, who from there will go and train the remainder of your organization.  This is in opposition to trainers coming in and training directly to people in your organization.  In the Train the Trainer model, the internal trainers are kind of a middle man in this process.  They obtain the software knowledge and then go from there.  The train the trainer approach can work very well if you:

• Have a training department
• Have many, many users to train or properties to roll out
• Have somebody who is naturally adept at training or software
• And has a strong urge to lead this training effort
• And has the time to do it

Should the training occur at your office location or should an outside training room be used?  Ideally, get a training location.  You’re going to be able to focus more:  no phone calls or emails, and your boss won’t be coming along to disrupt the flow of the session.  This will most likely cost more because you have to go rent the room, but it’s quite possible worth it considering the cost of software failure…

Should the training agenda be customized to your particular needs?  Yes.  Do not accept a canned approach.  This means you are going to have to be proactive with your trainer.  I recommend for you to go ahead and create a first draft agenda and send this agenda to your assigned trainer.  There will be some back and forth between you and the trainer as you strive for clarity.  If you do not do this, then you are going to get a canned agenda that almost assuredly will not suit your needs.  The trainer is not going to know what your hot spots or pressure points are….what your weaknesses are.  There is no way for them to know.

Do not abdicate this responsibility.  You want an agenda that has been customized to your needs and desires.

Should the users be allowed to 'play around' in the software in the beginning of the implementation process?  I don’t like it and I have always felt this is an undisciplined approach to software implementation.  People make decisions about the software and perceived functionality without the education (read: training) to discern whether what they are concluding is true or not.  I have seen unnecessary ‘freak out’ by users when allowed to play because they make these poor conclusions.  In my opinion, there is very little upside here.   Playing is not working.  There is a definite potential downside, and there are better things to do in the project at this point in time than ‘playing in the software sandbox’.

Does the trainer have to be part of the implementation project team?  They don’t have to be.   But if they haven’t been then they do need to be brought up to speed as to how the software modules were configured and other relevant items that only the project team would know.  The training could have bad outcomes if the trainer and the project team are not in sync.  This doesn’t have to be a big deal, but a coordination meeting does should be held to discuss the status of the implementation, the training dates, the training agenda, special needs and nuances of the people being trained, and things you DON’T want to be trained on.

Is there any benefit to the trainer having a copy of the database prior to the training?  Yes.  This way they can see how your system has been configured and can have their training database (if not using yours) configured the same way.  By having the database in advance the functionality the users are trained on is the same as what they will see when they get back to their desks and start using the system on the live system.  Don’t skip this step.  It is very important for the trainer to know your configuration.  If they don’t care to see it, get yourself another trainer.  This means you will probably get a canned training that won’t suit your needs.

Resources
	Sign-up for FREE Software Selection Tips
Do-It-Yourself Guide to Implementing Yardi Voyager™ A Comprehensive Approach By Lupine Partners Planning a software implementation is something that MUST be done correctly in order to have a successful system migration.  Lupine Partners has once again taken our time-tested and proven methodology to bring you our Video Series on Implementing Yardi Systems' Voyager™ product.  The videos and documentation provided in this series will teach you how to implement Yardi Voyager without consultants, but within your time and financial constraints. Click Here To Learn More About The Video Series “The Insider’s Secrets Revealed, Soup-to-Nuts, Blue Collar Guide to Yardi Systems’ Report Development” When the need for a Yardi custom report arises you don’t have to call a consultant – you can create the report yourself!  All you need are the right tools to get the job done.  This video series uses Lupine Partners’ proven in-house training method and a takes a learn-at-your-own-pace approach for providing all the technical information, tools, and know-how you need in order to become skilled at writing custom reports for Yardi Systems’ software. Click Here To Learn More About The Video Series

When a software selection project falls out of the sky and onto your plate, you need a strong heart, a sharp brain, and the courage to tackle the task.  This is the book that provides all three, and more.  It is a clear and methodical map through the unclear and needlessly chaotic process of software selection.

Click Here
To Learn More About The Book