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.]]>
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:
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!)]]>
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.]]>
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!]]>
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.]]>
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!]]>
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.]]>
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:
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.]]>
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.]]>
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!]]>