Defining the scope of the Software Evaluation project is the first critical step. Do not assume that everybody is on the same page.

As described in my book “Software and Vendors and Requirements, Oh My! – A Project Team’s Guide to Evaluating Business Software”, I start all of my software acquisition planning and implementation meetings asking for the scope of the project. More than half of the time, there is disagreement in the room. Know this: You cannot implement a moving target. Write the scope down, and then read it out loud. Keep doing it until everybody agrees. If there is not agreement, then this will be the first item that you will run up the flagpole to the Steering Committee.

“What is a scope document?”

The scope document defines the boundaries and limits of the project. It is a clearly written description of what the project is. It should include the items in scope as well as those that are not in scope. For scope definition, consider:

• areas of the client’s organization
• package or modules of a package to be evaluated
• descriptions of enhancements to be evaluated
• business functions or processes
• affected or replaced systems or subsystems
• relevant hardware platforms
• contemplated or required interfaces
• features or functions of a piece of software to be evaluated
• work that must be done to complete the project

Beware of a phenomenon known as “scope creep,” the changing of the previously agreed-to scope during the course of the engagement. This is not unusual in systems projects and if you do not handle it correctly it can derail all of your hard work to date. When this project poison rears its head, the project manager must address it immediately.

Do not assume that everybody knows when a change in scope occurs or that they agree with it. For example, a project is kicked off with a scope of evaluating accounting packages, and then it is agreed that point-of-sale packages should be evaluated as well as part of the ongoing process. This is scope creep. It’s now a new project with a whole new set of considerations. At this time, the project team and steering committee can decide to:

• let the point-of-sale project be its own project with its own selection team or
• expand the scope of the accounting acquisition project. If the project is just kicking off, this is probably fine. If you have software vendors coming in the next week to show their wares, you are most probably starting the entire process over from scratch.

When scope creeps rears its ugly head (and it probably will at some point), act on it immediately by putting the steering committee and project team together.

One other comment on scope: There may be times when you want to cut the project scope back. If the “bite” of the project is too big and will strain limited human resources to the breaking point, go ahead and reduce the scope. It’s better to have a smaller success than to have a larger failure. Knock out the smaller project and live to fight another day.

“Why do so many software projects fail? Has anyone learned lessons that will help my project to avoid failure?”

While there is no one “right” way to purchase software, there are many wrong ways as I have described in my book “Software and Vendors and Requirements, Oh My! – A Project Team’s Guide to Evaluating Business Software”,

There is definitely strength in knowing what not to do.

Several times over the years I have stopped meetings and said, “You remember when we started this project and I made you all sit through my ramblings of why projects fail?”

“Yes,” they say.

“Well, we are doing some of them—and we have to stop.”

Saying this works, because we had the discussion in advance and because we were intentional in our efforts to curb dysfunctional project behavior. The list I am going to provide is not necessarily the entire list of behaviors and actions related to project degeneration. but they are the ones I have seen in working with close to one hundred clients in matters related to business software.

Here’s the list of major offenders:

• Lack of executive or managerial buy-in
• Projects that take too long
• Organizational inflexibility to change
• Poor resource allocation
• Negativity
• Lack of a plan
• Lack of understanding that the organization is buying both product and vendor
• Bias
• No method for identifying and resolving issues
• Lack of project leadership
• People not doing what they say they are going to do
• Decision remorse
• No defined project end date
• Lack of a realistic project budget
• Team members’ objectives not in alignment with the business objective

Lack of executive or managerial buy-in. The software acquisition process must work from the top down. This is a large effort in any organization and requires hundreds of hours across all functional areas. If executive buy-in has not occurred, then people on the team may not give their best efforts and the leaders of the company will not respect or support the hours and dedication it requires to get a software match. I put this lesson on the top of the list because it is the number one reason for projects “gone wild.” Think about it: your organization is going through a major effort to investigate new business software. You are going to invest major time and money in doing so; shouldn’t the top managers and executives be on board and engaged? It is tough to get past poor leadership and do a good job on these types of projects.

Projects that take too long. Here’s the deal: Most people—and organizations—only have so much endurance and time to work on projects of this magnitude. If an end date is not specified up front or if the project continues to be delayed, the momentum and energy for finishing the project will just dry up and go away. Also, company management will lose confidence in the project team. If the project looks like it is going to be a long one, then break it up into bite-size phases and have multiple projects. Psychologically it is more palatable to all concerned.

Please look for Part 2 of this article describing the major offenders of project failure

As a reader of many different books in many different genres, I have gotten in the habit of marking passages that I find interesting or challenging. As the years have gone on, I have taken this habit and made it worse by typing up some of the passages so I could study them…then the habit got worse with me putting the passages in frames and putting them on my office wall.

For example: “Money matters, but less than we think and not in the way that we think. Family is important. So are friends. Envy is toxic. So is excessive thinking. Trust is not optional. Neither is gratitude.”

I had a client come to my office recently. He looked curiously at my collage of passages on the wall. He asked about them and then wanted to know where my awards and plaques were. I pointed to my CPA certificate and college diploma to lying on the floor in shame – driven down to the basement by my compulsion for improvement and a need for a different kind of education than I received at the University of Texas in the 70s.

In my opinion, displayed awards are for others…accomplishments for sure, but are based on the past. My office is geared, and sets my mind, for the future. I think it is important to never NEED the accolades. Need for it, just like the need for just about anything, including money, invariably leads to unproductive priorities, decisions, behaviors, and compromises.

Need is evil.

Attention or recognition junkies often discredit themselves, give up the authority or autonomy, waste time and money, and otherwise damage themselves and others. You cannot afford to be always in search of a mommy to put your latest drawing up on the refrigerator with magnets. If there is some particular recognition or publicity that strategically serves your deliberate purpose, effort invested in obtaining it is justified.

But as an end rather than a means, as spotlight for spotlight’s sake, it is embarrassingly juvenile. The highest achievers pretty much concentrate on the work and its results…not on recognition. Appreciate it if and when it comes, but don’t worry about it. Or who else may be getting it.

By far, the best recognition is a private matter; self knowledge of the job well done, the life well lived.