We are a software company building, selling and supporting our product RecFind 6 as an information management system and enterprise content management system. We have an in-house support department (we don’t outsource anything) and thousands of customers that contact it with questions and reports of problems they are having.

However, like I suspect happens at most software vendors, it is often very difficult for my support people to initially diagnose the real problem. Obviously, if there is an error message then it is easier to resolve but in most cases there is no error message, just an explanation of what a user thinks is the product not working properly.

If we can connect in to the user’s workstation using GoToAssist then we can usually ‘see’ firsthand what the problem is and then help the customer. However, this is not always possible and in a lot of cases my people are working ‘blind’ via phone or email and the only recourse is a question and answer dialog until we get to the point where we can define what the user thinks is going wrong and we can get the history of the problem. That is “When did it start to happen? What changed? Does it happen with everyone or just some users?” Etc., etc.

My people are pretty good at this process but even they get caught occasionally when the customer describes what he/she thinks the solution is rather than what the problem is. This usually takes the form of the customers telling us the ‘fix’ we need to make to the product to solve his/her ‘problem’. The wise support person will always ask, “What were you trying to do?” Once you can determine what the customer was trying to do, you then understand why they are asking for the particular ‘fix’. In most cases, the real problem is that the customer isn’t using the right functionality and once shown how to use the right functionality the need for a ‘fix’ goes away.

Problems also arise when my support people start mistakenly addressing the symptoms instead of the problem. In all fairness, it is often hard to differentiate the two but you can’t fix a problem by addressing the symptoms; you have to go back further and first define and then fix the root problem. Once the root problem is fixed the symptoms magically disappear.

For example, a customer reports multiple documents being created with the same auto number (i.e., duplicate numbers) as a problem. This isn’t really the problem though that is how the customer sees it. It is in fact a symptom and a clue to the identification of the real problem. In the above example, the root problem will be either an auto-number algorithm not working properly or an auto-number configuration with a flawed design. The former is what we call a ‘bug’ and the latter is what we call ‘finger trouble’; the configured auto number configuration was working precisely as designed but not as the customer intended.

Bugs we fix in code but finger trouble we fix by first clearly understanding what the customer wants to achieve and then by helping them to configure the functionality so its works as expected.

All experienced support people get to know the difference between:

What the customer thinks is the solution versus the problem; and

The symptoms versus the problem.

In my experience these are the two most common challenges faced when handling support calls. Recognizing both as early as possible is critical to achieving a speedy resolution and minimizing frustration. Not recognizing both as early as possible leads to longer resolution times and unhappy customers.

If we extend our support experience to real life we realize that these same two challenges face us in everyday life and in all of our social interactions. It why we often argue at cross-purposes; each party seeing the problem differently because of different perceptions of what the real problem is.

The challenges of misunderstanding are also often harder to overcome in real life because unlike a support call which has form and structure, our social interactions are mostly unstructured and opportunistic. We don’t start with a problem, we start with a casual dialog and don’t realize we are about to enter a conflict zone until it sneaks up upon us.

So if you find yourself in an argument please take pause and take the time to ask yourself and the other party, “Just what is it exactly we are arguing about?”  Which upon reflection, is exactly how we should handle each and every support call.

If we take the time to properly define the real problem we would spend far less time arguing and making people unhappy and far more time enjoying the company of our customers and friends. It is a no-brainer really, who wants to go through life in constant conflict?

For my part, I will just continue to ask to ask, “Before I address your request for a change would you mind please explaining what you were you actually trying to achieve; can you please show me?” And “What were you doing when you first saw that problem? Please start from the beginning and walk me through the process.” These two questions have worked for me for a very long time and I certainly hope that they work for you.

When we were all learning about what used to be called Data Processing we also learned about the hierarchy or transformation of information. That is, “data to information to knowledge to wisdom.”

Unfortunately, as information management is part of what we call the Information Technology industry (IT) we as a group are never satisfied with simple self-explanatory terms. Because of this age-old flaw we continue to invent and hype new terms like Knowledge Management and Enterprise Content Management most of which are so vague and ill-defined as to be virtually meaningless but nevertheless, provide great scope for marketing hype and consultants’ income.

Because of the ongoing creation of new terminology and the accompanying acronyms we have managed to confuse almost everyone. Personally I have always favoured the term ‘information management’ because it tells it like it is and it needs little further explanation. In the parlance of the common man it is an “old un, but a good un.”

The thing I most disliked about the muddy knowledge management term was the claim that computers and software could produce knowledge. That may well come in the age of cyborgs and true artificial intelligence but I haven’t seen it yet. At best, computers and software produce information which human beings can convert to knowledge via a unique human cognitive process.

I am fortunate in that I have been designing and programming information management solutions for a very long time so I have witnessed first-hand the enormous improvements in technology and tools that have occurred over time. Basically this means I am able to design and build an infinitely better information management solution today that I could have twenty-nine years ago when I started this business.  For example, the current product RecFind 6 is a much better, more flexible, more feature rich and more scalable product than the previous K1 product and it in turn was an infinitely better product than the previous one called RecFind 5.

One of the main factors in them being better products than their predecessors is that each time we started afresh with the latest technology; we didn’t build on the old product, we discarded it completely and started anew. As a general rule of thumb I believe that software developers need to do this around a five year cycle. Going past the five year life cycle inevitably means you end up compromising the design because of the need to support old technology. You are carrying ‘baggage’ and it is synonymous with trying to run the marathon with a hundred pound (45 Kg) backpack.

I recently re-read an old 1995 white paper I wrote on the future of information management software which I titled “Document Management, Records Management, Image Management Workflow Management...What? – The I.D.E.A”. I realised after reading this old paper that it is only now that I am getting close to achieving my lofty ambitions as espoused in the early paper. It is only now that I have access to the technology required to achieve my design ambitions. In fact I now believe that despite its 1995 heritage this is a paper every aspiring information management solution creator should reference because we are all still trying to achieve the ideal ‘It Does Everything Application’ (but remember that it was my I.D.E.A. first).

Of course, if you are involved in software development then you realise that your job is never done. There are always new features to add and there are always new releases of products like Windows and SQL server to test and certify against and there are always new releases of development tools like Visual Studio and HTML5 to learn and start using.

You also realise that software development is probably the dumbest business in the world to be part of with the exception of drug development, the only other business I can think of which has a longer timeframe between beginning R&D and earning a dollar. We typically spend millions of dollars and two to three years to bring a brand new product to market. Luckily, we still have the existing product to sell and fund the R&D. Start-ups however, don’t have this option and must rely on mortgaging the house or generous friends and relatives or venture capital companies to fund the initial development cycle.

Whatever the source of funding, from my experience it takes a brave man or woman to enter into a process where the first few years are all cost and no revenue. You have to believe in your vision, your dream and you have to be prepared for hard times and compromises and failed partnerships. Software development is not for the faint hearted.

When I wrote that white paper on the I.D.E.A. (the It Does Every Thing Application or, my ‘idea’ or vision at that time) I really thought that I was going to build it in the next few years, I didn’t think it would take another fifteen years. Of course, I am now working on the next release of RecFind so it is actually more than fifteen years.

Happily, I now market RecFind 6 as an information management solution because information management is definitely back in vogue. Hopefully, everyone understands what it means. If they don’t, I guess that I will just have to write more white papers and Blogs.

It was a long time ago that we all realized that emails were about eighty-percent plus of business correspondence and little has changed today. Hopefully, we also realised that most of us weren’t managing emails and that this left a potentially lethal compliance and legal hole to plug.

I wrote some white papers on the need to manage emails back in 2004 and 2005 (“The need to manage emails” and “Six reasons why organizations don’t manage emails effectively”) and when I review them today they are just as relevant as they were eight years ago. That is to say, despite the plethora of email management tools now available most organizations I deal with still do not manage their emails effectively or completely.

As an recent example  we had an inquiry from the records manager at a US law firm who said she needed an email management solution but it had to be a ‘manual’ one where each worker would decide if and when and how to capture and save important emails into the records management system.  She went on to state emphatically that under no circumstances would she consider any kind of automatic email management solution.

This is the most common request we get. Luckily, we have several ways to capture and manage emails including a ‘manual’ one as requested as well as a fully automatic one called GEM that analyses all incoming and outgoing emails according to business rules and then automatically captures and classifies them within our electronic records and document management system RecFind 6.

We have to provide multiple options because that is what the market demands but it is common sense that any manual system cannot be a complete solution. That is, if you leave it up to the discretion of the operator to decide which emails to capture and how to capture them then you will inevitably have an incomplete and inconsistent solution.  Worse still, you will have no safeguards against fraudulent or dishonest behaviour.

Human beings are, by definition, ‘human’ and not perfect. We are by nature inconsistent in our behaviour on a day to day basis. We also forget things and sometimes make mistakes. We are not robots or cyborgs and consistent, perfect behaviour all controlled by Asimov’s three laws of robotics is a long, long way off for most of us.

This means dear reader that we cannot be trusted to always analyse, capture and classify emails in a one-hundred percent consistent manner. Our excuse is that we are in fact, just human.

The problem is exacerbated when we have hundreds or even thousands of inconsistent humans (your staff) all being relied upon to behave in an entirely uniform and consistent manner. It is in fact ludicrous to expect entirely uniform and consistent behaviour from your staff and it is bad practice and just plain foolish to roll out an email management system based on this false premise. It will never meet expectations. It will never plug all the compliance and legal holes and you will remain exposed no matter how much money you throw at the problem (e.g., training, training and re-training).

The only complete solution is one based on a fully-automatic model whereby all incoming and outgoing emails are analysed according to a set of business rules tailored to your specific needs. This is the only way to ensure that nothing gets missed. It is the only way to ensure that you are in fact plugging all the compliance and legal holes and removing exposure.

The fully automatic option is also the most cost-effective by a huge margin.

The manual approach requires each and every staff member to spend (waste?) valuable time every single day trying to decide which emails to capture and then actually going through the process time and time again. It also requires some form of a licence per employee or per desktop. This licence has a cost and it also has to be maintained, again at a cost.

The automatic approach doesn’t require the employee to do anything. It also doesn’t require a licence per employee or desktop because the software runs in the background talking directly to your email server. It is what we call a low cost, low impact and asynchronous solution.

The automatic model increases productivity and lowers costs. It therefore provides a complete and entirely consistent email management solution and at a significantly lower cost than any ‘manual’ model. So, why is it so hard to convince records managers to go with the fully automatic solution? This is the million dollar question though in some large organizations, it is a multi-million dollar question.

My response is that you should not be leaving this decision up to the records manager. Emails are the business of all parts of any organization; they don’t just ‘belong’ to the records management department. Emails are an important part of most business processes particularly those involving clients and suppliers and regulators. That is, the most sensitive parts of your business. The duty to manage emails transects all vertical boundaries within any organization. The need is there in accounts and marketing and engineering and in support and in every department.

The decision on how to manage emails should be taken by the CEO or at the very least, the CIO with full cognizance of the risks to the enterprise of not managing emails in a one-hundred percent consistent and complete manner.

In the end email management isn’t in fact about email management, it is about risk management. If you don’t understand that and if you don’t make the necessary decisions at the top of your organization you are bound to suffer the consequences in the future.

Are you going to wait for the first law suit or punitive fine before taking action?

The greatest knowledge-loss disaster I can think of was the destruction of the great library of Alexandria by fire around 642 AD. This was the world’s largest and most complete store of knowledge at the time and it was almost totally destroyed. It would take over a thousand years for mankind to rediscover and regain the knowledge that went up in smoke and to this day we still don’t think we have recovered or re-discovered a lot of what was lost. It was an unmitigated disaster for mankind because nearly all of Alexandria’s records were flammable and most were irreplaceable.

By contrast, we still have far older records from ancient peoples like the Egyptians of five-thousand years ago because they carved their records in stone, a far more durable material.

How durable and protected are your vital records?

I mentioned vital records because disaster recovery is really all about protecting your vital records.  If you are a business a vital record is any record without which your business could not run. For the rest of us a vital record is irreplaceable knowledge or memories. I bet the first thing you grab when fire or flood threatens your home is the family photo album or, in this day and age, the home computer or iPad or backup drive.

In 1996 I presented a paper to the records management society titled “Using technology as a surrogate for managing and capturing vital paper based records.” The technology references are now both quaint and out-of-date but the message is still valid. You need to use the most appropriate technology and processes to protect your vital records.

Interestingly, the challenges today are far greater than they were in 1996 because of the ubiquitous ‘Cloud’.  If you are using Google Docs or Office 365 or even Apple iCloud who do you think is protecting your vital records? Have you heard the term ‘outage’? Would you leave your children with a stranger, especially a stranger who doesn’t even tell you the physical location of your children? A stranger who is liable to say, “Sorry, it appears that your children are missing but under our agreement I accept no liability.” Have you ever read the standard terms and conditions of your Cloud provider? What are your rights if your vital records just disappear? Where are your children right now?

Some challenges are surprisingly no different because we are still producing a large proportion of our vital records in paper. Apart from its major flaws of being highly flammable and subject to water damage paper is in fact an excellent medium for the long term preservation of vital records because we don’t need technology to read it; we may say paper is technology agnostic.

By contrast, all forms of electronic or optical storage are strictly technology dependent. What good is that ten year old DAT tape if you no longer have the Pentium compute, SCSI card, cable and Windows 95 drivers to read it? Have you moved your vital records to new technology lately?

And now to the old bugbear (a persistent problem or source of annoyance), a backup is not disaster recovery. If your IT manager tells you that you are OK because he takes backups you should smack him with your heaviest notebook, (not the iPad, the iPad is too light and definitely not with the Samsung tablet, it is too fragile).

I have written about what disaster recovery really involves and described our disaster recovery services so I won’t repeat it here, I have just provided the link so you can read at your leisure.

Suffice to say, the objective of any disaster recovery process is to ensure that you can keep running your business or life with only a minimal disruption regardless of the type or scale of the disaster.

I am willing to bet that ninety-percent of homes and businesses are unprepared and cannot in any way guarantee that they could continue to run their business or home after a major disaster.

We don’t need to look as far back as 642 AD and the Alexandria Library fire for pertinent examples. How about the tsunami in Japan in 2011? Over 200,000 homes totally destroyed and countless business premises wiped from the face of the earth. Tsunamis, earthquakes, floods, fire and wars are all very real dangers no matter where you live.

However, it isn’t just natural disasters you need to be wary of. A recent study published by EMC Corporation offers a look at how companies in Japan and Asia Pacific deal with disaster recovery. According to the study, the top three causes of data loss and downtime are hardware failure (60%), data corruption (47%), and loss of power (44%).

The study also goes on to analyse how companies are managing backups and concludes, “For all the differences inherent to how countries in the Asia Pacific region deal with their data, there is at least one similarity with the rest of the world: Companies are faced with an increasing amount of data to move within the same backup windows. Many businesses in the region, though, still rely on tape backup systems (38%) or CD-ROMs (38%). On this front, the study found that many businesses (53%) have plans to migrate from tape to a faster medium in order to improve the efficiencies of their data backup and recovery.”

It concludes by estimating where backups are actually stored, “The predominant response is to store offsite data at another company-owned location within the same country (58%), which is followed by at a “third-party site” within the same country.”

I certainly wouldn’t be relying on tape as my only recovery medium and neither would I be relying on data and systems stored at the same site or at an employee’s house. Duplication and separation are the two key principles together with proven and regularly tested processes.

I recently spoke to an IT manager who wasn’t sure what his backup (we didn’t get to disaster recovery) processes were. That was bad enough but when he found out it seemed that they took a full backup once a month and then incremental backups every day and he had not tested the recovery process in years. I sincerely hope that he has somewhere to run and hide when and if his company ever suffers a disaster.

In a nutshell, disaster recovery is all about being able to get up and running again in as short a time as possible even if your building burns to the ground. That in fact is the acid test of any disaster recovery plan. That is, ask your IT manager, “If this building burns down Thursday explain to me how we will be up and operating again on Friday morning.”

If his answer doesn’t fill you with confidence then you do not have a disaster recovery plan.

Twenty years ago our main way of competing for business was to respond to Request For Quotes (RFQ) and Request For Proposals (RFP). Our sales people and technical people spend months on end laboriously responding to detailed questionnaires and spread sheets with only a small chance of winning because of the number of vendors invited to respond. Luckily, this is no longer the main way we compete for business and we now complete only a fraction of the RFQ/RFPs we used to; much to the relief of my hard working sales and pre-sales staff.

Now we only respond to RFQs and RFPs if we have prior engagement plus the opportunity for questions and engagement during the process together with a good fit for our software and services (we sell information management software and services). We also heavily qualify every opportunity and the first step is to initially speed read and scan all proposal documents for what we call ‘road blocks’.

Road blocks are contractual conditions, usually mandatory ones, which would automatically disqualify us from responding. Sometimes these are totally unfair, one-sided and non-commercial contractual conditions and sometimes they are mandatory features we don’t have and often, the road block is simply the prescriptive nature of the request document.

By prescriptive I mean that the request document is spelling out in detail exactly how the solution should work down to the level of screen design, architecture and keystrokes. In most cases prescriptive requests are the result of the author’s experience with or preference for another product.

As we produce a ‘shrink-wrapped’ or ‘off-the-shelf’ product, the RecFind 6 suite, we aren’t able to change the way it looks and works and nor can we change the architecture. In almost every case we could solve the business problem but not in the exact way specified by the author. Because our product RecFind 6 is highly configurable and very flexible we can solve almost any information management or business process management problem but in our particular way with our unique architecture and our unique look and feel.

In the old days we may have tried to enter into a dialog with the client to see if our solution, although working differently to the way the author envisioned a solution working, would be acceptable.  The usual answer was, “Why don’t you propose your solution and then we will decide.” Sometimes we did respond and then learned to our chagrin that our response was rejected because it didn’t meet some of the prescriptive requirements. Basically, a big waste of time and money. So, we no longer respond to prescriptive RFQs/RFPs.

But, why is a prescriptive RFQ/RFP a bad thing for the client? Why is it a bad practice to be avoided at all costs?

It is a bad thing because it reduces the client’s options and severely narrows the search for the best solution. In our experience, a prescriptive RFQ/RFQ is simply the result of someone either asking for the product they first thought of someone who is so inflexible that he/she isn’t able to think outside the box and isn’t open to innovative solutions.

The end result of a prescriptive RFP/RFQ is always that the client ends up with a poor choice; with a third best or worse solution to the problem.

The message is very simple. If you want to find the best possible solution don’t tell the vendors what the solution is. Rather tell the vendors what the problem is and give them the opportunity to come up with the most innovative and cost-effective solution possible.  Give them the opportunity to be innovative and creative; don’t take away these so very important options.

Please do yourself, and your organization, a favour. If you want the best possible solution clearly explain what the problem is and then challenge the vendors to come up with their best shot. Prescriptive requirements always deny you the best solution.

Like me I am sure that you have been inundated with ads, articles, white papers and proposals for something called BPM or BPO, Business Process Management, Business Process Outsourcing and Business Process Optimisation.

Do you really understand what it all means?

BPM and BPO certainly aren’t new, there have been many companies offering innovative and often cutting-edge technology solutions for many years. The pioneering days were probably the early 1980’s. One early innovator I can recall (and admired) was Tower Technology because their office was just across from our old offices in Lane Cove.

In the early days BPM was all about imaging and workflow and forms. Vendors like Tower Technology used early version of workflow products like Staffware and a whole assortment of different imaging and forms products to solve customer processing problems. It involved a lot of inventing and a lot of creative genius to make all those disparate products work and actually do what the sales person promised. More often than not the final solution didn’t quite work as promised and it always seemed to cost a lot more than quoted.

Like all new technologies everyone had to go through a learning process and like most new technologies, for many years the promises were far ahead of what was actually delivered.

So, is it any different today? Is BPM a proven, reliable and feature-rich and mature technology?

The answer dear friends is yes and no; just as it was twenty-five or more years ago.

There is a wonderful Latin phrase ‘Caveat Emptor’ which means “Let the buyer beware”. Caveat Emptor applies just as much today as it did in the early days because despite the enormous technological progress we have all witnessed and experienced we are still pushing the envelope. We are still being asked to do things the current software and hardware can’t quite yet handle. The behind the scenes technicians are still trying to make the product do what the sales person promised in good faith (we hope) because he didn’t really understand his product set.

Caveat Emptor means it is up to the buyer to evaluate the offering and decide if it can do the job. Of course, if the vendor lies or makes blatant false claims then Caveat Emptor no longer applies and you can hit them with a lawsuit.  However, in reality it is rarely as black and white as that. The technology is complex and the proposals and explanations are full of proprietary terminology, ambiguities, acronyms and weaselly words.

Like most agreements in life you shouldn’t enter into a BPM contract unless you know exactly what you are getting into. This is especially true with BPM or BPO because you are talking about handing over part of your core business processes to someone else to ‘improve’. If you don’t understand what is being proposed then please hire someone who does; I guarantee it will be worth the investment. This is especially true if you are outsourcing customer or supplier facing processes like accounts payable and accounts receivable. Better to spend a little more up front than suffer cost overruns, failed processes and an inbox full of complaints.

My advice is to always begin with some form of a consultancy to ‘examine’ your processes and produce a report containing conclusions and recommendations. The vendor may (should) offer this as part of its sales process and it may be free or it may be chargeable.  Personally, I believe in the old adage that you get what you pay for so I would prefer to pay to have a qualified and experienced professional consultant do the study. The advantage of paying for the study is that you then ‘own’ the report and can then legally provide it to other vendors to obtain competitive quotes.

You should also have a pretty good idea of what the current processing is costing you in both direct and indirect costs (e.g., lost sales, dissatisfied customers, unhappy staff, etc.) before beginning the evaluation exercise. Otherwise, how are you going to be able to judge the added value of the vendor’s proposal?

In my experience the most common set of processes to be ‘outsourced’ are those to do with accounts payable processing. This is the automation of all processes beginning with your purchase order (and its line items), the delivery docket (proof of receipt), invoices (and line items) and statements. The automation should reconcile invoices to delivery dockets and purchase orders and should throw up any discrepancies such as items invoiced but not delivered, variations in price, etc. Vendors will usually propose what is commonly called an automatic matching engine; the software that reads all the documents and does its best to make sure you only pay for delivered goods that are exactly as ordered.

If the vendor’s proposal is to be attractive it must replace your manual processing with an automated model that is faster and more accurate. Ideally, it would also be more cost-effective but even if it is more costly than your manual direct cost estimate it should still solve most of your indirect cost problems like unhappy suppliers and late payment fees.

In essence, there is nothing magical about BPM and BPO; it is all about replacing inefficient manual processes with much more efficient automated ones using clever computer software. The magic, if that is the word to use, is about getting it right. You need to know what the current manual processing is costing you. You need to be absolutely sure that you fully understand the vendor’s proposal and you need to build in metrics so you can accurately evaluate the finished product and clearly determine if it is meeting its stated objectives.

Please don’t enter into negotiations thinking that if it doesn’t work you can just blame the vendor. That would be akin to cutting off your nose to spite your face. Remember Caveat Emptor; success or failure really depends upon how well you do your job as the customer.

We are in the enterprise content management business or more explicitly in the information management business and we provide a range of solutions including contract management, records management, document management, asset management, HR management, policy management, etc. We are a software company that designs and develops its own products. We also develop and provide all the services required to make our products work once installed at the customer’s site.

However, we aren’t in the ‘creating innovative software’ business even though that is what we do; we are really in the ‘selling our innovative software’ business because without sales there would be no business and no products and no services (and no employees).

We have been in business for nearly 30 years and have watched and participated as both technology and practices have evolved over that time. Some changes are easy to see. For example, we no longer product paper marketing collateral, we produce all of our marketing collateral in HTML or PDF form for delivery via our website and email. We also now market to the world via our website and the Internet, not just to our ‘local’ area.

Another major area of change has been the interface between the customer and the vendor. Many companies today no longer provide a human-face interface. Most big companies and government agencies no longer maintain a shopfront; they require you to deal with them via a website. Some don’t even allow a phone call or email; your only contact is via a web form.

Sometimes the website interface works but mostly it is a bit hit and miss and a very frustrating experience as the website fails or doesn’t offer the option you need. My pet hate is being forced to fill in a web form and then never hearing back from the vendor. Support is often non-existent or very expensive. From my viewpoint, a major failing of the modern paradigm is that I more often than not cannot get the information I need to evaluate a product from the website. This is when I try to find a way to ask them to please have a sales person contact me as I need to know more about their product or service.

I look forward to a sales person contacting me because I know what I want and I know what questions I need answers to. However, the sad truth is that I am rarely contacted by a sales person (and I refuse to speak to anyone from an Indian call centre because I have no wish to waste my time). However, experience with my customers and prospects tells me that not everyone is as enamoured with sales people as I am. In fact, many of the people I have contact with are very nervous of sales people, some are even afraid of them.

Unfortunately for me, we aren’t in a business where we can sell our products and services via a webpage and cart checkout. We need to understand the customer’s business needs before we can provide a solution so we need to employ high quality sales people who are business savvy and really understand business processes. It is not until I know enough to be able to restate the customer’s requirement in detail that I am in a position to make a sale. Conversely, the customer isn’t going to buy anything from me until he/she is absolutely sure I understand the problem and can articulate the solution.

So, in my industry I rely on a human interface and that usually means a sales person. But, do I really need a sales person and do my customers and prospective customers really want to speak to a sales person? Is there a more modern alternative? Please trust me when I say I have pondered this question many, many times.

Those in my business (selling information management solutions) will know how hard it is to find a good sales person and how hard it is to keep them. The good ones are less than ten-percent of the available pool and even after you hire them they are still besieged by offers from recruiters. Finding and retaining good sales people is in my opinion the biggest problem facing all the companies in our industry. They are also the most expensive of human resources and after paying a recruitment fee and a big salary you are then faced with the 80:20 rule; that is, 20% of the sales force produces 80% of your revenues.

Believe me, if I could find a way to meet my sales targets without expensive and difficult to manage sales people I would. However, as our solutions are all about adapting our technology to the customer’s often very complex business processes this is not a solution that can be sold via a website or automated questionnaire; it requires a great deal of skill and experience.

So for now dear customer, please deal with my sales person; he or she is your best chance of solving that vexing problem that is costing your organization money and productivity. All you really need to do is be very clear about what you want and very focussed on the questions you want answered. There is nothing to be afraid of because if you do your homework you will quickly be able to differentiate the good sales person from the bad sales person and then take the appropriate action. I never deal with a bad sales person and nor should you. I also really enjoy dealing with a professional sales person who knows his/her business and knows how to research and qualify my needs.

A good sales person uses my time wisely and saves me money. A bad sales person doesn’t get the chance to waste my time. This should be your approach too; be happy and willing to deal with a sales person but only if he/she is a professional and can add value to your business.

Sales people call this the value proposition. More explicitly; if the sales person is not able to articulate a value proposition to the customer that resonates with the customer then he/she shouldn’t be there. Look for the value proposition; if it isn’t apparent, close the meeting. Make each and every sales person understand, if they aren’t able to articulate a value proposition for your business then there is no point in continuing the conversation.

Dealing with a sales person isn’t difficult; it is all up to you to know what you want (the value proposition) and what questions to ask. Do your preparation and you will never fear a sales person again.

We all know about the success of tablets both in the home and enterprise. It is one of those overnight success stories that took around ten years or more. The real breakthrough was the iPad and it is still the market leader and the trend setter; the one that all others try to emulate.

The fact that many tablets failed before the advent of the iPad and that many more have failed since is testimony to the uniqueness of the iPad, to its creators getting it ‘just right’ and to Apple being the premier marketing organization of our time. The fact that the iPad outsells all of its competitors despite having fewer features is due to the understated brilliance of its design and Apple’s overachieving marketing department.

Despite their best efforts, huge budgets and amazing technology, both HP and Samsung have failed to topple the iPad. Now we have Microsoft with its vapourware Surface about to attempt the same task; good luck Microsoft but for now I am placing my bets on Apple to win this contest. Then again, maybe Google’s coming Nexus 7 tablet will be the deal-breaker?

I own an iPad 2 and a Samsung Galaxy Tab and despite the Samsung having more capabilities I would choose the iPad every time and it is the one I carry around with me despite the missing USB port and sandboxed file system. It wins because it is just ‘right’; it is super easy to configure and use and just does what it is supposed to do without irritating bugs, idiosyncrasies or pain. This is due to the maturity and robustness of iOS. The Samsung on the other hand suffers because of the immaturity and instability of the Android operating system; I feel sorry for Samsung because they have done a good job with the hardware only to be let down by the software. Google, are you listening?

However, the iPad has not replaced my smart-phone, desktop computer or laptop and it isn’t likely to until it matures and grows a lot past both the iPad 2 and the stupidly named New iPad (I guess even Apple can’t get it right every time). The reasons are pretty self-evident:

·         It can’t run all the applications I need

·         Its screen is too small for some jobs

·         It is too big to replace my phone and doesn’t work as a phone

·         It has limited connectivity

·         The sandboxed file system is next to useless when I need to transfer data between applications. In fact, you may as well say it doesn’t have a file system.

·         It can’t be networked (connecting via Wi-Fi is not the same as networking; for enterprise use it needs to connect to Active Directory)

So even though the iPad is the ‘best’ it is still light years away from being the single device I could use in my business. This means it is an ‘additional’ device, not a replacement. I still need my smartphone and my desktop and my laptop and this is just too silly for words because all of these devices can receive and send emails, all of these devices can receive and send messages and all of these devices allow me to type and create and read documents, etc., etc. There is an enormous overlap of functionality, a duplication of functionality which is more than silly; it is stupid; why am I receiving the same email on four devices?

You may ask then why do I have four devices? The simple answer is that each one of them is more appropriate in a given situation. For example, at my desk there is nothing better than the desktop, in the airport just before my flight the smart-phone is best, in my hotel room the night before the meeting the laptop is perfect and while having coffee just before a meeting the iPad is the ideal device. However, none of them are appropriate for all the things I do and all the places I go. This is the major dilemma of the modern office worker.

I do not want to work with four devices, I do not want to carry three devices (phone, laptop and iPad) on business trips and I think it is just plain dumb to have to send and receive the same email on four different devices. We need a single solution and everyone in the industry tells me it will be a tablet but I have yet to see a tablet that fits the bill or even comes close.

I want a screen big enough to view and compose important documents or presentations. I want a real keyboard. I want connectivity, I want security. I want to be able to run all the applications I need to run my business. I also want lightness and small size and a phone. I am not Robinson Crusoe; every business person I speak to wants the same capabilities and until tablets can come close to satisfying my needs they will never be the single device business people need.

To all the tablet makers out there, Apple, Samsung, HP, Lenovo, Google, and the like; please, please listen to your customers and produce a new generation device that will simplify our lives and reduce our load. Please give me a single device that does everything.

I am told again and again by the popular press and unpopular politicians (is there any other kind?) that we in Australia have a skills shortage. I agree but with a strong proviso; we have a skills shortage but we don’t have an applicant shortage.

We have been advertising for a support specialist (we actually hired one), software sales people and experienced .NET programmers. We are trying to grow and expand and the lack of good quality staff is the major impediment.

I have placed the ads on SEEK, on LinkedIn and am also using the services of several recruiting firms so we at least have a wide coverage.

The initial problem is that the majority of candidates either don’t read the ad or don’t understand the ad or just plain ignore the requirements in the ad. Please note that we are talking about very clear and unambiguous requirements like:

• Please note that applications without a personalised cover letter articulating why you have the right attributes to be successful in this role will not be considered.
• Previous applicants need not apply and all applicants must be Australian citizens or legal residents.

We also list skill or experience prerequisites which most applicants also either misread, don’t understand or just plain ignore. Again, we list them very clearly as follows:

• You will have 3+ years’ experience programming in .NET (preferably VB)
• You will have 3+ years’ experience working with SQL Server (2005/2008)
• Experience with the most of the following: .NET 3.5, ASP, AJAX, LINQ, Threading, Web Services, JavaScript, IIS

Of course, as you may guess, the next biggest problem is that the claims in the resume/curriculum vitae simply do not match reality. We for example now test all programing applicants and less than ten-percent of the people we interview come even close to passing a simple programming test. For example, applicants who claim to be certified and experts in topics like SQL are unable to answer even the most elementary questions about SQL.

The funniest (strangest?) thing is that invariably, when we ask them after the test why they rated themselves as a 9 out of 10 in SQL but don’t seem to know anything about SQL, they still rate themselves as a 9 out of ten. It is at that point that you realise there is no point in continuing the interview.

We have now changed our approach and in order not to waste time we conduct a simple phone interview with applicants before deciding to bring them in. As you would guess, most never get past the simple phone interview.

In a nutshell, the ‘norm’ appears to be that applicants ignore the requirements in the ad and also lie about their experience and skills in their resumes. Sometimes the lies are so obvious it is funny. For example, we always check applicants in social networking sites like LinkedIn. The differences between the public profile on LinkedIn and the resume we receive are often amazing; different companies, different titles, different dates of employment. It reminds me of that old question, “Are you lying now or were you lying then?” As soon as we see big differences between the LinkedIn profile and the resume we lose interest.

Recruiters are also in the main, simple hopeless. They want a huge fee for placing an ad on SEEK and sending you a resume. Most don’t interview candidates or screen them in any way or even check references and none take any responsibility. Most beg for an appointment so they can really understand your requirements and then totally ignore them after taking up an hour or two of your valuable time.

However, even after the ‘information-gathering’ appointment and us supplying the recruiter with detailed written requirements the first few resumes we receive are usually nothing like what we asked for. Invariably, when I summon up enough patience to call them as ask why they wasted my time sending me resumes that are nothing like our requirements the answer is usually, “Oh, I thought you might be interested in this one.” Luckily I am not in the habit of gnashing my teeth or I would have none left.

Let me translate that response, “I am a recruiter on a low base salary and high commission and I can’t pay the mortgage on my girlfriend’s flat unless you take one of my candidates so I am going to send you whatever I have in the hope I can earn some commission.”

Then there is the question of literacy and professionalism or the lack thereof. To be fair, a lot of our programming candidates (most actually) are new to this country and English isn’t their first language so we expect to see some unusual phrasing and sentence construction in the resume. Most programming candidates however, despite language difficulties, do a pretty good job in the resume. It is only when we do a phone interview that we discover the candidate’s real grasp of English and unfortunately, for most new arrivals, I can’t employ them in my development environment if they can’t communicate technical matters and nuances at an expert level. It isn’t my job to teach them English.

The real surprise, or shock, is the number of ‘sales professionals’ who can’t spell or construct a sentence or even format a document despite English being their first language. I need these people to be able to construct well-written, cohesive selling proposals for my clients and if the resume is an indicator of their abilities then they fail abysmally.

More importantly, you have to ask if this is the effort they put into an extremely important document selling themselves what hope do you have of getting a well-written and totally professional proposal for your customers? We simply reject any sales candidate with a poorly written and formatted resume.

It is strange that most resumes from programming candidates who are also recent arrivals to our country are generally much better written that the resumes of so-called experienced sales professionals who were schooled here. There is obviously something seriously amiss with our education system and the standards of the companies they worked for previously.

The sad bottom line is that out of one hundred applicants we will only want to interview ten and out of those ten only one will prove to be suitable. I would like to say that this is a one-percent success rate but it isn’t because the one good candidate always gets several offers and the chance of actually hiring them is no better than one in two. This give me a success rate of at best, one in two-hundred.

My theory is that there is a major mismatch between available candidates and the available positions with a lot of poorly qualified people in the market and very few highly qualified people in the market. So we definitely have an ‘available’ skills shortage. It is an awful thing to say but I can only see this situation getting worse in the next few years as our economy slows down because the few good people are going to stay where they are and wait out the bad times.

Where are those cyborgs I see in movies like Prometheus; how much do I have to pay and how long do we have to wait?

When we see terms like Web-Client or Thin-Client it means an application that runs in a browser like IE, Firefox or Chrome. The alternative is a Fat-Client usually meaning an application that runs within Windows (XP, Vista, Windows 7) on your desktop or notebook.

Neither the Web-Client nor the Fat-Client are new concepts having been around for many years but both have changed and improved over time as they have employed new technologies. Most Fat-Client applications today for instance are based on the 2008 or 2010 Microsoft .NET platform and require the .NET Framework to be installed on the workstation or notebook. Most Web-Client applications today utilize advanced multi-tier tools like those from Ajax plus more advanced toolsets from development systems like Visual Studio 2010 and provide a far better user interface and experience than their ancestors did.

In a nutshell, in the old days say fifteen years ago, Web-Clients were clunky, two-tier and had terrible user interfaces, nowhere near as good as their Fat-Client counterparts. Today, using the advanced development tools available, it is possible to build a Web-Client that looks and works little different from a Fat-Client. Much better development tools have made it much easier for programmers to build nicer looking, more functional and easier to use Web-Client user interfaces for applications.

It still isn’t all roses because not all browsers are equal and different browsers (e.g., IE versus Safari) and different versions of browsers (e.g., IE 6, 7, 8 and 9) force the programmer to have to write extra code to handle the differences. The advent of HTML5 will soon introduce another layer of differences and difficulty as vendors deploy different or non-standard versions of the HTML5 standard. However, this has been the case for as long as I can remember (there have always been differences in the HTML deployed by different vendors) and us programmers are used to it by now.

It used to be that because of the limited development tools available to code Web-Client interfaces that the typical Web-Client had far less functionality than its Fat-Client equivalent. Whereas it is still easier to implement complex functionality in a .NET Fat-Client than a Web-Client, it is possible to provide equivalent functionality in a Web-Client; it just needs smarter programmers, more work and a few extra tools.

So if your application vendor offers you the choice of a Fat or Web user interface, which should you choose and why?

You first need to ask a couple of very important questions:

·         Does the Web-Client have equivalent functionality to the Fat-Client? and

·         Is the Web-Client operating system and browser independent?

Let’s address the second question first because it is the most important. You can for example, write a Web-Client user interface that it not operating system independent and that in fact is ‘locked’ into a particular operating system like Windows and a particular browser like IE8. Most Silverlight Web-Client applications for instance require that the .NET Framework be installed on the local workstation or notebook. As the .NET Framework only works on Microsoft Windows systems it means you can’t run your Web-Client on other systems such as Linux, Mac OS, iOS or Android.

It also means that your IT department has to install and maintain software on each and every workstation or notebook that needs to run the application. This is the big problem because the cost of installing and maintaining software on each and every desktop and notebook is enormous.

Ideally, the Web-Client will be operating system independent and will support most of the latest versions of the most popular browsers. Expecting the Web-Client to support old versions of browsers is an unreasonable expectation.

If the Web-Client is operating system independent and has the same functionality as the Fat-Client then your decision is a foregone conclusion; go with the Web-Client and save on the installation and ongoing maintenance costs that would apply to the Fat-Client but not to the Web-Client.

If the Web-Client has a subset of the functionality of the Fat-Client you then need to compare the functionality offered to the needs of different classes of your users. It may not suit your systems administrator but will it suit inquiry users who just need to be able to browse, search, view and print? Will it also suit the middle-class of users who need to be able to add, modify and delete records but not perform administrative tasks like designing reports and building workflow templates?

It is important to have as many of your users as possible using the Web-Client because not only will this approach reduce your IT costs it will provide extra benefits for users who travel and operate from remote and poorly serviced locations not to mention those who work from home. After all, all that is needed is a computer (or tablet or smart-phone) and a secure Internet connection.  

Obviously, as a Web-Client runs from a Web Server your IT people need to ensure that it is secure and for example, operates as a secure and encrypted HTTPS website rather than as an insecure HTTP website. All traffic from public sites needs to be encrypted both ways as a minimum security requirement.

The other major benefit of the Web-Client is that it protects you from differences in operating systems, e.g., Windows XP versus Windows 7 or even Windows 8. A Web-Client runs in the browser, not in Windows so it is much less affected by fundamental changes in an operating system than a Fat-Client application which has to be re-compiled and re-certified against every change. Importantly, you are not locked in to a particular operating system or version of an operating system.

I expect most application vendors to be moving their customers to a Web-Client end user platform; we certainly will be and are investing large amounts of dollars in our RecFind 6 Web-Client interface. There are enormous cost and convenience benefits to our customers in moving from our Fat-Client to our Web-Client user interface and we will be doing everything in our power to encourage this move.