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.

Over the last 28 years of running this business I have had hundreds of conversations with customers and partners about integration. In most cases when I have tried to obtain more details about exactly what they wanted to integrate to and how I have drawn a blank. It is as if the word ‘integration’ has some magical connotation that everyone is supposed to instantly understand. Being a very logical and technical person, I guess I fail the test because to me it is just a general term that covers a multitude of possibilities.

I have also designed and/or programmed many integrations in my life and I can honestly say that no two have ever been the same. So, assuming that you have a requirement for two or more of the application software products you use to ‘integrate’ how should you go about defining what is required so it is as clear and as unambiguous as possible to your partners, the people you will ask to do the work?

Integration is usually about sharing information and importantly, not duplicating effort (i.e., having to enter data twice) or duplicating information. Having to enter the same information twice into two different systems is just plain dumb and bad design. Maintaining duplicate copies of information is even dumber and dangerous because sooner or later they will get out of step and you will suffer from what we call a loss of data integrity. This is usually why we need integration, to share information and to avoid duplicate effort and duplicate information.

For our purpose let’s assume that we have two application systems, A and B, that we need to be ‘integrated’; both use a SQL database to store data. Applications A and B are produced by different vendors that haven’t worked together before. The first fact to face is that in the normal course of events each vendor is going to want the other vendor to do all the work and each vendor is going to want the other vendor to utilize its proprietary integration methodology (e.g., Application Program Interface (API) or Software Development Kit (SDK)). This is your first big challenge; you need to get the vendors to agree to work together because no matter how this turns out both are going to have to do work and contribute; you can’t complete an integration using just one vendor. That is, the most important thing you have to do is to manage the vendors involved. You can’t just leave it up to them; you need to manage the process from beginning to end.

The second most important thing you have to do is to actually define and document the integration processes as clearly as possible. Here is a checklist to guide you:

1.    Will application A need to access (i.e., read) data held by application B?

2.    Will application B need to access data held by application A?

3.    How often and at what times is access to data required? All the time, once a day, once a week, only when something changes, only when there is new data, every time a new record is added to either application A or B, etc. What are the rules?

4.    How is the data identified? That is, how does application A know what data it needs to access in the application B database? Is it by date or special code or some unique identifier? What are the rules that determine the data to be accessed?

5.    Will application A need to transfer data to application B (i.e. write data to the B database)?

6.    Will application B need to transfer data to application A?

7.    How often and at what times is a transfer of data required? All the time, once a day, one a week, only when something changes, only when there is new data, every time a new record is added to either application A or B, etc. What are the rules?

8.    How is the data identified? That is, how does application A know what data it needs to transfer to the application B database? Is it by date or special code or some unique identifier? What are the rules that determine the data to be transferred?

9.    Does application A have an API or SDK?

10.What is the degree of difficulty (expertise required, time and cost) of programming to this API or SDK? Rate it on a scale of 1 to 10, 10 being the most difficult and most expensive and most time consuming.

11.Does application B have an API or SDK?

12.What is the degree of difficulty (expertise required, time and cost) of programming to this API or SDK? Rate it on a scale of 1 to 10, 10 being the most difficult and most expensive and most time consuming.

13.Is the vendor of application A happy to assign a suitable qualified technical person (not a sales person or pre-sales person) to be the interface?

14.Is the vendor of application B happy to assign a suitable qualified technical person (not a sales person or pre-sales person) to be the interface?

15.What is your timescale? When does it have to be completed? What is the ‘driver’ event?

16.What is your budget? Basically vendors work in a commercial environment and if they do work then they expect to get paid. As a rule, the size of the budget will depend directly upon your management skills and the quality of your integration specification.

Please keep it in mind that there are always multiple ways to integrate; there is never just a single solution. The best way is always the simplest way and this is usually also the lowest cost and quickest way as well as being the lowest cost to maintain. Think about the future, the most complex solution is always the most difficult and most expensive ongoing maintenance solution. Think KISS; minimize your pain and expense.

As a guideline, the vendor with the most work to do is usually the best one to be the ‘lead’ in the integration (remember, both have to be involved or it won’t work). So, if for example vendor A needs to read data from Vendor B’s database and then massage it and utilize it within application A then vendor A is the natural lead. All vendor B has to do is expose its API and provide the required technical assistance to vendor A so vendor A can successfully program to the API.

However, in the end it will usually be the vendor that is the most cooperative and most helpful that you will choose. If you choose the vendor you most trust and work best with to be the lead then you will maximize your chances of completing a successful integration on time and on budget.

Almost every organization, commercial or government, needs a help desk. Help desks support either internal or external ‘customers’. Generally speaking the job of a help desk is to support users who have problems or questions about a product or service.

Help desks may run as either a profit centre or as a cost centre. Normally, help desks supporting internal customers run as cost centres (though maybe with an internal accounting function that attempts to allocate costs to all the departments that utilize the service) and help desks that support external customers run as a profit centre, charging for their services via an annual service fee or incident fee.

The only true measure of the worth of a help desk is the level of customer satisfaction and this is very difficult to measure other than in an anecdotal way. This is because of human nature; customers who are happy with the service rarely take the time to write to the help desk manager and tell him. The same is true of customers who are unhappy with the service; most just make a decision not to use that product or service again. A small number of very disgruntled or even litigious or nuisance customers will complain repeatedly in the most vociferous and rudest manner but will largely be ignored as repeat offenders or the usual suspects.

Trying to get a reading across the customer base by using a survey rarely works either as most won’t respond  and the ones that do respond are usually from the two extremes, the really, really happy customers and the really, really dissatisfied customers. Plus, we all know that a survey is like a poll, if you design the questions in a certain way you can always get the result you first thought of.

Because it is so difficult to obtain enough customer input to be able to rate the help desk we usually fall back on internal metrics. Such things as how many calls did we receive last week? What percentage was closed within 1 day, 2 days, 3 days, etc.? How many are still outstanding after 7 days? How many had to be escalated?

The problem with internal metrics, like police reports on crime statistics, is that they can be manipulated to produce the result you first thought of. Remember that old saying about statistics, "Lies, damned lies, and statistics." A smart and politically savvy help desk manager will always find a way to guild the lily and dress up the stats so he looks good.

So, how do you know if your help desk is working and servicing your customers to the highest standard? There is only one sure way I know of and that is to ring the help desk yourself (incognito I hope, calling up and saying this is the CEO won’t really give you a fair reading about how ordinary customers are treated), or organize a team to call the help desk with a list of known issues and test the responses.

This sounds like it should be a business opportunity; a kind of reverse outsourced help desk, an organization that specializes in testing help desk services. All you have to do is provide them with scripts and a way to measure the effectiveness of the responses. However, I don’t know of any organization that provides this service just as I have never met a CEO lately who seems to know or care what is happening with his help desk service and this is the real problem.

You can always tell the company with the disinterested CEO because there is no way to contact him or her on the website. Companies that aren’t interested in supporting customers always make it almost impossible for a customer to provide feedback. Unfortunately, this ‘we are hiding from you approach’ is becoming the norm as companies remove all contact information from their websites and force customers to endure long waits and rubbish ‘service’ from outsourced support centres.

The executives don’t receive negative feedback because they make it so difficult for customers to reach them. Personally, I think this is a short term and eventually damaging practice as customers tend to have long memories and frustrated, dissatisfied customers will make it their business to tell everyone but the company’s management team (because they aren’t able to contact them) about the rubbish product and the shoddy way they were treated.

Before you ask, let me explain that we do have a support centre but it is not outsourced and we make it as easy as possible for customers to contact us by web form, email, mobile device or toll free number. Please see the links below:

http://www.knowledgeonecorp.com/support/contactinghelpdesk.htm

http://www.knowledgeonecorp.com/contactus/emailus.htm

http://www.knowledgeonecorp.com/contactus/Contact_By_Mobile_App.htm

http://www.knowledgeonecorp.com/support/freeemailsupport.htm

support@knowledgeonecorp.com

Just so you know that we practice what we preach.

Paradoxically, I believe the reason that I get so few complaints (apart from the high standard of our support services) is that I make it so easy for customers to contact me or any other executive in my company.

We also use our own product RecFind 6 as our help desk software so we are able to build in all the alerts, escalations and reporting we need to manage each and every support call to the best of our ability. And finally, my office is just 20 metres or so from the support centre so I make it my business to be in there talking to the support staff at least 4 or 5 times a day.

I am a CEO who is vitally interested in his customers and the quality of support they are receiving and not just for altruistic reasons but for sound business reasons.  Happy customers stay with us and invest in our products and services year after year. It is quite simple really; I invest in my customers so they will invest in my company. It works for us and I wonder why other CEO’s don’t understand this very simple message.

The relationship between a vendor and a customer should be a mutually beneficial partnership; it should not be an destructive, adversarial relationship. In my opinion CEO’s who do not allow their customers to contact them and deliver either a complaint or a compliment are fools and bad business people with a strictly short term view. It is a formula for more short term profit but less long term customers. We opt to spend more money and time on support so we can foster better long term relationships. I think in the ‘old days’ this used to be called service.