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.

We have all heard and read a lot about the Cloud and why we should all be moving that way. I wrote a little about this in a previous post. However, when we look at specific applications like records management we need to think about the human interaction and how that may be affected if we change from an in-house system to a hosted system. That is, how will the move affect your end-users and records management administrator? Ideally, it will make their job easier and take away some pain. If it makes their job harder and adds pain then you should not be doing it even if it saves you money.

We also need to think about the services we may need when we move to the Cloud. That is, will we need new services we don’t have now and will the Cloud vendor offer to perform services, like application maintenance, we currently do in-house?

In general, normal end-user functions should work the same whether we are running off an internal system or a Cloud-based one. This of course will depend upon the functionality of your records management software. Hopefully, there will be no difference to either the functionality or the user interface when you move to the Cloud. For the sake of this post let’s assume that there is a version of your records management system that can run either internally or in the Cloud and that the normal end-user interface is identical or as near-as-such that it doesn’t matter. If the end-user interface is massively different then you face extra cost and disruption because of the need to convert and retrain your users and this would be a reason not to move to the Cloud unless you were planning to change vendors and convert anyway.

Now we need to look at administrator functions, those tasks usually performed by the records management administrator or IT specialist to configure and manage the application.  Either the records management administrator can perform the same tasks using the Cloud version or you need to ask the Cloud vendor to perform some services for you. This will be at a cost so make sure you know what it is beforehand.  There are some administrator functions you will probably be glad to outsource to the Cloud vendor such as maintaining the server and SQL Server and taking and verifying backups.

I would assume that the decision to move a records management application to the Cloud would and should involve the application owner and IT management. The application owner has to be satisfied that the end-user experience will be better or at least equal to that of the in-house installation and IT management needs to be sure that the integrity and security of the Cloud application will at the very least be equal to that of the in-house installation. And finally, the application owner, the records manager, needs to be satisfied that the IT support from the vendor of the Cloud system will be equal to or better than the IT support being received from the in-house or currently out-sourced IT provider.

There is no point in moving to the Cloud if the end-user or administrator experience will deteriorate just as there is no point in moving to the Cloud if the level of IT support falls.

Once you have made the decision to move your records management application to the Cloud you need to plan the cutover in a way that causes minimal disruption to your operation. Ideally, your staff will finish work on the in-house application on Friday evening and begin working on the Cloud version the next Monday morning. You can’t afford to have everyone down for days or weeks while IT specialists struggle to make everything work to your satisfaction. This means you need to test the Cloud system extensively before going live in production. In this business, little or no testing equals little or no success and a great deal of pain and frustration.

If it was me, I would make sure that the move to the Cloud meant improvements in all facets of the operation. I would want to make sure that the Cloud vendor took on the less pleasant, time-consuming and technical tasks like managing and configuring the required IT infrastructure. I would also want them to take on the more bothersome, awkward and technically difficult application administration tasks. Basically, I would want to get rid of all the pain and just enjoy the benefits.

You should plan to ‘outsource’ all the pain to make your life and the life of your staff easier and more pleasant and in doing so, make everyone more productive. It is like paying an expert to do your tax return and getting a bigger refund. The Cloud solution must be presented as a value proposition. It should take away all the non-core activities that suck up your valuable time and allow you and your staff more time to do the core activities in a better and more efficient way; it should allow you to become more productive.

I am a great believer in the Cloud as a means of improving productivity, lowering costs and improving data integrity and security. It is all doable given available facilities and technology but in the end, it is up to you and your negotiations with the Cloud provider.  Stand firm and insist that the end result has to be a better solution in every way; compromise should not be part of the agreement.

Have you ever had to remove files from shelving or cabinets and reallocate them to other spaces because a drawer or shelf is packed tight? Then had to do it again and again?

One of my favourite records managers used to call this the “Squishing” problem.

The squishing problem is inevitable if you start to load files from the beginning of any physical filing system, be it shelving or cabinets and unload file files from random locations as the retention schedule dictates. If you create and file parts (a new folder called part 2, part 3, etc., when the original file folder is full) then the problem is exacerbated. You may well spend a large part of your working life shuffling file folders from location to location; a frustrating and worthless, thankless task. You also get to inhale a lot of toxic paper dust and mites which is not a good thing.

You may not be aware of it but there is a very simple algorithm you can utilize to make sure the squishing problem never happens to you. It is usually referred to as the ‘Terminal Digit’ file numbering system but you may call it whatever you like. The name isn’t important but the operation is.

Importantly, you don’t need to change your file numbering system other than by adding on additional numbers to the end. These additional numbers are the terminal digits.

The number of terminal digits you need depends upon how many file folders you have to manage. Here is a simple guideline:

·         One terminal Digit (0 to 9) = one thousand files

·         Two Terminal Digits (00 to 99) = ten thousand Files

·         Three Terminal Digits (000 to 999) = greater than ten thousand files

Obviously, you also have to have the filing space and appropriate facilities available (e.g., boxes, bays, etc.,) to hold the required number of files for each terminal.

It is called the Terminal Digit system because you first have to separate your available filing space into a number of regular ‘terminals’. Each terminal is identified by a number, e.g., 0, 1, 2, 09, 23, 112, 999, etc.

The new terminal digit is additional and separate from your normal file number. It determines which terminal a file will be stored in. Let’s say your normal file number is of the format YYYY/SSSSSS. That is, the current year plus an automatically incrementing auto number like 2012/000189 then 2012/000190, etc. If we use two terminal digits and divide your available filing space into one hundred terminals (think of it as 100 equally sized filing slots or bays numbered 00 to 99) then your new file number format is YYYY/SSSSSS-99. The two generated file numbers above may now look like 2012/000189-00 and 2012/000190-01.

File folder 2012/000189-00 is filed in terminal number 00 and 2012/000190-01 is filled in terminal number 01. In a nutshell, what we are doing is distributing files evenly across all available filing space. We are not starting at terminal 00 and filling it up and then moving on to terminal 01, then terminal 02 when 01 is full etc. Finding files is even easier because the first part of the file number you look at is the terminal digit. If a file number ends in 89 it will be in terminal 89 in file number order.

The other good news is that when we unload files from the shelves say at end of life or at the point in the lifecycle when they need to sent offsite we will also unload files evenly across all available filing space. If the terminals are actually big enough and if you have calculated everything correctly you should never again suffer from the ‘squishing’ problem and you should never again have to ingest paper dust and mites when tediously shuffling files from location to location.

Obviously, there is a little more to this than sticking a couple of digits on the end of your file number. I assume you are using a computerised records management system so changes have to be made or configured to correctly calculate the now extended file number (including the new terminal digit) and your colour file labels will need to be changed to show the terminal digit in a prominent position.

There is also the question of what to do with your existing squished file store. Ideally you would start from scratch with your new numbering systems and terminals and wait for the old system to disappear as the files age and disappear offsite to Grace or Iron Mountain. That probably won’t be possible so you will have to make decisions based on available resources and budget and come up with the best compromise.

I can’t prove it but I suspect that the terminal digit system has been around since people began filing stuff. It is an elegantly simple solution to an annoying and frustrating problem and involves nothing more complicated than simple arithmetic.

The surprise is that so few organizations actually use it. In twenty-five plus years in this business I don’t think I have seen it in use at more than one to two-percent of the customers I have visited. I have talked about it and recommended it often but the solution seems to end up in the too-hard basket; a shame really, especially for the records management staff charged with the constant shuffling of paper files.

It may be that you have a better solution but just in case you don’t, please humour me and have another look at the terminal digit filing solution. It may just save you an enormous amount of wasted time and make your long-suffering records staff a lot happier and a lot healthier.

We produce a content management system called RecFind 6 that includes several ways to capture, classify and save emails. Like most ECM vendors, we offer a number of alternatives so as to be better able to meet the unique requirements of a variety of clients.

We offer the ‘manual’ version whereby we embed our email client into packages like Outlook and the end user can just click on our RecFind 6 Button from the Outlook toolbar to capture and classify any email.

We also offer a fully automated email management system called GEM that is rule-driven and that automatically analyses, captures and classifies all incoming and outgoing emails.

At the simplest level, an end user can just utilize the standard RecFind 6 client and click on the ‘Add Attachment’ button to capture a saved email from the local file store.

Most of our customers use the RecFind 6 Button because they prefer to have end users decide which emails to capture and because the Button is embedded into Microsoft Office, Adobe Professional, Notes and GroupWise. A much smaller percentage of our customers use GEM even though it is a much better, more complete and less labour intensive solution because there are still many people that just don’t want email to be automatically captured.

This last point is of great interest to me because I find it hard to understand why customers would choose the ‘manual’ RecFind 6 Button, small, smart and fast though it is, over the fully automated and complete solution offered by GEM, especially when GEM is a much lower cost solution for mid-size to large enterprises.

A few years ago in 2005 the Records Management Association of Australia asked me to write a paper on this topic, that is, why don’t organizations make a good job of capturing emails when there is plenty of software out there that can do the job?  I came up with six reasons why organizations don’t manage emails effectively and after re-reading that paper today, they are still valid.

In my experience, the most common protagonists are the records manager and the IT manager.  I don’t think I have ever spoke to a senior executive or application owner who didn’t think GEM was a good idea but I have only ever spoken to a tiny number of records managers who would even contemplate the idea of fully automatic email management. Most IT managers just don’t want all their emails captured.

This is despite the fact that because GEM is rule-driven any competent administrator could write rules to include or exclude any emails they want included or excluded.

Another road block is that old red herring personal emails. In ninety-percent upwards of cases where my customer has decided against GEM this is given as the ‘real’ reason. It is of course rubbish because there are many ways to handle personal emails including an effective email policy and writing GEM rules to enforce that policy. This 2004 paper explains why we need to manage emails and also talks about an effective email policy.

The absolute worst way to mismanage emails is to mandate that end users must select and print them out for the records staff to file in cardboard file folders. This method is entirely appropriate to 1900 except for the fact that we actually didn’t have emails in 1990. It is entirely inappropriate and just plain ineffective, wasteful and stupid in 2012 but, tens of thousands of records managers all around the world still mandate this as the preferred approach.

Is it because they don’t understand the technology or is it because they stubbornly refuse to even consider the technology?

It can’t be budget because the cost of expensive staff having to be part-time records managers is monumental. You would be hard pressed to find a more expensive and less effective solution. So why are we still doing it?

Back to the title of this paper, “How hard can it be?”

The answer is that it is not hard at all and that every ECM vendor has at least one flexible and configurable solution for email management. More so, these solutions have been around for at least the last ten years. So why are we still doing it the hard, ineffective, incomplete and expensive way?

The answer is that it is to do with people and attitudes; with a reluctance to embrace change and a reluctance to embrace a challenge that just might force managers to learn a lot in a short time and extend their capabilities and workload for the period necessary to implement a new generation solution. I guess it comes down to fear and a head in the sand attitude.

I once had a senior records manager tell me he wasn’t going to install any new systems because he was retiring in five years and didn’t want the worry and stress. Is this really why you aren’t managing your emails effectively and completely? Isn’t it time you asked the question of your records and IT managers?

In a previous career with mainframes I spent eight years as a large scale project manager and then a further two years as the international operations manager managing a number of project managers at troubled projects around the world. Those ten years taught me a great deal about what it takes to be a successful project manager and conversely, why some project managers fail.

Notice that I said why some project managers fail, not why some projects fail. It is cause and effect; projects only fail when the project manager fails to do the job required. This particular concept separates good project managers from bad project managers. Good project managers take full responsibility for the success or failure of their projects, bad project managers don’t.

Good project managers are ‘glass-half-full’ people, bad project managers are ‘glass-half-empty’ people. Good project managers are leaders, bad project managers are victims.

So the first piece of advice is to choose your project manager carefully. You want a strong willed, bright and energetic doer, not a facilitator or politician. You want a strong leader, not a careful and political follower; you want Jesus, not the disciples.

The next piece of advice is that you should set quantitative criteria for project success. No ambiguity or motherhood or weaselly words, as the Dragnet cop used to say, “Just the facts Mam.” In my day it was easy, we had to install the new hardware and software, convert from the old system, design and program the new applications and then take the whole system through a 30 day acceptance test with 99% uptime. There was always a contract and the conditions of acceptance were always clearly laid out and assiduously referred to by the customer. We knew what we had to achieve and there was no ambiguity.

Unfortunately, one of the problems with a lot of projects is that the conditions for acceptance and success are not clearly articulated or documented. But, a good project manager will always make sure that the scope and objectives and expected outcomes are clearly defined regardless before accepting the challenge. The bad project manager on the other hand is always happy that there isn’t a clear definition of success because the bad project manager wants to make judging his or her performance as difficult as possible.

I once fired a project manager who told me in three meetings in a row that he had not completed the requested project plan because the project was too complex. Obviously the more complex the project the more its needs a comprehensive project plan otherwise it will be impossible to manage. My failed project manager didn’t want to document the project plan because he didn’t want deadlines and he didn’t want to be judged on how well he was meeting deadlines.

It sounds like an over-simplification but if you want a successful project then choose a successful project manager, one who accepts full responsibility for all outcomes and one who is committed to success.

As part of the interview process, ask them what their philosophy of responsibility is. As an example, here is one I always used.

“Everything that happens is due to me because everything that happens is either due to something I did or something I didn’t do.”

I have never found a good project manager who had a problem with this credo. Bad project managers on the other hand, see it as anathema to their survival strategies. Good project managers accept full responsibility for success or failure, bad project managers do not.

Good project managers also don’t spend all day in an office playing with Excel and Microsoft Project. Nor do they spend all day in meetings or on conference calls. Good project managers integrate themselves into the very bowels of the project and ‘walk-and-talk’ on a daily basis.

Walk and talk refers to the practice of meeting with real workers at all levels of the project, especially end users. Good project managers make the time to talk to end users every day and because of this they know more about what is happening than any senior manager. They are ‘in-touch’ with the project and are constantly aware of changes, problems and successes. Good project managers who practice the walk and talk technique are never surprised in project or management meetings because they always know more than anyone else at the meeting and they always have the very latest information. This is probably why they are such good project managers. If you aren’t prepared to invest at least one hour of your time every day walking and talking to real users then you shouldn’t be a project manager.

Good project managers also always know how to select and manage their team. Because they are natural leaders, management is a natural and comfortable process for them. There is never any doubt in a good project manager’s team about who the leader is and who will make the final decisions and then take responsibility for them. There is no disseminated responsibility. The opposite is always true in a bad project manager’s team with disseminated responsibility and no clear record of who made what decision.

The calibre of the bad project manager’s team is always significantly lower than that of the good project manager’s team. This is because mediocre people always hire mediocre people and a bad project manager is afraid of strong capable staff because he or she finds them threatening. A good project manager on the other hands loves working with strong capable people and revels in the ongoing challenge of managing them. A good project manager is never threatened by strong capable staff, au contraire; he seeks them out because they make it easier for him (or her) to be successful.

There is no magical formula that will ensure a successful project, completed on time and on budget and with all contracted deliverables accepted and signed off. It also doesn’t matter what project management tool you use as long as you do use a project management tool. I don’t particularly like the latest version of Microsoft Project (and that is an understatement) but if required I could use it to manage any project no matter how big and how complex. It isn’t the tool; it is the person that counts.

This is simple advice like my favourite about how to do well on the stock market, “buy low and sell high.” If you want a successful project, always start with a successful project manager. He or she will take care of everything else.

Twenty-eight years ago we released our first records management product, DocFind I.

Twenty-six years ago we released the first version of our iconic records management product RecFind 1.0.

Twenty-five years ago we released our first imaging enabled records management product, ImageFind 1.0.

Thirteen-years ago we shipped our first fully featured Electronic Document and Records Management Solution (EDRMS) with a full complement of records, document, imaging and workflow functionality, RecFind 3.2.

Twenty-five years ago I used to do a lot of trade show and seminar presentations about the coming paperless office yet here we are today with more paper records in existence than I would have ever imagined all those years ago. The fabled paperless office as far away now as it has ever been.

It isn’t because of a lack of functionality to deal with the problem. Most of the other vendors did what we did and produced products merging records, document and imaging functionality many years ago so the functionality to facilitate the paperless office has been around for a very long time. Yet, governments and private companies are still using paper as records and are still using and storing billions of sheets of paper each year. Organizations like Iron Mountain and Crown are rushing to build new warehouses all over the world to store boxes of paper records and there seems to be no end in sight. We are drowning in paper.

In order to understand why we are still storing millions of boxes of paper every year we have to ask ourselves two very important questions:

1. What are we (still) doing we shouldn’t be doing?; and
2. What is it we should be doing that we are (obviously) not doing?

Answering number one is easy; we are still using paper and are using it at a rate many, many times that of twenty-five years ago.

Answering number two is also easy; we are not taking advantage of available technology.

The next and most important question to ask is why? Why are we still using paper and why aren’t we taking advantage of available technology?

I have pondered the above questions for a long time and have discussed them at length with my customers and staff and associates in the industry for many years. Whereas you are likely to get any number of responses from industry experts, I am going to narrow it down to four simple issues.

1. Paper is actually still a great medium for many applications and its convenience, cost and flexibility is hard to beat;
2. Most electronic document management systems on the market today are expensive to buy, difficult and expensive to roll out, difficult to use and difficult to maintain;
3. Most EDRMS implementations fail (albeit over time) because very few organizations budget for or are prepared to pay the huge ongoing cost to retrain workers as software changes or train new workers as staff turns over; and
4. Records management is not a core business activity in most organizations and it is seen as a cost centre, not a profit centre so it gets little senior management attention and little funding.

Basically, in most large organizations senior management is aware of the paper problem but it is not high on their agenda and it is easier to just maintain the status quo; keep packing files into boxes and sending them off to Iron Mountain. It is a lot like the Greek Debt problem, that is, keep ignoring the problem and leave it to someone in the future to solve.

To summarize, management says, “It works and isn’t my major priority so I will leave it for someone else to solve.” Or, applying that time-honoured old maxim, “If it ain’t broke, don’t fix it.”

The reality is that we have to find ways to manage paper. The additional reality is that very few of the ECM/EDRMS software packages on the market today do the job well or even at all. SharePoint 2010 for example is hopeless at managing physical records so don’t even think about paying a consultant hundreds of thousands of dollars to configure it for you to solve the problem.

Luckily for us, and largely because we started developing applications for physical records management back in 1984, we have incorporated a rich subset of physical records management functionality (our legacy if you may) into our latest product suite, RecFind 6.  This means we are one of the few vendors with a product that can easily handle any physical records management requirement.

Also, and this still surprises me, we are receiving more and more inquiries for a product that just does physical records management. To be honest, if anyone had told me twenty-five years ago that I would still be receiving requests for a physical records management product in 2012 I would have laughed at them. Yet, here we are today in a world swimming in paper with organizations all around the world desperately needing to solve a paper records management problem.

Now I am really glad that I insisted that my design teams maintain upwards compatibility through all of our product releases and that they should continue to refine and improve our physical records management capabilities.

I hope I am happily retired in another twenty-five years but just in case I am not, I will set myself a reminder to re-read this post and once again review how far we have progressed in replacing paper records with digital records. With luck, I will be living in a luxury apartment converted from an old Iron Mountain warehouse and there won’t be a sheet or paper or archive box in sight.

What will they do with all those warehouses?

I have written about this many times before (see links below) but our customers continue to ask for advice, usually when being ‘told’ by IT that they will have to use SharePoint as their records management solution.

http://www.knowledgeonecorp.com/news/pdfs/IntegratingWithSharePoint.pdf

http://www.knowledgeonecorp.com/news/pdfs/SharePoint%20-%20A%20Primer.pdf

In the past I have treated the subject softly and leaned over backwards to be kind to SharePoint, after all, who am I to argue with mighty Microsoft? Now however, I am just going to tell it how it is.

• Out of the box RecFind 6 is an infinitely better and lower cost and faster to roll out records management solution than SharePoint 2010.
• You can easily and quickly configure RecFind 6 to meet one hundred-percent of your records management requirements. No matter how much time and money you throw at SharePoint 2010 you will never be able to meet one hundred-percent of your records management requirements.
• Whereas the initial licensing costs of SharePoint 2010 may appear to make it a better financial proposition than RecFind 6, once you start pouring in the money required to get SharePoint to do what RecFind 6 does out of the box the situation reverses very quickly. By the time you finish paying your SharePoint consultants (and you probably never will) you will end up paying at least ten times what you would have paid for RecFind 6.
• Worse, whereas Knowledgeone Corporation does all the maintenance and adds all the new features to RecFind 6 as part of your annual maintenance (ASU),  with SharePoint you have to design, implement, test and fund all the maintenance and improvements to your SharePoint system. This means that the ongoing costs are also around ten times what it would cost to maintain an equivalent RecFind 6 system.

It is important to note that this is just not my opinion. As an example, please refer to the advice given to state government agencies by NSW State Records:

http://futureproof.records.nsw.gov.au/initial-advice-on-implementing-recordkeeping-requirements-in-sharepoint-2010/

Allow me to summarize:

• SharePoint 2010 is a good collaboration & intranet solution but will not apply good records management functionality out of the box.
• It will take a significant investment of time, money and strategy to build an effective EDRMS with SharePoint 2010.
• While licence costs for SharePoint may be relatively inexpensive, the complexity and cost of designing, developing, implementing and maintaining a SharePoint 2010 EDRMS is considerable and needs to be factored into the decision to implement EDRMS functionality with SharePoint.
• SharePoint 2010 is not compliant to records management standards including with reference to:
• Difficulties in capturing email;
• Lack of native security classification and access control; plus
• An inability to manage hybrid records (i.e. both electronic & hard copy records).
• As SharePoint generally operates as a series of team sites, the complexity & costs of design, development, implementation and on-going maintenance should reflect the fact that each team site will need to be specifically implemented to meet the particular recordkeeping requirements of each business area.
• Without proper design & implementation a SharePoint EDRMS implementation will become another sprawling, uncontrolled network or shared drive environment, with content existing everywhere. SharePoint’s native structure is much like a website, where it is possible to implement as many specific sites for different teams and projects or business areas as your organisation requires. Without strong records management frameworks, recordkeeping can quickly scale out of control in this kind of environment.

If your main interest is physical records management then don’t even begin to consider SharePoint because it simply cannot do it.

If your main interest is email management then SharePoint also does not have the required functionality.

However, RecFind 6:

1. Delivers all of the EDRMS functionality a customer will every need out of the box.
2. Is fully compliant to all known records management standards (e.g. has achieved full compliance with all of the latest VERS standards).
3. Has comprehensive out of the box capabilities to manage hybrid records (electronic and / & hard copy records).
4. Has the administration application called the DRM that allows the customer to customize RecFind 6 and change almost anything including the data model and any business process, easily & quickly, without source code changes, whilst remaining on the standard product.
5. Has a SharePoint 2010 integration module so that a customer can take advantage of the good collaboration & intranet capabilities of SharePoint and the best-in-class EDRMS functionality of RecFind 6 within the one integrated environment.

So there we have it, no more Mr nice guy. As a records management solution RecFind 6 blows SharePoint out of the water. It costs less, is easier and faster to roll out and has infinitely more RM functionality in the standard product than you will ever be able to develop in SharePoint.

Now I feel much better.

I have been in the application software industry for most of my professional life. I started in bureaus designing and programming bespoke applications for a variety of clients then moved to mainframes and online and real time application software development and then to my own software company in 1984. I have worked with thousands of customers and hundreds of applications and I have never seen any customer use anything like one hundred-percent of an application’s functionality.

Whenever I visit my customers there is a common dialog that goes along the lines of, “It would be great if RecFind could do …….” To which my reply always is, “Actually it can, would you like me to show you?”

Yes, before you ask, we do provide detailed help screens and manuals and both classroom and online training. We also have a plethora of helpful information on our website including white papers, a Knowledgebase & FAQs, News, helpful hints, product descriptions, etc., etc.

We also employ inside sales people who talk regularly to our customers and we communicate via newsletters and emails and, of course, this blog.

There is no shortage of information on what our products can do. There is however, still a big gap between what our products can do and what our customers understand about the capabilities of our products. From my experience, the knowledge gap is common across all products and software vendors because no one has yet come up with a mechanism to continually train and remind the customer’s personnel about a product’s complete functionality and entire range of capabilities.

Nor, do I suspect, would the average customer’s end user be too happy about being bombarded with unsolicited information of this kind. The fact is people only have time to work on a need-to-know basis. They only want to know enough to get the job done and this is entirely understandable.

Customers have multiple application products to work with and unlimited work to complete in a limited time frame. Typical end users do not have the time to become expert in any one application product and nor do they have the time to explore all of its capabilities or even to keep completely up to date with an application product as its moves from release to release.

This is a common dilemma for all application software providers. The best they can hope for is a single ‘champion’ within each customer that does his/her best to keep up to date and informed.

The end result of the above reality is that no customer ever manages to get maximum value from its application software. No organization ever gets a full return on its investment. There will always be many things the application software could be configured to handle that would improve productivity, solve burning problems and reduce costs but the knowledge gap prevents this happening.

The only solution I can think of is for the customer to pay the vendor to provide a resident onsite application expert who continually looks for application niches where the software can add value. However, the two flaws in this approach are:

1. Where does the customer find the money?; and
2. Where does the vendor find the people?

Apart from these two minor flaws, it is the perfect solution except for the fact that the application expert would also need to also be an expert in the customer’s business. You have to understand the customer’s business processes before you can determine whether a particular application software product could be a solution. This means that our application consultant needs to be pretty clever and very experienced with bags of initiative and there aren’t a lot of these people around; which brings me back to flaw number 2.

Archimedes was supposed to have said, “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.”

I say, “Give me enough smart people and I could automate the world.”

In both cases, we are missing the essential ingredient.

The difficulties don’t mean that we give up, au contraire; they force us to work harder at a solution. The vendor and the customer need to work together to find new ways for the vendor’s product to add value to the customer’s business. This is a mutually beneficial partnership.

Our product RecFind 6 was specifically designed and engineered to be able to handle multiple tasks simultaneously. It was designed from the outset to be a multi-application solution and to enable the customer to use the one piece of application software to solve multiple business problems. To be able to leverage off a single investment and use the one product for multiple business application needs.

We provide the high level tools free of charge with RecFind 6 so the customer can configure multiple solutions (e.g., records management, help desk, asset management, contract management, document management, email management, customer relationship management or CRM) using a single copy of RecFind 6. The tools also allow the customer to ‘partition’ the various applications so each group of users thinks it has its own solution.

However, despite the unique capabilities of RecFind 6, we still have the problem of knowing enough about our customers to be able to propose additional uses for our product. Maybe if all of our customers had their head office in North Sydney our task would be easier but I doubt it. As it is, we have customers all over the world in all time zones and in some very remote locations.

The Internet and Citrix tools like GoToAssist, GoToMeeting and GoToTraining largely solve the distance problems and do so in the most economical way without airfares, expenses and hotel charges. We use these tools extensively and our customers love the convenience and low cost of the solutions we are able to provide thanks to our friends at Citrix. But, there is still no substitute for being onsite and in face to face dialog to best understand a customer’s business processes and needs. It is a case of the old way is still the best way.

Our challenge in these austere times is to convince our customers of the value of our proposition. That is, that an investment in an onsite investigation of needs will always provide bottom line and productivity benefits; that it will more than pay for itself in the short term.

It is early days yet for our model but many of my customers are already using RecFind 6 to solve multiple application software problems. It is always a battle for both of us to find the time and resources for the investigation but it always pays off.

We are continually looking for new ways to simplify and systemise the processes required to determine where we can add value. We don’t have a perfect solution yet but we keep trying because the value proposition is undeniable; do more with less. Buy a single product instead of having to buy ten products. Learn how to use a single product instead of having to learn how to use ten different products. Deal with a single vendor instead of having to deal with ten different vendors. No integration required instead of having to integrate ten different products.

We know we have the right paradigm, now we just need to reach our audience.

This is the question that keeps Microsoft executives awake at night and gnawing at their fingernails.

Will home users, corporates and government agencies rush in to upgrade their desktops to Windows 8? I for one don’t think so and this is why I don’t think so.

The Vista debacle is still fresh in every CIO’s mind and I have not spoken to anyone who is planning to upgrade to Windows 8 in 2012 or even 2013. Most of my customers are still using XP and planning to upgrade to Windows 7.

Microsoft released Vista two years before it was ready and in doing so it inflicted a huge cost and productivity burden on its customers. Those same customers have long memories.

This isn’t a debate about whether Metro is a ‘good’ UI or whether or not Windows 8 should have a start button or whether or not the ARM version should have/will have the option of switching to the classical UI. That particular debate is for the techies and bloggers, not business owners and executives. For serious people this is a debate about value, cost and risk avoidance.

• What is the value proposition of Windows 8? What are the compelling reasons for upgrading to Windows 8? What are the benefits of Windows 8? What effect will Windows 8 have on the bottom line? How will the CIO compose a cohesive business case to convince the board to allocate scarce funds to a Windows 8 rollout?
• What will it cost to purchase Windows 8? What will it cost to upgrade all desktops to Windows 8? What will the cost be of lost productivity as your users grapple with the changes and differences? What will it cost to retrain your users?
• Will the initial Windows 8 experience be a repeat of the Vista experience? What is the risk of this happening? What is the risk of some of your current devices not working with Windows 8? What is the risk of some of your current applications not working with Windows 8? What is the risk that you will have to upgrade or replace some of your PCs? What is the risk that your will have to roll back to Windows 7 from Windows 8 as many customers had to roll back from Vista to XP?

Value Proposition

As a business owner I don’t believe Windows 8 has a compelling value proposition. I don’t see any reason to upgrade from Windows 7. Windows 7 works fine and I will follow the old but wise maxim, “If it ain’t broke, don’t fix it!”

Cost

In my business, if I add up all the potential costs including manpower and retraining and lost productivity I come up with a minimum of $1,000 per desktop to upgrade to Windows 8 and that doesn’t include any hardware upgrades that may be required. And this cost assumes that Windows 8 is not a Vista and that all my current devices and application programs (like accounting, CRM and payroll) continue to work fine. The absolute worst case would be $2,000 a desktop if my assumptions are incorrect.

Risk

There is no reason to accept any risk. I will be recommending to my customers that they stick with Windows 7 and wait at least two or three years until Windows 8 has gobbled up a couple of service packs and proven itself.

Maybe Microsoft hasn’t noticed but most of the world is still in recession and every one of my customers, private and government alike, is still trying to cut costs and do more with less. I don’t know where Microsoft thinks the money is coming from to fund a Windows 8 upgrade.

From my perspective as a long-term Microsoft .NET application software developer I have decided not to redevelop my Windows applications for Windows 8 because of the huge amount of retraining, effort and money required to do so. I have been on the Microsoft treadmill for 28 years and have dutifully upgraded, redesigned and redeveloped my applications for each new release of Windows over that time. This time I do not believe the effort and cost is either justified or required. Instead, I am concentrating on converting all my application client functionality to both web clients (to run in a browser) and mobile clients (supporting smartphones and tablets). There will be some inevitable tweaking to do for Windows 8 but for the most part my new RecFind 6 clients won’t care if the user is running Windows XP, Windows 7, Windows 8, Linux, Apple OS, iOS or Android.

I actually can’t think of any good reason to redevelop for Windows 8 and have to believe that there will be lots of developers like me that will go the web client and mobile client route instead of spending scarce R&D funds and important developer time just to comply with Microsoft’s latest idea of how desktop applications should look and work. I already have enough trouble keeping up with the rapid changes in Android thank you.

It is every software developer’s dream to have just a single set of source code and to support multiple platforms with the same source. Unfortunately, this has never been possible but I still have to manage costs by minimizing the number of code variations I have to support. The advantage of a web client is that it is largely compatible with most operating systems and browsers and I can build and maintain my web client with a single set of source code albeit with a number of “ifs” to cater for variations in browsers and operating systems. I need separate source code for Both Android and iOS for my ‘native mode’ mobile apps so I end up supporting three development environments, browser, Android and iOS. This is fine because my customers are demanding web clients and mobile clients so I know that my investment in these three environments will pay off. No customer has yet asked for a Windows 8 compatible/certified RecFind 6 client but it is early times yet.

My applications (all based on RecFind 6) are in the Enterprise Content Management (ECM) sector and are designed for the records management, document management, document imaging and business process management sectors. As such we could best describe RecFind 6 as an information management solution and luckily for us this is an ideal application for the three environments we now support, browsers (web clients), Android and iOS (mobile clients).

My customers are also happy to use my products in these three environments so I have absolutely no compelling reason to redesign and rewrite RecFind 6 for Windows 8. My browser clients will run under Windows XP, 7 and 8 so there is absolutely no need for me to build a ‘native’ Windows 8 RecFind 6 client. Hopefully, my current Windows 7 RecFind 6 client will run with only minor tweaks under the Windows 8 ‘classical’ desktop so that my clients that still want to run my ‘fat’ client can still do so. However, there will be no need to do so because my RecFind 6 web client will be faster and easier to install and maintain.

What if a majority of software developers think like me and Microsoft ends up with a new desktop platform and very few ‘native’ applications, especially designed and written for Windows 8? Customers buy Windows to run applications, to do work. If Windows 8 doesn’t have the applications they need they will not bother with it.

Microsoft has thousands of very, very clever people and a marketing budget I can only dream of so we should never write them off. They proved they can get it very wrong with Vista and they have also proved they can get it very right with Windows 7. Fingers crossed that they again get it very right with Windows 8. But, they are taking a very, very big chance and with most of the western world still in recession they have not chosen an exactly auspicious time to launch Windows 8.

To reiterate, and for all the reasons espoused above, I do not see Windows 8 being the success Microsoft is hoping for.