You may remember, The Mango, a classic episode of Seinfeld where Elaine agrees to sleep with Jerry in an effort to “save the friendship.”

If you are honest with yourself and the constituency that you serve, then your level of expertise is inversely proportional to the amount of mistakes – and corrected - you have made over your career.  I contend that the only way you can grow in your life is to make mistakes.  Over time you begin to eliminate behaviors that just don’t work.  Humiliation is a cruel but powerful teacher.  Touch a hot stove one time – probably won’t do that again.  Don’t need an instruction manual for that one.

Making mistakes to save the client…if you will.

The power is in the recognition of the problems, the ownership of them, and then making the change either in yourself, the process, the system, the management technique – whatever it is.  As I say on software implementation projects, the identification of a project issue is more important than the resolution of it.  You can’t resolve what you don’t know exists…

To be honest, most of what I do and have done from a managerial (not consulting) perspective fails miserably.  My employees, except for Maggie occasionally, don’t see a lot of them, but I do habitually botch it.  However there is one thing I have glommed on to that works and is powerfully effective for the team at Lupine, and through association, is good news for our client base.  And it’s this:

Every quarter the Lupine meets to go over a variety of things – clients, technical ideas, policy, and consulting techniques.  But the biggest thing that we do is that all of us present our professional failures and embarrassments.  I start the process, and usually have the longest list…I may also be the most honest.  I start to give everybody else permission to be as starkly honest.

We go one at a time and talk about

· The scenario

· What we did wrong

· What we will do differently in the future

· And what we learned

What is so powerful about these sessions is how much the rest of us learn from listening to the others.  Tremendous conversation and learning moments occur because my guys are unabashed in their ability to own up to making mistakes.  They honestly fess up, and then speak to what the correcting behavior is.  And that they will not make that particular mistake again.  And by and large they don’t.

They send me their confession list in advance.  Sometimes I will add one or two that I had noticed during the previous few months.  The biggest managerial change I made, and it has made all the difference, is to let the team make their own list as oppose to me bringing my list of observed transgressions to the table.  That small tweak by me has changed everything.  There is a quote from W. Clement Stone that says, “Little hinges swing big doors.”  This was a little hinge.

Allowing my team to speak about humbling moments in a safe environment has been a boon for our clients whether they recognize it or not.  Or as Kenny Bania would say, “It’s gold Jerry!  Gold!”

Getting older is full of surprises – things nobody tells you about until you are ‘there’. A secret club of sorts…Things like hair starting to grow in your ear when you hit 40 – never got that memo. You become curmudgeonly – my wife has been calling me ‘Mr. Wilson’ for the last several years. Can’t say that I blame her. You wake up one day and you look in the mirror and you realize that you look exactly like your mother (definitely not a bad thing), and that you sound like your father….Never saw any of these things coming.

The biggest surprise though has been a creeping affinity for…for…for…NASCAR. It’s a true guilty pleasure. Yes, I know how to drive a car, use proper grammar, but am probably the least mechanical man on the planet. One time, years ago, I successfully hammered a nail.

A snippet from a recent race: “Yeah, boy he was hummin’ along drivin’ that cage like he stole it….”. “I hear ya pardna – even better since he was running hot with two bad rights and moving chains with the new CJ2R crankshaft.” “10-4 on that.” No freaking idea what any of that meant – but being a man, nodded my head in understanding – since my wife was in the room - rolling her eyes…

I think I like the sport because there is a guy in the spotlight (the driver), but he is only one piece of the puzzle. There is an entire team. You have the car owner, the crew chief, the crew, and the spotters. If they don’t do their job, then it doesn’t matter how good the driver is. They all have to work together. I love the strategy and the gamesmanship of all of this.

One leisurely Sunday afternoon I thought about it I could equate what they do to what we do at Lupine. I tend to get a lot of the attention (driving the number 53 car) for a variety of reasons, but there is a team at Lupine, and if one ‘cog’ is not doing their part, then the ‘car’ doesn’t go too fast (even with a CJ2R crankshaft…)

Take Maggie for instance. She operates as the Crew Chief. The Crew Chief is the boss, the coach and the top mechanic who spots any problems with the car before they interfere with the safety and performance of the high speed racers. He doesn’t have a set position during the pit stop, but you can bet he’ll be there is anyone needs a hand.. Directing traffic, getting this newsletter out, talking with new customers, issuing financial statements, and maintaining the company calendar – that’s some of what our Crew Chief does. Or as Maggie says, “DW were jumping all over turn 3, running hot and lookin’ like he had the jimmies. Had to put 4 new ones on with lower PSI – just a splash of that Sunoco fuel…” Mags knows her stuff.

Amy is our Starter/Tire Passer. In the racing world that person is responsible for passing the inside rear tire to changer, preparing all tires for all on-track sessions and keeps track of the miles/laps on each set of tires and the order in which they are used during the race. He also passes the starter over the wall in the event the car stalls. Amy is in her 13^th year at Lupine – she’s done it all. Served as General Manager, created 5 different evolutions of our website, learned how to become a SQL guru, served as our training coordinator, and is now a Senior Consultant. Amy says, “I done done it all…wherever DW put me, I’m gonna bust a n*t to get her done.” How true, how true.

Brian is our Dead Man. In NASCAR parlance the Dead Man operates the lever on the fuel tank that allows fuel to flow through the hose into the car. The name has been coined because if a fuel problem or fire occurs, he can ‘dead’ stop the fuel by releasing the lever. And that’s what BW does for us, and has for the last 9 years – he dead stops technical problems that the rest of us cannot solve. He is our go-to guy with anything that needs fixing – from a laptop that has died to taking bad SQL code and making it righteous. BW opines, ““Boogity, boogity, boogity, let’s go racing boys!”

Angela operates the Fire Extinguisher. During the race this team member sprays a quick jet of water after fuel hose is removed to wash away any methanol spillage. AC, in her 4^th year supporting the number 53 car, has cleaned up my ‘spillage’ on numerous occasions – either by gently reminding me that I am wrong (or full of it), or by showing predominant software, accounting, and technical knowledge. She is calm, but fierce. AC bringing it – “My life wasn’t worth a shoot until I hooked up with D-Dub and the 53 team. I liked how they all get their hands dirty – even the old man will grab a wrench every now and again…”

Debbie, our rookie, serves as the Fueler. During a race this person fits the fuel nozzle into the fuel tank opening on the inboard side of the car. He wears a full face helmet and a three-layer fire suit. Other racing teams have a gas man and a gas catch man who are in charge of gassing up the car. DG gets this crummy job because everybody has to do their time and to pay their dues….So she now gets the consulting version of having ‘fuel’ jump in her face – and occasionally gets burned even though she is wearing a fire suit. Two months into her career at Lupine, she has jumped right in and taken everything we have thrown at her. DG – “DW told me up front – he was going to be tough on me. The old man is no liar…he done said – the time to worry is when the coach stops yelling at ya. Well, I guess I don’t have to worry…”

It does take a team to be successful. A team of different personalities, talents, and perspectives. And that’s what we have with the number 53 car – AKA Lupine Partners. Watch us at the next pit stop…

If you are leading a training session and the room is set up lecture style, an effective technique is to either teach from the back of the room or to walk the room as you talk. If you teach from the back, you can see everybody’s computer. Here’s what you will catch:

• People jumping ahead of the training
• People answering email
• People surfing the internet
• People surfing the software being trained

It makes people uncomfortable when you stand behind them in a training situation. The flip side of this is that it makes me very uncomfortable (and annoyed) for clients to pay me a fee and then to not listen to the knowledge I have to share. For some people, going to training is the equivalent to going on a field trip when we were all younger. They revert back…

If you want to really see what is going on in your classroom – spend some time in the back of the room.

Best Practices. This is a term that gets thrown around a lot – and something that clients ask my firm to implement from time to time. David, will you implement the Best Practices for doing X for us? The more companies I work with and the more that I see – I have come to the conclusion that the whole notion is a Big Firm concoction. To nod sagely, and to say that you (Mr. Client) need to follow ‘Best Practices’.

I have coined a new phrase. I invented it, and I want attribution. And it’s this:

Best Practices – For You…

There is no one-size-fits-all best practice. There can’t be because every company is different. Your organization has different biases. You have different talent levels at different positions within your company. Your department may have different objectives than similar departments at your competitors – IT may be a profit center at one company and a cost center at another. Each company has things they will and won’t do because of culture, or money, or the access to money. Companies have different sorts of vision and motivation with regard to software.

Here’s a real life example. I was having lunch in early July with a client. He asked me what the Best Practices were with regard to whether accounting personnel or on-site manager should enter their commercial leases into the system. My answer: I’ve sent it done well and miserably both ways. What worked well for one did not work well for another. Some of the variables that affect that Best Practice are:

• The number of resources in each group
• The quality of resources in each group
• The overall tenure of resources in each group
• Company policy
• Company politics
• Was the property management person primarily hired to lease space?
• How does paper flow within the organization?
• What is the review policy with regard to entering leases into the system
• Maturity level of company
• Maturity level of employees
• Executive leadership

As a consultant, the wiser you become – the messier the analysis because you know more. You have a cache of experiences that you have seen work well and not so well. You also have a client that you have become intimate with knowing their personal and organizational strengths and weaknesses. The gift is the melding of your experiences and you knowledge of the client into a Best Practice – For Them. When you have done this you are really performing a service for your client.

Best Practices as defined by most is a pure intellectual exercise. Best Practices – For You is not an intellectual exercise. But rather a messy, contemplative, intimate analysis for your paying customer.

You heard it here first.

In 1995 a client of mine in New Mexico flew me in for the day to train a new employee on how to use their property management software. Prior to the training, I asked several times if there was any preparation I needed to do prior to the one-on-one session. Each time I was told to just show up and we’d have a freewheeling session. Went against my better judgment, but okay.

John picked me up at the Albuquerque airport and we drove into Santa Fe – about an hour’s drive. I asked a few more times about how he saw the day going…We get to their office and he shows me the conference room door and he tells me we’ll be working in there. I walk into the conference room and there are 12 people in the room. All wanting to be trained by me! I have no agenda, no computer, no computer set up…and to make matters worse the topic was not one of my strongest.

I began to feel the sweat on my forehead and back, and to smell the stench of embarrassment and failure. I went and found John and did the 1995 version of WTF. He thought he had told me there would be an entire group to be trained. (We were JUST in the car together where I asked him that exact question!)

Long story short – it was a tough day but I got through it. Having a sense of humor helped. Big lesson learned – always assume that there will be more people attending than you thought. Always assume that the room will not be setup properly. Always assume that the technology will not work. Be ready for all contingencies, because when you are in front of a group of people, forces always seem to work against you. This experience made me a better consultant as I had to struggle against a lot of obstacles that day…but I made sure that nothing like that ever happened to me again. And it hasn’t.

The much revered, very wise, aged rabbi is on his deathbed, his rabbinical students gathered for the deathwatch, arranged with the smartest of the students at the rabbi’s head, the next smartest second, and so on, down to the pitied dunce of the class at the foot of the bed. As it becomes increasingly apparent that the old rabbi was soon to depart, his best student leaned over and whispered, “Before you leave us, could you please, finally, give us THE secret of life itself, great master teacher, sir?”

After a few moments of thought, with considerable effort, the rabbi managed to croak out, “Life is like a river.”

The honored student turned to the one next to him and said, “The master said ‘life is like a river.’ Pass it down.” And so each student in turn passed the wisdom down to the next. But the dunce said, ‘Hey, wait a minute. Life is like a river? What does that mean? Ask him what he means by that.”

Ashamed and tentative, each student passed the question back up the line. The best student again leaned over and said, “I’m sorry, master teacher, but the dunce, down at the end, he does not understand. He wants to know: what do you mean? – Life is like a river.”

With every ounce of strength remaining in his dying, frail body, the rabbi managed these last words: “Okay, so it’s not like a river.”

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, and these trainees will go and train the remainder of your organization.

This is in opposition to trainers coming in and training directly to everyone in your organization. In the Train the Trainer model, the internal trainers are kind of a middle man in the 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 both a strong urge and the time to lead a training effort

Otherwise you are probably better off hiring out the end-user training process.

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.

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, and 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…

Software Implementation Myths

It is not uncommon during the implementation discovery process to encounter some ill-advised misconceptions regarding the process. Here is a short list:

Myth 1. You are done when you execute the software contract. Nope – you are just getting started. If you purchase software, but botch the execution of the implementation, then nothing really has happened. Evaluating the right product for your organization is obviously important, but a skillful execution of your implementation plan is where the financial payoff is.

Myth 2. Implementation and training are synonymous. Training is a component of implementation – an important one. But it’s only a piece. If you are only paying, or plan to pay, for training, then you will not move more quickly to your goals. There is more involved than just training.

Myth 3. Software implementations must take a long time to complete. Not so at all. It’s all in the planning. Unfortunately, some companies want to skip this vital step in the interest of ‘getting a leg up’ and getting started. We have learned that the tortoise always finishes faster than the hare. We have completed migrations for some clients in as little as six weeks.

Myth 4. Parallel processing between the existing software system and the new software system must occur as part of the implementation. Parallel processing should occur if you are not certain of the functionality of the system you are converting to. Any sort of pilot testing should occur before the acquisition of the software. It is an unnecessary burden on the project and the employees who must now do their work in two systems, rather than one. Not good.

Myth 5. Planning can be skipped. Only if you want a failure. Guaranteed.

Myth 6. The first thing that must happen on the implementation is to train all of the users. We get this one a lot. It’s a good idea to give the user base an overview of the system, but only for purposes of system setup – in other words to facilitate system and module configuration. End users should be trained as close to the go-live date as possible. Why? Answer: Use the information or lose it.

Myth 7. An outsider must be your implementation project manager. Anybody can be trained on how to be an effective project manager. There are pros and cons to hiring an outside professional.