Business Application Value

Projects and Priorities

In keeping up with these times of limited resources and high desires (if not expectations - which may also be running high!) it is critical that project priority be properly set.  Many of us have been involved with projects which have many facets to them, and depending upon the environment those facets may be very clearly defined, or perhaps somewhat nebulous.  They may be down on paper or in the developers and users heads.  Either way, setting the proper priority for the project is critical.

While there are many criteria to focus upon I believe there are two areas in particular that warrant looking at very closely.  Certainly the overall value of the application to the business is one critical criteria to be considered.  Where does the application fit?  What will it bring in the way of added value to the operation?  Can this added value be quantified?  Is this an application which when completed will result in the saving of time, labor or materials?  If so, to what extent? 

In addition to the added business value of the application I believe that the testing procedures being used with the project be clearly monitored.  Test for value to ensure that the desired or expected return can be achieved.  Test especially for data integrity, try to “break” it, ensure solid product through your testing.  Be creative in the testing wherever possible in an effort to prove usability.

I believe that any project which can’t produce a high “value add” probably shouldn’t be done (at least at this time).  However, any project given such high “value add” is worth taking the time required for testing which will produce a reliable and valuable application.  Now more than ever, extensive testing should be the order of the day.

Application Value

Earlier this week I was speaking with a client for whom I had developed a custom solution for tracking and maintaining records of truck use mileages.  The company has multiple locations scattered within a 200 mile radius or so, and crossing state lines.  The project started out specifically as the result of an increasing difficulty in getting the individual logs and information back into the corporate headquarters in a timely manner to create the reporting required by the governing agencies.  The existing process required significant time to assemble, organize and prepare reports from the existing logs (…which more often than not were not legible!).  In fact, the person whose task it was to prepare the reports figured they spent somewhere between 8-12 hours preparing the reports each month.

From my developer perspective this was an excellent demonstration of need which could easily be developed.  The goals desired from the program were to establish:

• Timely reporting
• Increased accuracy
• Accessibility
• Painless Operation (read that as EASY) to use

To accomplish these goals a multi-user database application was created to collect log information on a daily basis — a key element of which was an EXTREMELY simplistic user interface for entering the log information by employees without typing skills.  This was accomplished by extensive use of selection lists, calendar date pickers, combo forms and checkboxes - mostly it was odometer readings to be entered with the keyboard.  (i.e. Start/Stop readings).  Validation was built into the program to check the “reasonableness” of the entries.  (i.e. an entry showing a truck doing 1000 miles in a day would not be accepted!).

As (I believe) with any application, the “real” value of the application has come with the variety of reporting now immediately available.  The system is “real time” so a quick report run to the screen any time during the month can easily show “missing” or errant entries which can be followed up on while memories are still fresh. 

As for the “value” of the application (…which by the way has been running for about 5 years now!),  it’s difficult to quantify the accuracy gains, but certainly there is much more confidence in the current data (which looks quite different than previous data, probably because of inaccuracies with previous methods).  As for the time spent preparing reporting - a savings of hours per month has added up over 5 years!  Value of information availability again is hard to quantify, however as a sidebar, using the log has enabled better tracking of preventive maintainance for vehicles — certainly a benefit!

I love hearing reports like this where the value of an application shows such clear value!  (Especially when it’s a piece of my work!)

Coming Back to a Project

Regardless of the reason for a development project being delayed, coming back to a project which has been “on the back burner” for a while seems always to raise questions about the project.  For me the questions may start out with “Where was I on this before I had to leave it?”, to “Why on earth was I heading in THAT direction with this?” — or my favorite “What was I thinking!”   …usually an indication that I wasn’t thinking! ) .  Besides the “lost” time of re-aquainting oneself with the project, there have been many projects for which the longer they sat, the more I just wanted to start over again.

As an independent developer I’ve always had to be working with multiple projects at a time, and somewhere deep down in my being, I wished that I could just have one project to work - from start to finish!  The problem with that idea is that for one thing a custom application project never seems to end — mostly as the result of constant improvements being made to the application — or “tweaks” as one of my customers call them, so there is seemingly always something more to be done. 

However, coming back to a project can be challenging.  It can also be an indication to one as a developer of how much they’ve learned in the say, six months that a project sat without being worked on.  This is a good thing!  Whenever possible when I have identified that some previous work can be improved upon to simplify or somehow make the code more maintainable — if at all possible I make the change.

Another thing I have experienced after coming back to a stopped project is that very often I find that in the time lapse since last working on the project the needs of the user community for which the project is designed may have changed.  Certainly it is imperative that before going ahead with any stopped project there be clear communication with users or as a minimum the person ultimately responsible for the project from the business need standpoint.

Coming back to a project can be exciting — but it can also bring new requirements, expectations and challenges.

Managing Application Expectations

I remember the statement made by the president of a software company vendor of mine in a meeting some years ago as if it were yesterday.  The comment, made to a salesperson of his also in the meeting, was this — “See, it’s all about managing expectations.  We have to do a better job of managing expectations.”  This was his whispered response to the “complaints” he was hearing from us, his customer, about our (I’ll be nice ), disappointment with the software quality and performance. 

In a similar vein I also remember being in a meeting with our previous software vendor where, trying to make light of our “concerns” with the ever increasing software support fees which we saw as getting us nothing, this president quipped jokingly “…gotta keep up our cash flow you know!”  That statement was the opening of the exit door for that software and vendor — never forgotten by our company — and referenced many times over as the years went on.

While I don’t mean to suggest that either of these comments represent major attitudes of an application vendor to their customers, the examples above do point to an important attitude that (I believe) applications vendors “should” have — and that is “listening” to their customers expectations and really “hearing” how their software is, or is not, meeting the customer expectations.  I’ve blogged in the past about “hearing” in my post “Please Hear What I Really Need“.  This kind of active listening goes a long way toward managing software application expectations.  I highly recommend it!

New Applications - Taking the First Step

Social networking in business has been receiving quite a bit of press lately with many differing views on just what should or should not be allowed, or how to use various social networking tools now available.  I ran into an interesting read in an article “Social networking in business: Avoid the ‘Kumbaya Zone‘.  Now, the ‘Kumbaya Zone’ is a new term for me, and the article refers to it as “…the place where social media is ultimately a time-waster and has little business value”.  

Now I don’t want to get into any do’s or don’ts about social media - nor do I think that it would be wise for me to do so — but what I do want to address is that perhaps many of us have seen applications which appear to become time-wasters with little business value, I certainly have.  They may be the “old” application never replaced, or they may be an application for which users have developed so many work-arounds to have it fit that there is much time wasted.  Either way, the application has little business value.

The referenced article ends with the statement “Get comfortable taking that first step, and see what works along the way. That is way different from the software model we’re used to.”  Now, I certainly agree with the first sentence concept of getting comfortable and  seeing what works - and while the article specifically is talking about social media, I would posit that this is an approach worth considering for any new application.  As for being a different software model than we’re used to, I must say that working with my customers we’ve been able to create an environment where we do to a large degree follow the concept - it doesn’t have to be “…way different…” than we’re used to.

Sometimes the Obvious is Missing

We developers need input from our users!

This became very clear to me once again last week when I received an unexpected request from a user to add a simple lookup function to a field in their order entry program which has been in use (…and regularly enhanced) for over 5 years.  When I first received the request I was shocked to discover that such an obviously beneficial function would be missing.  In fact, my first thought was something like “How could [the user] miss it?  Of course there is a lookup there!”  Then, upon further investigation and review going back numerous iterations and versions I discovered much to my surprise that it NEVER was there — an obvious omission.

All of this led me to recognize once again the value of having a close relationship with my user community.  Working with the small & medium size companies that I do, it is generally commonplace.   This incident also pointed out to me that user and software developer/designer alike can easily miss obvious functionality enhancements.

P.S.  The program now has the desired lookup!

The Business Process — How Does It Get Complicated?

I wonder how many of the business processes which a company develops over time from its early days as a very small company to a larger organization become overly complex.  Of those processes, I also wonder just how many of them are the result of new demands on the process simply as the result of the growth of the company, and how many of them become “the way it’s done” out of habit or because of other requirements mandated by the business environment. 

I’ve worked mostly with smaller companies, often times businesses that have started off very small and grown to become multi-location operations.  As their growth has progressed the needs for tighter controls becomes increasingly apparent.  No longer can the business depend upon the memory of that one key individual who “knows everything” that’s going on — who knows the customers, knows the vendors, knows each employee.  As staff increases so does the “risk” associated with no longer having a close, trusted, personal relationship with employees, often co-founders of the company. 

Many of the applications with which I’ve worked were originally developed specifically to provide the growing organization a means to “get a handle on” information that many may need, but early on resided in the head of the “key” person.  The small company finds a way to get the job done - process is the least of concerns.  I believe that what happens often during the growth period is that as the need for defining the business process becomes clear, efforts to define the business process fail because there are “so many variables”.

Its at this point that I’ve found a company will generally make the buy or build decision for software.  Some will look at a vertical market package for their industry and decide that the “business process” required by the software is the way they should be running their business.  (Hey — it works for others - why re-invent the wheel?).  Others may find that they just can’t see themselves running their business “just like everybody else”, and they will choose to have a customized application.  Then there are those who choose that vertical market package, work hard to change their business processes to “fit” the software, and then find the “work-a-rounds”.

“Work-a-rounds” add a level of complexity to the business process that is generally not required.  If your business processes are too complicated - maybe its time to look at how much is a “work-a-round”, you may be surprised.

Beta Testing - Not for Everybody

It’s like the stock market - it can be risky - it can be frustrating and downright annoying - and it can be rewarding.  I’ve always liked participating in beta testing of products which I find of value, or as has happend to me before, in a product that I had to use - but (let’s just say to be nice), needed a lot of work — and by beta testing (with our live data of course) we got to evaluate the latest and greatest of the software.  Most of the time it was a win-win situation, but not always.

I wrote a few weeks ago about how my chiropractor didn’t realize what it meant to be a beta test site, and consequently just how much she “suffered” with the arrangement.

For me, as a custom software developer, I think I like participating in anothers beta test because I invevitably learn from the experience.  There are 2 major learning opportunites that I consider to provide the value for me by participating — they are:

1. The opportunity to really learn a product and understand it
2. The opportunity to find out just how the software provider works

Products and companies have made it and lost it based upon my experience with beta testing their product.  If a company isn’t easy to work with when you are providing beta testing, they probably aren’t a company you’ll want to work with long term.  Likewise with the product.

A Business Process NOT to be Duplicated

When an independent application software developer first meets with a prospective new client it becomes very much a meeting where each party is evaluating the other.  For the developer it becomes questions of “Is this an organization I can work with?  Can I provide what they are looking for?  Can they pay me?  Do I want to do the proposed work for this organization?”.  For the prospective client the questions become “Can I get what I want from this developer?  Is the talent there to provide the service?  Can I afford the service?  Can I work with this developer?  Do I want to work with this developer?”  All good questions - left generally unspoken.

In speaking with a fellow developer today I was reminded of this by a story he told of one such interview where he decided that he was NOT interested in doing work for the prospective organization — and the reason?  Basically it came down to the prospect being firmly entrenched in a business practice that was just plain poor.  The application in question was an inventory application - the problem to be solved was to have a system that kept inventory straight.  The “real” issue, quickly identified for the prospect was their practice of transferring inventory from store to store.  They used hand-written packing lists for the transfers.

There were 2 locations, each keeping their own separate inventory system.  Each properly received inventory, and inventory was in fact properly relieved by the sales function.  The system wasn’t used at all for the transfer of goods from one location to another — no surprise that inventory was off!  Since the system for each store was independent of the other, neither system “knew” of the movement of goods to the other location.  So, you had a system where goods were received properly, but not properly relieved at the location shipping the goods!

My developer friend thought it best to stay away from this potentially difficult situation, and suggested that the prospect find a developer who was willing to do the work as desired.  The moral of this story?  Not all business processes deserve to be duplicated.  In this case, the issue was not the computer application that was the problem, but rather how it was being used. 

The story also illustrates very well one of the situations that I always try to become aware of at a clients site when I’m there - “What are they doing manually that could easily be in an application?  Why isn’t it?”  The manual packing list is in my book a BIG red flag!  It signals stop, look, and be cautious. 

P.S.  My friend later found out that this company’s “new” inventory system didn’t work any better - at least until the business process was changed.

Beta Testing - A True Story

On a visit to my chiropractor today I heard a story that I found simply amazing to believe, yet I have to believe it as I was witness to some of the “events” a few years ago - and I remember them well!

It seems that some 6-8 years back my chiropractor (always on the lookout for a “good” deal) was in need of software to handle her business - appointment scheduling, billing - the “usual” stuff for a small practice.  I remember this period as I had been shaking my head on more than one occasion as her employee struggled with the system that was being used.  I also remember her excitement that she had ordered a new system that was really going to be much better than what she was using - and she couldn’t wait until it got installed so that she could address some of the “issues” she’d had with her existing system.

Well, making a long story short, let’s just say that it was a LONG time before improvements were noted by this loyal patient of hers.  She struggled seemingly at every turn - reports didn’t work properly, things didn’t balance - just an apparently endless array of “issues” with this new system that was supposed to solve so many of her problems.  “User friendly” was not how she described her new system at the time.

Interestingly enough, today after I commented about “…good thing your computer system is user friendly…”  (her new office person was struggling with some entry is what prompted my remark) — she asked me if I remembered all the problems she used to have with the system?  (I acknowledged that I indeed did!).  At that point in time she told me “…I really didn’t understand what being a beta tester really meant!  They gave me deep discounts!…”

Indeed they should have given her the software for free from my perspective — her beta testing was more like an alpha site - only she was running live!  I chose not to ask her if she would buy into a beta testing again.

However, what I took away from this today was that if deeply discounted pricing is provided to a customer in return for being a beta test site — the developer had better convey VERY clearly to the customer just what it means to be a beta test site for them.  It seems that in this case the expectations were not clear - the result appears to have been that the 5 years of high employee turnover, retraining, and resulting frustrations and inefficiencies probably cost a great deal more than paying for a proven product would have been.

Of course, I could be wrong!