Years back actress Meryl Streep was giving a commencement address when she said this:

She said, “You have been told that real life is not like college and you have been correctly informed. Real life is more like high school.”

College and graduate school teach us that technical competence is all. None of these institutions reward the human qualities that tests cannot measure. College graduates come out of school with the firm belief that knowing your stuff is what counts.

Remember?

This lesson of college conflicts with the lesson we learned immediately before it. Children and teenagers learn to value well-roundedness and traits that are likable. College seduces us with the notion that real life will be an oasis where sheer talent is what counts.

Early in my career I made the transition back from college thinking to high school. What good does it do to be a socially deficient expert who gets zippo clients?

Same thing applies to software evaluation.

I have met other consultants who have much formal training than me. (I know this because they tell me.) But they are not better than me at what I do…and I know this for several reasons.

One, I have a LOT more clients than they do.

Two, I have been able to sustain my companies for 15 years providing the same software core services to my clients.

Three, I don’t try to put these evaluations through an intellectual meat grinder.

Do I quantify the results of the evaluations? – you bet.

Do I make final recommendations to my clients from these quantified numbers? Nope.

I watch the body language of software sales people…I watch their eyes to see if they are lying or BS’ing me or my client. I read between the lines of their answers to pointed questions I ask in the vendor questionnaire. I listen to what they don’t say…or what they should be saying.

This is all part and parcel of being a good consultant…thinking AND feeling.

None of us were taught that in college…

Earlier in the week I was talking about a client of mine who was insistent of getting two years of financial statements from software vendors…even though they admitted they were not going to do anything with the information…

There are scoring systems that have been created that (attempt to) gauge the financial soundness of software vendors. They ask for years of financial statements and from these statements try to determine the companies’ financial shape.

The determination of financial soundness is in itself a subjective determination.

Does having a large cash balance mean that you are financially sound or does it mean that you have not been investing in new technologies or reinvesting back into the company? Does having no debt mean that you are financially sound or does it mean that you are missing the boat by not borrowing to take advantage of business opportunities? If you had a bad year last year, does it mean that this year is doomed? And so on.

The only thing I look at on the financial statements is the notes section—if there are audited statements from a CPA. At a minimum, ask the following five questions in the RFP:

• How much is your recurring revenue? In other words, if you do not make a new software sale this year, how much revenue would you have coming in from your existing customer base?
• How many deals do you have in your pipeline and what is your success ratio of demos to sales?
• How many sales have you made this year?
• How many sales have you made that have not yet started implementation?
• How many implementations do you have in process?

To me, the past is past. What you want to know is whether the vendor is viable at the moment and how big its customer base and recurring revenue stream is. If you want to go into a full-blown analysis of the financial condition of a software vendor, you need to determine in advance what the criteria will be for financial soundness.

I have been a CPA since 1982 and I can tell you that this is a slippery slope and not easily done.

Last year, I had to give a little talk in front of some people.

The presentation went well…as I knew it was as I was going through it. I was asked later on if I was nervous while speaking.

I thought for a second and said, “Yes, right before I went on I was…but once I was up there I was very comfortable. Because I knew I was just going to be me…baggage and all. I knew that I would ‘let it all hang out’ and that would be appealing and attractive for my audience.”

And I knew it would be comfortable and relaxing for me…being yourself normally is.

Many people mistakenly believe they have to perform, to get it right. They hold back, afraid to reveal their true self. They have an image of what a good presenter should look like, and it’s often something very different from how they truly are.

It’s called wearing a professional mask.

This mask is bad for your career, your income, and your health. This internal pressure to uphold a mask, a false self in front of an audience, is at the core of performance anxiety and nerves. Your goal, when speaking to any audience, is simple. Give as much as you can.

You give when you are well prepared, when you present a clear roadmap, when you make them laugh, when you give relevant examples and choose stories your audience can relate to. When you muster the courage to tell the truth, and even when you are selling your audience something that will benefit their lives. It’s true - selling a great product or service and helping people recognize the benefits is an act of affection, too.

So if you’re a nervous speaker, you’re not nervous because you’re afraid of standing in front of a crowd.

You’re nervous because you are afraid to give.

Think about this for a moment, and then resolve to share. It all gets very easy after that.

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.