The Discipline of Project Justification - Part 3

Third in a multi-part series
By Tom DeVroy
VP of Sales

I started this series discussing some of the steps I’d recommend to a project team when trying to justify a project to management. The second part of the series dealt with the definition of the business case. In this post I’d like to discuss a solution scenario, which is a situation where you have management understanding that there is problem, perhaps they have painted a vision or made a vision statement, and now they’d like to hear your ideas for potential solutions. Not that they are looking for a vendor recommendation or the definition of what the internal costs might be, but are simply interested in hearing more about their options in a way the demonstrates you understand what is trying to be achieved.

This requires some research and often times a good deal of work. You have already spent a long time thinking about what the business problems are that you want to fix. This could be inefficiency in your operation, dual data entry, lack of visibility to service levels during a service process, missed revenue opportunities, or whatever the case may be. Understanding your business problems that need to be fixed should drive a whole new set of business requirements.

What’s the Current State of your Company?
These requirements reflect the necessity of your specific business, as well as those requirements necessary to address your future model. Consultants refer to this as current and future state. It would make sense that most people know their current state but I frequently find that this isn’t the case. Often when we ask prospects about their current business process we tend to get more questions, blank stares, and referrals to other departments or individuals. It is very hard to derive the benefit of a new automation project when you can’t determine the impact on your current business.

Take the time to define your current operating model. If time or resource demands are too great to perform an adequate analysis internally, hire a consultant - they are experts at performing these assessments. This, however, is a task best performed internally because it requires a good deal of interdepartmental cooperation and communication.

The Present will define the Future
When completed you need to take the documentation to determine the future state of your company (the state it will be in after the problems are fixed). This future state ought to align with the vision of management. Once again, if you have a problem thinking outside the box, hire some external industry expertise, or use the change process to force this new model of thinking. It’s ideal to do this work before you start a solution search but it’s not always practical. Do the best you can to at least identify what it is in your current state that you want to change or fix. Between the current state and the future state this should drive your requirements.

Draft your requirements against those processes in the current model that you want and need to bring forward, as well as those requirements necessary to meet your future state. A good example would be a company that closes out their service calls on paper. This causes delays in billing, disputed invoices, and extends their AR days outstanding. To remedy the problem they would like to automate this function through mobile automation for their field people. After this is clearly articulated, management will want to know their options.

Make Sure that Management is Onboard
Speaking of management, get approval and sign-off along the way. Have them review the current state documents and have them approve the drafted changes in the future state. They should be well aware of these changes seeing that they are the ones that ought to be driving the changes.

The research in the solution definition should include the technology choices, different vendors, preliminary budgets, and so forth. Once again, get some management approval on the technology and the vendor alternatives. Managers may have strong preferences to particular technologies - or they may not care as long as the functionality meets the needs of the business. Whatever their opinion, it’s always better to determine this up front.

Don’t Blow it on an Unrealistic Budget
There’s nothing worse than spending a long time on a project only to find out that there is absolutely no money to fund it. So it’s important to make sure that your budget estimates are realistic. Finally, get your potential vendor alternatives approved in advance. Managers and executives may have had past dealings with a vendor that drives their preferences. Once again, better to understand these preferences up front.

I find that the selling process for Metrix is often a validation process for our prospects. They go through a buying process to validate a decision that was tentatively made prior to vendor evaluation. It pays to do as much up front research as possible, getting buy-in and approval along the way.

In the next post I’ll discuss how you might want to define project assumptions and potential risks, as well as rewards.

View Part 1 Here
View Part 2 Here
View Part 4 Here
View Part 5 Here

What is good software, anyway?

By Larry Laux
President and Founder

That might seem like a silly question coming from the CEO of a software company, but I’ve been asking that question of myself lately. I’ll share some of my answers, and some related questions and answers, in this and in some upcoming blog entries.

To be able to answer the question, I need to re-state and frame my question more tightly: ‘What is good business application software?’ To begin with, what pieces make up business application software. Then, what makes those pieces ‘good’?
Here is a short list of general attributes of business application software:

It has to perform the business function it was designed to perform – print payables checks, track field inventory, whatever.

I am not convinced that there can be ‘too much’ business capability. But I do agree that software can be hard to understand and follow what it’s doing (which can safely be called ‘bad’). Also, if users don’t want to use a feature, they should be able to easily ‘turn it off’ or otherwise avoid it without being forced to plow through unwanted stuff.

It needs to play well with other systems. For example, a scheduling package must easily take in data from the system storing all of the service calls, perform the magic of optimization, and send the answer(s) back in an acceptable format. This ‘data mapping’ and integration of information between systems can easily ‘blow up’ a project. More about this in a future blog entry.

The software must have good hygiene factors. Among these are:

• Runs fast enough, short response times.
  
• Is secure in its handling of data, especially sensitive data.
  
• Can reasonably grow with your organization without degrading performance.
  
• Is built in an acceptable or better technology.

The user interface is another piece of the overall system. I am still not convinced that any software is or can be intuitive. Sorry, Mac users, I don’t buy it. But I absolutely think it can be conventional, and MUST be consistent. Further, if it can be easily adjusted to the specific business process of the users, that is a significant advantage.

It’s interesting that some of these are subjective – what is ‘fast enough’ for some situations may be totally unacceptable in others. I expect, though, that a small group of smart people in your company could get together and develop a list of wants and needs from this very high level list of attributes.

But what makes application software good?

Partly, good-ness is contained in how the above items are achieved. A hands-on trial can help determine if you think the user interface is ‘good’.

I would say that if a software package were to be judged ‘good’ in three, or all four of these categories, it would be ‘good software’. But I think there are more attributes that a software application can have. With them, a ‘good’ software package can be ‘very good’ or ‘great'. I will try to get to those in a blog entry next week.

Let me leave you with one closing thought.

Software vendors especially, but sometime also buyers, get wandering among the trees of features, functions and sizzle and lose sight of the forest.

I think the number one, most important, gotta-have from a software application is – USING THE SOFTWARE MAKES MORE MONEY FOR YOUR COMPANY. Everything else is fluff.

I completed the Milwaukee Lakefront Marathon

By Larry Laux
President and Founder

Yesterday I joined 2500 other marathoners and started the 26.2 mile journey. As a first time marathoner, I really didn’t know if I could finish, or even what to really expect. The longest distance I had ever gone previously was 11 miles.

I had built a plan based on Galloway’s training method – run, run, walk. I would run for two time periods, then walk for one, right from the first mile. I felt remarkably good for the first 3 ½ hours.

We were very fortunate to have an excellent day for the race. The sky was cloudless all day, and very light winds. Temperatures at the start were 50 or so, and rose to the upper 60’s by early afternoon.

As the saying goes, I ‘bonked’ a bit around mile 19 or so. My legs started feeling pretty heavy. I had been taking my ‘goo’ (a carbohydrate gel designed to give a controlled fast-acting energy release without the crash) about every hour. By the way, they try to make it palatable (‘apple cinnamon’, ‘raspberry’,’vanilla bean’) but overall it’s pretty disgusting. Still, finishing was not certain.

Somewhere in there I switched from run, run, walk to run, walk, run, walk. In Mile 23 as I hit the lakefront, I was pretty sure I would finish. My support crew (my wife Nina) had been providing me with support and assistance throughout the race. She was incredibly helpful and patient.

How did I get this idea? Well, I turned 50 this year, and my Mom (she is SO cute) sent me $50. Now, what can I do with $50 that will be memorable?

Two words: “Entry Fee”.

So, now I can tick the “Did a marathon” box on my life accomplishments list. I doubt that I will do another one. And you don’t have to be concerned about me being too boastful of this feat. Metrix’ VP of Sales, Tom DeVroy has completed an Ironman Triathlon – where you swim for 2+ miles, ride a bike for 120 miles THEN run a full marathon. Worse yet, on his day the weather was in the 90’s.

He wins bragging rights.

p.s. if you’re really curious about my final time, click here and enter Larry Laux in the name box.