This past December, in the span of 3 days I received 4 different phone calls from software sales professionals that went something like this: “David, I have prospect and they are ready to buy but they don’t want to spend a lot of money on the implementation – can you create a proposal on the cheap?”

Not music to any professional consultant’s ears. I did craft the proposals…and they were crappy as I knew in more heart that I was not serving this prospect well. I was just quoting services for a fee up to their threshold level. Nothing about outcomes. Nothing about success. Nothing about strategy. Nothing.

As a result of the December proposals, Lupine decided to open up our tactics and methodology to the market in order to allow our clients and prospects the opportunity to become The Wizard. We have created and are currently selling the “Do it Yourself Guide to Implementing Yardi Voyager”. It’s for those prospects who don’t want to spend/invest the money for outside consulting – i.e. unsuspecting Wizards. And it’s for those Wizard wannabes who have been itching to ‘look behind the curtain.’ For those who want to go it alone, but desire to be educated and to have us looking over their shoulder. Everything we know about software implementation has been included in this Guide.

I’ve been told by several in the industry that I am crazy for doing this – signing a death warrant for Lupine Partners. Who opens up their intellectual vault and shows their secrets to the world? Us, I guess…And this is one of the reasons why I went ahead with this effort. I look around and see what others are doing, and then do the opposite. To stand out, to differentiate, and to serve my employees and customers. This is no death warrant. In a changing economy, CHANGE!

Change. Just to be clear Lupine Partners is a consulting firm. We still consult with clients on a daily basis. We are also in the product solution business. We consult with our clients through our products on a daily basis as well.

We created our Guide with our team of 5 each having a separate responsibility and function while we carried our full consulting load. Amy served as the project manager using the exact methodology that I teach in the guide. In other words, we practiced what we preached. We had an issues list, held weekly status meetings, had a kickoff meeting, and a lessons learned process at the end of the ‘engagement’. Maggie was responsible for the packaging and shipping. Brian, Angela, and I created the content – each handling about a third. I also had (have!) the responsibility of marketing and selling the series.

Not many consulting firms or companies can match our speed to market. Our 27 DVD series was completed in about 2 months – from soup to nuts. Our agility is a by-product of working together for a very long time, working overtime as necessary, and having a trust in the relative strengths of the individual team members. In our company, the sum of the parts is greater than the whole.

While the Guide was built for new customers, an interesting phenomenon has occurred. Existing Yardi clients have been buying it…Reasons given to us include:

• · not wanting to be held hostage by key employees
• · having to add more properties to their portfolio and wanting to ‘do it themselves’
• · using the Guide as an internal training document

As a marketer, I have been trained to enter the conversation going on in my customer’s and prospect’s head. For prospective software buyers, one of the questions is always: Why does an implementation have to cost so much? It’s a good question – really good. The honest answer is that doing it poorly can be devastating and expensive in ways that most people don’t think of. A few being:

• · An increased amount of time on their old, inefficient system
• · Loss of organizational confidence
• · Loss of time spent on meetings and tactics that did not take them to their goals
• · Employee firings resulting in increased training costs and ramp-up time (on their regular job)
• · Organizational recriminations
• · Money spent on software license fees for a product they were not using
• · Money spent on outside consultants – with no implementation to show for their consulting investment
• · Competitors had pronounced operating advantages due to being on a more current software platform

When should you be the Wizard and when should you beware the Wizard? My answer is that you be and do both all the time – as much as you can. Independence is a good thing – except when it isn’t. For example, if the independence takes you away from your core earning potential or your core business…then you need to be marginally dependent. If you are in a dependent mode, don’t put all of your eggs in one basket and don’t trust one Wizard absolutely. Hate to say this…even if that wizard is me.

Somebody asked me recently about the most outrageous software demonstration I had ever participated in. I have two…couldn’t choose between them.

The first…was my first. Way back in 1990. This particular software company came to my employer’s office with two sales professionals. One was the local sales rep – the other guy was brand new to the software company. So new, that this was his first day on the job…a bit of a gunslinger was he.

These two guys were so out of sync with each other….the low-point came when they actually wrestled the keyboard from each other trying to make a point. Very funny. Needless to say we killed them…The demonstration was so bad that it worked to their favor. I contacted the president of the software company and explained what happened. He came out and did the demo with another sales professional…and they eventually won the sale.

Interestingly in retrospect…this whole little drama was the first step in me forming Lupine Partners. More on this another time.

Lesson: If you are going to be bad…be REAL bad.

Second really bad software demonstration: As more and more technology has become Internet based, it is not unusual for software vendor salespersons to request Internet connections to be made available during the demonstrations. This particular vendor made a big deal about having the connection; processing over the Internet was a large consideration for this particular client.

The demonstration started, and very quickly we began to go through the scripts. The software vendor salesperson was talking about the speed of the processing. I looked up at the screen and noticed that the whole demonstration was running on c:\localhost, which for the technically challenged means that the entire demonstration was running locally on the vendor’s laptop. In other words, the entire Internet connection “hook-in” was a sham. I held my tongue to see if the representative would correct his misdirection. He didn’t. He proceeded through the whole day talking about the speed of the vendor’s internet product. When I held the debriefing that night, I asked the team about the Internet speed. They were very impressed. I then asked how many of them knew that the entire demonstration was local, processed on the software vendor salesperson’s laptop. The IT director raised his hand. The other people in the room were shocked—and then they were angry. We had a long discussion about product and company—good product, bad company.

The really interesting turn on this story was that three weeks later I was going through demonstrations with another client with this same vendor. The same thing happened again. It was an entirely different sales team; in fact, these were senior sales people. I held my tongue and then did the same thing at night: revealed what had been done to the project team. Same result, same anger.

All of this was avoidable. All the sales representative had to do was disclose upfront that he was going to do the bulk of the demonstration locally in the interest of speed and timing. That’s what everybody else does. But they were insecure about the functionality of their Internet offering that they misled.

The really interesting point is that the software company in all 3 examples…from 1990 to 2004…is the same company.

Immediately following The Wizard of Oz, Judy Garland went into production on the Mickey Rooney movie Babes in Arms. In this movie, Rooney plays Mickey Moran, a talented singer and musician, son of a veteran from show business. Garland plays a pretty girl who is also a very talented singer. One day, a big opportunity arrives for Mickey, a big contract to set up his own show. However, things don’t go well, and to avoid being sent to a work farm, he decides to improvise a show in the country, despite the awful weather conditions. And then comes one of my all-time favorite exchanges:

“Hey kids, let’s put on a show!” Mickey says.

“We can use my Dad’s barn!” Judy says.

This same “gee-whiz, let’s just rush ahead with this project” attitude is something I have seen on numerous occasions with my clients.

A not untypical scenario would entail the IT manager being summoned by the president of the organization and told to find a new software package for the company. And that’s what he does; he goes out and finds a package on his own. He puts on a show and uses his dad’s barn. It’s a hasty, quick, impromptu activity that does nothing to move the organization forward. It’s probably not the right vendor or the right functionality—but it is a package. And it is one that most people in his firm have heard of. Low risk for him, and it didn’t take much time or effort to sign the contract with the software vendor.

The problems occur once you start planning the implementation and conversion from your existing systems. Functional items that the IT manager assumed would be in the new package aren’t there because he didn’t ask and he didn’t plan.

Remember the Fram oil filter commercials from the 1970s, “You can pay me now, or you can pay me later”? That logic is the same for software evaluation and implementation. If you don’t do the proper planning, then you may hit a point where you may have to abandon the implementation and revisit the entire software selection effort.

Years ago, a large retail operation in the Southwest hired my consulting firm to lead it through the implementation of a just-purchased software product. We started the planning process and by the second day of discovery, I began asking very pointed questions about their newly purchased software, things that would ordinarily be part of a retail package. I received the answer “I don’t know” quite a few times. At the end of the session, it was obvious that they really had not contemplated all of the operational needs in their organization.

The project was kicked off, but in my head and heart I knew it had a small chance of succeeding because the client was not ready for the change that a new software package was going to bring. They had not defined their requirements and accordingly had no idea if the package would be up to the task.

As the project went on and I exhibited some “tough love” to my clients, they became increasingly agitated about where things were going. It culminated with me telling the business owner (where was he during the “selection” process?) that he just wasted a bunch of money and needed to create a team with representation from every area in the organization to aid in a new software selection effort. I told him he needed to go slower so he could finish faster.

If you scrimp here and try to pick the software vendor in an organizational vacuum, you most likely will get backed into a corner at some point. The chance of getting a software solution match is directly proportional to the amount of effort an organization spends in planning the evaluation and in seeing that every functional area within the organization is represented in the process.

Here’s a big tip for you project managers and marketers out there. Lean close…”plastics”. Ok, only funny to a handful of you.

One of the things I talk to my fellow consultants about is communicating on a steady, recurring basis to our customers – both when on an engagement and when we are not. Here’s how it goes:

Probably the smartest thing we do on our engagements is the creation and issuance of weekly project status report. It helps lowers the anxiety of our clients, fosters communication, and is a consistent tool that all parties involved can count on to track progress and to communicate issues.

The key is having the mechanism in place as part of the project infrastructure. The timing of it must never change, once set – it then becomes an accepted part of the project ‘tools’. It can be used to deliver less-than-thrilling news about the project, particularly when there are under-performers involved.

The key phrases, with regard to project communication, that I continue to hammer home to the consultants at Lupine are the words ‘recurring’ and ‘inviolate’.

The same argument and concept can be made about marketing your business. (See page 1 of this newsletter.) Contacting your customers only after they have jumped ship does not help you more quickly achieve your goals. The contact with them should be recurring, expected, and intentional.

Answer: Maybe.

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

Don’t discount the value of having somebody outside your company run the engagement. On numerous occasions over the past fifteen years, clients have said to me, “Would you go talk to Person X? He will listen to you.” Or, “You and I say the same thing but because we are paying you the high hourly rate, they listen to what you say.” Another nice side benefit to having outsiders come in is that we don’t have to care about company politics. We do our job, get paid, and go home. Sometimes an internal project manager is stuck running the project in a manner not totally to his liking because of the realities of his particular organization. In other words, he wants to keep his job.

How large should the team be? What is the optimal size for a software acquisition team? My preference is five to seven people. That usually covers all the functional areas of most organizations and allows for the meetings where everybody can be heard but that do not go on too long. As number of participants grows, so does the length of time to conduct a meeting, particularly if the meeting is poorly run.

I was hired to manage a software acquisition project for a large East Coast property management firm a few years back. The leaders asked for volunteers to serve on the evaluation team and they got eighteen responses, fifteen from the same functional area). All eighteen people ended up serving on the selection team. It was big-time overkill, and it made conducting the planning meetings and the subsequent vendor demonstrations very difficult. There were reasons why my client did it—over my objections. The ultimate selection was not “better” because the selection team was this large.

At what level of the organizational chart should the team members reside?

They should be in the middle, neither frontline staffers nor the executives. We want people who know the organization and are used to working.

Everybody tends to know who these folks are; they are the ones doing all the work! Ambitious types who want to serve just so they can say they served should be avoided. These guys will not work and will make the others angry and resentful as they have to pick up the slack of a noncontributing team member. Having said this, I have had people on all places of the org chart be successful on a team. They have to want to work, though; that’s the key characteristic.

What is the motivation level of possible team members? Do they want to serve… are they TOO eager to serve? What I am talking about here is bias and/or ambition. We don’t want people who are bucking to select a certain vendor because they worked with the package in advance or because they want to advance in the organization by the kudos that might be granted by being a part of a terrific software choice. (By the way, that goes two ways.) A vendor that was great for one company might not be the best match for another. Steering committee members, be cautious of somebody who wants to be on the team too much.

You want reluctant warriors.

A few weeks back I talked myself out of a paying engagement.

I was asked if I recommended that an outsider always be used on software evaluation and implementation projects.

The answer is no…it goes against what I believe, and frankly what I sell to my clients.

One of my service offerings – both through my book and my seminars is to show people (both consultants and non-consultants) what I do and how I do it. There are certainly some personality traits that lend themselves towards being a good project manager, but at the core most people can learn the required methodologies.

What I told this person though was to be wary of somebody who wanted the job just a little too badly…somebody who is just a little too eager.

What I am talking about here is bias and/or ambition. You don’t want people who are bucking to select a certain vendor because they worked with the package in the past or because they want to advance in the organization by the kudos that might be granted by being a part of a terrific software choice. (By the way, that goes two ways.) A vendor that was great for one company might not be the best match for another.

Be cautious of somebody who wants to lead the team too much. You want a reluctant warrior.

They are probably already over-worked because of their team-first temperament and sense of fair play. You know the type of person I’m talking about.

So, know you don’t need an outsider…but if you don’t have the ‘right’ insider, who is playing for the right reasons, then you might consider looking outside your own walls.

On any project the detailed project plan is your road map of how to get from A to Z. It should be as detailed as possible with tasks and subtasks listed. The tool you use is not as important as the process of creating the plan and the ultimate deliverable that is created.

I use the “one big dump” method of creating these plans. I just start typing in tasks into my project planning software. I do not organize the tasks; I just try to get them all out of my head. This is the hardest and most important part.

Once I get most of them out of my head, I start the process of organizing them into coherent groups. The last steps are to assign people or groups to the tasks and to include beginning and ending dates.

As you create the final plan, be mindful of the concept of “critical path.” A task is on the critical path if its delay creates a corresponding delay in the ending of the project.

Let’s assume our project scope is to complete the evaluation of a new software product by March 31. If the vendor demonstrations are delayed by six weeks, that will mean that the ultimate decision gets pushed back as well because the vendor demonstrations are toward the end of the process.

That task is on the critical path.

Purchasing hardware for the eventual implementation is not on the critical path, although it is a task in the detailed work plan. A delay in this purchase has no effect on the final decision regarding a software vendor.

Tasks that are not on the critical path are not necessarily handled differently and they are not fundamentally less important. They just don’t have an effect on the end date of a particular milestone or of the project as a whole.

I received an email last week from one of my readers wanting to know my thoughts on who the ideal person was to lead a software effort from the inside.

Specifically, they wanted to know if the person needed to have experience in software.

Answer: No

They need to have experience in your organization. They need to feel the organizational pain. They need to know what is not working as well as it should because of system deficiencies. Project team members who have little or no experience in the various software packages are less biased going in.

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

I also was asked: Should the position be contracted out?

Answer: Maybe.

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

Don’t discount the value of having somebody outside your company run the engagement. On numerous occasions over the past fifteen years, clients have said to me, ‘Would you go talk to Person X? He will listen to you.’ Or, ‘You and I say the same thing but because we are paying you the high hourly rate, they listen to what you say.’

Another nice side benefit to having outsiders come in is that we don’t have to care about company politics. We do our job, get paid, and go home. Sometimes an internal project manager is stuck running the project in a manner not totally to his liking because of the realities of his particular organization.

In other words, he wants to keep his job.