I run a company called the Knowledgeone Corporation that produces a software application called RecFind 6 that is used to provide records management, document management, workflow, document imaging, email management and general business process management functionality. Every installation is different because we configure RecFind 6 to the exact requirements of each customer. All installations include some form of business process management and many include a reasonable degree of complexity, especially, when integrating to other systems.

We are always proposing to new and existing customers and negotiating contracts and the one item in the pricing summary that is always under attack is training. As well as questioning the need for face to face training, many customers also try to reduce the cost by just training a core group that will then train the rest of the staff who will use the new system.

I try to explain that effective and complete training is fundamental to the success of the project; that training isn’t a cost, it is an investment in success. I rarely win.

I also try to convince my customers of the importance of ongoing training for new releases and new employees but I am rarely successful.

I try to explain that cutting costs on training is a sure fire way to ensure that the project will never be as successful as it could be. I rarely win this argument either.

And finally, I always recommend that an IT person attends the training course because his/her services will be need by the application administrator throughout the year. This rarely happens.

Yet, time after time and in example after example, projects (not just ours) are significantly less successful than they should be because someone in management decided to cut costs by skimping on training; by not training operational staff in how to use the product in the most cost effectively and productive way possible.

If you skimp on training you are almost certainly dooming your project to failure.

Lack of knowledge on how to best use a product is an insidious cancer. The project may begin with a big bang and lots of congratulations but deep within your organization the cancer has already started to grow. “I don’t like this product.” “This product is too hard to use.” “I can’t find anything with this product.” “My staff don’t understand this product.”

By year two, many people and departments simply don’t use the product any more. By year three there is a concerted push to find a replacement for this product that “is too hard to use. No one understands it.” The replacement project manager or application owner, who hasn’t been trained, is unable to address the complaints and soon also decides that the problem is with the product. It would be a bad career move to decide anything else.

In year four the organization begins looking for a replacement product. In year five, at great expense they select a replacement product and then lower costs by skimping on training. The cycle starts again.

If you skimp on training and re-training your project is doomed to failure.

How many expensive failures does it take before we learn the lesson?

Training is an investment in productivity, not a cost.

According to various industry surveys, 65% to 75% of companies still have no systems in place to manage email records. Based on my own observations and dialog with Knowledgeone Corporation’s customers and prospects, I would say the percentage is far higher; say 85% or more. My guess is that the industry surveys inadvertently included a number of email ‘cleaning’ systems as email management systems; thereby skewing the figures.

Given that there is now a variety of proven email management systems (like Knowledgeone Corporation’s GEM) available for most email servers (e.g., Exchange, GroupWise and Notes) and given the enormous danger of unmanaged email it is, on the surface, difficult to explain the apparent reluctance of organizations to implement email management policies and systems.

My own experience leads me to believe that the following are the major reasons organizations do not take this critical step:

1. Lack of ownership and leadership

Email management transects all of the traditional vertical organizational boundaries. There may well be an IT person in charge of the email servers but there is rarely a senior management person in charge of email organization-wide. That is, no one person actually ‘owns’ the problem and no one person has the authority to implement an organization-wide solution.

2. Lack of an understanding of the problem and of the solution

Most of the people who are senior enough in an organization to be aware of this problem do not comprehend the complexities of the problem. They have dialogs with IT people who explain the issues in technical terms, not in business or risk-management terms. Email management should come under an organization’s risk management regime because that is where a great deal of risk lies.

3. Lack of desire to solve the problem plus active opposition to a solution

There are a large number of IT people and others in every organization who simply do not want their emails managed, analysed, scrutinized, indexed and saved. This fact is never going to change and must always be addressed at a senior level by the person responsible for risk management policies and practice. Uncooperative and/or recalcitrant employees should not be allowed to put an organization at risk no matter what their position in the management hierarchy.

4. Confusion over what is involved in complying with a plethora of laws and regulations

One hundred percent of what well-meaning bureaucrats and politicians have done to ‘solve’ what they see as email privacy issues has been badly thought out, badly drafted and counterproductive; simply ill-informed, knee-jerk reactions. As you can see, I am no fan of politicians and bureaucrats who pass knee-jerk laws without understanding or caring about the full implications.

As far as I am concerned the privacy issue is secondary to the fact that every employer has to right to determine how its resources are used. Every employer has the right to protect itself. Every employer has the right to tell its employees if private emails are allowed or not. Every employer has the right to tell its employees what is acceptable and what is not acceptable in an email.

Solving the so called privacy policy is dead easy; herewith is the McKenna solution.

Tell employees that:

1. Private emails are not allowed and all emails will be scrutinized for inappropriate content; or

2. Private emails are allowed (in moderation) but that all emails, including private emails, will be scrutinized for inappropriate content; or

3. Private emails are allowed (in moderation) but that they MUST be identified by the keyword “Private” (or a word or phrase of your choice) in the subject line. All emails without the keyword “Private” in the subject line will be scrutinized for inappropriate content.

5. Confusing and misleading claims by companies marketing email management systems

It is a complex problem (have you ever tried to set up a multi-server email system in a large organization?) often poorly understood and poorly explained by the sales person. Add to this the fact that the sales person is usually speaking to the IT person (who lives in a different universe) who then has to ‘translate’ what he thinks the sales person said to senior management. Too often, the harried sales person, under intense pressure from the IT interrogator, will simply say “Yes” without really understanding the question or its implications.

My best advice to senior management is that if they don’t fully understand, keep asking questions until they do or, seek assistance from an independent authority. It is just plain dumb and dangerous to sign something off you don’t really understand.

6. Multiple and conflicting objectives

Is your objective to simply be aware of everything that is in your email store or is it to also meet a plethora of complex and competing regulations and certification standards?

Have you inadvertently set the goal post too high? Have you made the problem many times more complex than it should be? Has it become a “Wish List” instead of a requirement? Is the selection of a suitable product always held up by someone demanding that it has to also do something else? Has your horse now morphed into a camel?

My best advice? Why don’t you try ‘Getting wet slowly’ and review your needs again when the basic but critical email management problem is solved?

In the end it is about ownership, understanding and will. If just one senior person with the necessary authority understands the problem and commits to a solution then it will happen. The solutions are out there; they are just waiting for a committed purchaser with a clear and simple view of what needs to be achieved.

You must be aware of what is in your email store and you must be alerted to infringements before they grow into expensive problems. You can’t do this without an email management system in place.

I own and run a software company called Knowledgeone Corporation that produces an enterprise content management solution called RecFind 6. As such, our business is the design and programming of complex, heavy-duty application software. This means that we do the hard stuff, including all of the invention, and that I need really clever and innovative and productive IT people (mainly programmers) to work for me.

I have written previously about how hard it is nowadays to find the quality of people I need, see my previous blog entitled “Where have all the good applicants gone?” However, there is an even bigger problem in our industry with an ongoing fall in standards that began way back with the Y2K problem in the late 1990’s as everyone panicked about the problem of date handling once the year 2,000 clicked over.

The problem was basically one of greed where emerging countries like India realized there was a lot of money in providing IT expertise and started mass-producing so called ‘experts’ and shipping them all over the world. Very soon a resume or list of qualifications or certifications was all that was needed to convince paper-bound and rules-bound bureaucrats that an individual had the prerequisite skills to either immigrate or be awarded a work permit.

And of course, young people in countries like India and Pakistan and the Philippines moved into the IT industry not because they were motivated by the prospect of becoming IT professionals but because it was their ticket out of poverty and an entry opportunity into countries like the USA, Canada and Australia. So, we started to fill up the ranks of IT professionals with people that did not have the aptitude or motivation, just a strong desire for a better life (and who can blame them?).

Greed raided its ugly head again as local executives linked bigger bonuses to lower costs and the Indian companies further reduced ‘real’ qualifications to increase the supply of experts. Universities also got in on the act, again motivated by greed (more students equals more income) and standards were again lowered to create  a production line mentality, “Just pump more out of the system, we can sell them overseas!”

The law of averaging applies and as you gradually increase the number of the less talented and less well qualified people into the talent pool the lower the ‘average’ standard becomes. It is analogous to starting with a glass of the best Scotch Whiskey and then gradually adding more and more water. After a while it isn’t worth drinking because it isn’t whiskey any more, it is just flavoured water. We have similarly diminished our IT talent pool (especially in the ranks of programmers) to the degree where the average programmer can’t actually program.

For a long while we imported tens of thousands of these less-than-adequate programmers and they filled up the holes in mainly large enterprises like banks and finance companies and the public sector where they could hide their lack of real expertise. However, and unfortunately for them, the Global Financial Crisis (GFC) has accelerated the growth of outsourcing (back to even less qualified people in places like India, Pakistan and the Philippines) and our recent immigrants are now losing their jobs to their home country-men. I find this ironic but maybe you don’t agree.

In another previous blog, the world according to Frank, I predicted a significant rise in unemployment numbers within our IT industry. I also said it has been happening for some time but that the real numbers won’t be clear until around mid-2013.

Greed will continue to drive the outsourcing phenomenon just as it will continue to drive the lowering of standards and the overall effect on our industry will be significant as the available pool of real talent becomes smaller and smaller. Similarly, local opportunities for real professionals are disappearing fast. Many of you will end up having to help justify your boss’s big bonus by approving software created overseas when it isn’t really up to scratch and many more of you will relegated to fixing the crappy code being delivered to your company from the outsourced incompetents. Not a good future for real professionals and definitely not an environment of high job satisfaction.

When I began as a programmer in the 1960s everyone I worked with was highly motivated and everyone had a high aptitude because it was such a difficult industry to enter. You had no chance of working for a mainframe vendor unless you scored at least an A+ on the infamous IBM or Burroughs or ICL or GE or CDC aptitude tests. We were a very small and very exclusive group and to my mind, a dedicated band of professionals who were in IT because we loved it and were really good at it. The average level of expertise was extraordinarily high and this is now patently no longer the case because our industry has changed dramatically since those early and halcyon days.

So what is the future for real IT professionals who are in this industry because they love it and are really good at it? Like with all things, I believe there is good news and there is bad news.

The good news is that as a true IT professional your value is higher but, probably much higher than the less-than-competent manager who is interviewing knows. This is because many incompetent programmers have now managed to become incompetent managers and this situation protects incompetent programmers but punishes highly competent ones. Basically, your manager isn’t smart enough to recognize how different you are to the average programmer in his team. This makes getting paid what you are really worth very difficult.

Ergo, if you are really good at what you do and want to be paid what you are worth and want to do challenging and satisfying work your only chance is to select a company doing challenging work and a smart manager to be interviewed by. Oh, and don’t select a company with a greedy CEO who is looking to increase his bonus by outsourcing (regardless of the result) and lowering costs to impress the board and or shareholders. Sounds like a tough ask to me, thank God I am self-employed.

Would I recommend the IT industry to any young person today in high school contemplating a future career? No I probably wouldn’t. I would probably recommend accountancy, business studies, medicine or dentistry instead. So where am I going to find the really bright, talented and motivated programmers I need in the future? This almost certainly doesn’t bear thinking about but maybe it is an opportunity as most problems are.

We need a new way to select and train IT professionals; the universities are simply not doing a good enough job. Is there anyone out there with the money, ideas and knowledge willing to set up a new kind of highly selective IT training program? If so, please contact me, I will be more than happy to be one of your first customers.

I own and run a software company that designs, build and supports enterprise content management solutions. As such I have a lot of servers and workstations and performance and reliability are of paramount importance to me.

I had been a loyal Dell customer for many years. I have bought 40 or 50 servers, hundreds of workstations and dozens of notebooks plus other assorted paraphernalia such as racks, projectors etc. Back a few years ago Dell was a great company to do business with and its website made the selection and ordering of all the equipment I needed a breeze. Its support, both sales and technical was also top notch.

Even though I still think that Dell servers and OptiPlex workstations are great quality I no longer buy anything from Dell.

The reasons are to do with lousy service and the quality of its Australian web site.

The website is no longer easy to use or bug free and it is just annoying and no longer the really helpful resource it used to be. I have tried to tell Dell this on many occasions but no one is listening.

I also hate dealing with Dell’s Indian support centres and absolutely refuse to deal with an Indian based sales representative. If Dell wants my business then it needs to start doing business in Australia with Australian resident staff.

Every time in the recent past when we have had problems with Dell equipment it has been a nightmare trying to get things resolved. Again, I have gone out of my way to document these occurrences and tell the local Dell people but no one is listening because nothing has changed. If anything, and based on my experience today trying to get service for a Dell printer, it has gotten considerably worse. I do not enjoy being bounced around Indian call centres. Why does Dell senior management think it can reduce its costs by making me waste hours or days of valuable time when all that should be required is a few minutes?

Obviously, the powers to be at the top of Dell think reducing costs by reducing the service level is good business. Let me tell you as an ex Dell customer that it is not good business. Because I am a small customer in the scheme of things Dell probably doesn’t care that I have stopped buying Dell equipment. But, I can’t be the only Dell customer that is absolutely fed up with the new model with everything outsourced to India and the annoyances of the Dell website.

My point is that Dell used to be the best hardware company in the world to deal with and that it had the most reliable equipment and the best service level. Then someone at the top had all these bright ideas about how to lower costs. In my humble opinion, that person at the top needs to be replaced with someone who understands that customer service is paramount and that as the service level drops then so too will sales.

I still love my super reliable Dell servers and OptiPlex workstations and would dearly like to deal with Dell again but I and my staff are simply no longer willing to put up with the frustration of trying to do business with Dell via Indian call centres.

Hopefully someone with clout in Dell will read this Blog and realize that Dell’s fall in sales world-wide has less to do with the global financial crisis and more to do with its cost cutting. Hopefully that person will also be concerned with the massive eroding of its customer base and want to do something about it.

Here is my free advice. Dump your useless and unbelievably annoying Indian call centres and bring support back to the local country. Stop playing around with your website and give us the previously easy to navigate, easy to use and easy to configure and order website of previous years.

I would love to start buying Dell equipment again but you have alienated me just as I am sure that you have alienated hundreds of other previously loyal Dell customers.

Dear Dell, please give me a reason to come back.

I may be wrong but I think it was AIIM that first coined the phrase Enterprise Content Management to describe both our industry and our application solutions.

Whereas the term isn’t as nebulous as Knowledge Management it is nevertheless about as useful when trying to understand what organizations in this space actually do. At its simplest level it is a collective term for a number of related business applications like records management, document management, imaging, workflow, business process management, email management and archiving, digital asset management, web site content management, etc.

To simple people like me the more appropriate term or label would be Information Management but as I have already covered this in a previous Blog I won’t beleaguer the point in this one.

When trying to define what enterprise content management actually means or stands for we can discard the words ‘enterprise’ and ‘management’ as superfluous to our needs and just concentrate on the key word ‘content’. That is, we are talking about systems that in some way create and manage content.

So, what exactly is meant by the term ‘content’?

In the early days of content management discussions we classified content into two broad categories, structured and unstructured. Basically, structured content had named sections or labels and unstructured content did not. Generalising even further we can say that an email is an example of structured content because it has commonly named, standardised and accessible sections or labels like ‘Sender’, ‘Recipient’, ‘Subject’ etc., that we can interrogate and rely on to carry a particular class or type of information. The same general approach would regard a Word document as unstructured because the content of a Word document does not have commonly named and standardised sections or labels. Basically a Word document is an irregular collection of characters that you have to parse and examine to determine content.

Like Newtonian physics, the above generalisations do not apply to everything and can be argued until the cows come home. In truth, every document has an accessible structure of some kind. For example, a Word document has an author, a size, a date written, etc. It is just that it is far easier to find out who the recipient of an email was than the recipient of a Word document. This is because there is a common and standard ‘Tag’ that tells us who the recipient is of an email and there is no such common and standard tag for a Word document.

In our business we call ‘information about information’ (e.g., the recipient and date fields on an email) Metadata. If an object has recognizable Metadata then it is far easier to process than an object without recognizable Metadata. We may then say that adding Metadata to an object is the same as adding structure.

Adding structure is what we do when we create a Word document using a template or when we add tags to a Word document. We are normalizing the standard information we require in our business processes so the objects we deal with have the structure we require to easily and accurately identify and process them.

This is of course one of the long-standing problems in our industry, we spend far too much time and money trying to parse and interpret unstructured objects when we should be going back to the coal face and adding structure when the object is first created. This is of course relatively easy to do if we are creating the objects (e.g., a Word document) but not easy to achieve if we are receiving documents from foreign sources like our customers, our suppliers or the government. Unless you are the eight-hundred pound gorilla (like Walmart) it is very difficult to force your partners to add the structure you require to make processing as fast and as easy and as accurate as possible.

There have been attempts in the past to come up with common ‘standards’ that would have regulated document structure but none have been successful. The last one was when XML was the bright new kid on the block and the XML industry rushed headlong into defining XML standards for every conceivable industry to facilitate common structures and to make data transfer between different organizations as easy and as standard as possible. The various XML standardisation projects sucked up millions or even billions of dollars but did not produce the desired results; we are still spending billions of dollars each year parsing unstructured documents trying to determine content.

So, back to the original question, what exactly is Enterprise Content Management? The simple answer is that it is the business or process of extracting useful information from objects such as emails and PDFs and Word documents and then using that information in a business process. It is all about the process of capturing Metadata and content in the most accurate and expeditious manner possible so we can automate business processes as much as possible.

If done properly, it makes your job more pleasant and saves your organization money and it makes your customers and suppliers happier. As such it sounds a lot like motherhood (who is going to argue against it?) but it certainly isn’t like manna from heaven. There is always a cost and it is usually significant. As always, you reap what you sow and effort and cost produces rewards.

Is content management something you should consider? The answer is definitely yes with one proviso; please make sure that the benefits are greater than the cost.

I own and run a software company building enterprise content management solutions (RecFind 6) and I have a love/hate relationship with Microsoft Windows.

I love Windows because it is a universal platform I can develop for that provides me access to ninety-percent plus of the business and government organizations in the world.  I only need one set of source code and one set of development skills and I can leverage off this to offer my solutions to virtually any organization in any location. We may say that Microsoft Windows is ubiquitous.

I hate Windows because it is overly complex, unnecessarily difficult to build software for, buggy and causes me to have to spend far more money on software development than I ought to. There are many times each year when all I really want to do is assemble all the Microsoft programmers in one place and then bang their heads together and shout at them, “for heaven’s sake, why don’t you guys just talk to each other!”

Linux on the other hand, even in its many manifestations (one of its main problems), is not ubiquitous and it does not provide me with an entry point to ninety-percent of the world’s businesses and government agencies. This is why I don’t develop software for Linux.

Because I don’t develop application software for Linux I am not an expert in Linux but I have installed and run Ubuntu as a desktop operating system and I really like it. It is simple, clean and easy to use; more ‘Apple-like’ than ‘Windows-like’ to my eyes and all the better for it. It is also a great software development platform for programmers especially using the Eclipse IDE. It is also free and most of the office software you need (like OpenOffice) is also free. It also runs happily on virtually any PC or notebook and seems to be a lot faster than Windows.

So, Ubuntu (a flavour of Linux but a very good one) is free, most of the office software you need is also free, it looks good, runs on your hardware and is easy to use and uncomplicated. So why isn’t it ubiquitous? Why are people and organizations all over the world paying for (and struggling with – who remembers Vista?) inferior Windows when Linux varieties like Ubuntu are both free and better? Why are users and organizations now planning to pay to upgrade to Windows 7 or Windows 8 when alternative operating systems like Ubuntu will do the job and are free?

I read a lot of technical papers and IT blogs and I notice that the Linux community has been having similar discussions for years. As an ‘outsider’ (i.e., not a Linux zealot) it is pretty obvious to me that the Linux community is the main reason Linux is not ubiquitous. Please read the following ZDNet link and then tell me what you think.

http://www.zdnet.com/linus-torvalds-on-the-linux-desktops-popularity-problems-7000003641/

When I read an article like this two terms come immediately to mind, internecine bickering or sibling rivalry. How many versions of Linux do we need? The Linux fraternity calls these distributions or ‘distros’ to the insiders.  At last count there are around 600 ‘distros’ of which 300 are actively maintained.  Ubuntu is just one of these distros. How would the business world fare if there were 300 versions of Windows? Admittedly, most of the 300 have been built for a specialised use and the real list of general use versions of Linux is much smaller and includes product names such as Ubuntu, Kubuntu, Fedora, Mint, Debian, Arch, openSUSE, Red hat and about a dozen more.

But, it gets worse. On Ubuntu alone there are there main desktop environments to choose from, GNOME, KDE and Xfce.  Are you confused yet? Is it now obvious why Linux is not the default desktop operating system? It probably isn’t obvious to the squabbling Linux insider community but it is patently obvious to everyone else.

Linux isn’t the default desktop operating system because there is not a single standard and there is never likely to be a single standard. No software developer is going to invest millions of dollars in building commercial applications for Linux because of this. Without a huge library of software applications there is no commercial market for Linux. Windows reigns supreme despite its painful problems because it provides a single platform and because software developers do invest in building millions of commercial applications for the windows operating system.

Until such time as the Linux community stops its in-fighting and produces a single robust, supported version of Linux (when hell freezes over I hear you say) the situation will not change. The inferior desktop operating system Windows will continue to dominate and Linux will remain the plaything of propeller-heads and techies and old guys like me who really like it (well, the Ubuntu version that is, there are too many distros for me to become an expert in all of them and that is the core of the problem).

I own and run a software company that builds, sells, installs and supports an enterprise content management solution called RecFind 6. As such, I employ programmers, support specialists, accountants, consultants, trainers, pre-sales people and sales people to name but a few categories. This means I am always hiring and always reviewing applications from candidates.

Basically, most of the applications I receive are rubbish. They are badly written, badly formatted, not ‘selling’ documents and almost never focussed on the position I am advertising.  This is very sad but it does make vetting an avalanche of resumes pretty easy. I would probably spend no more than a minute or two reading each resume in the first pass to separate the real candidates from the flotsam. I move the results into two folders, one called possible and the other called ‘No way’.

This may sound a little impersonal but I have no patience with people who waste my time by firstly not reading the advertised job description properly and then by sending in a non-selling document. In fact, most resumes I see are great big red flags saying, “Please don’t hire me, I am a dope who didn’t read your ad properly and then couldn’t be bothered even getting the spelling and grammar correct or trying to sell myself in any way”.

So my first advice is if you are too lazy to allocate the time and effort required or can’t simply be bothered to sell yourself in the most professional manner possible then don’t bother because all you are doing is wasting your time and the time of any prospective employer. Prospective employers also have long memories so rest assured your next application to the same firm will be instantly relegated to the waste bin.

I only hire professionals and professionals do not send in a non-professional job application.

I only hire people who respect my time and I only hire people who manage to convince me that they really want the job I am advertising and are the best person for that role.

I figure that the effort you are prepared to expend on what should be your most important task at this time (i.e., finding employment) is indicative of the quality of work I can expect from you as an employee. If you send me a poor quality application then I assume everything you would do for me as an employee will be of a similar poor standard. If you are too lazy or too careless to submit a winning application then I can only assume you would also behave in this manner after employment so I have zero interest in you.

This is the bit I struggle to understand. How come the applicant doesn’t understand the obvious correlation any prospective employer makes between the quality of the job application and the quality of the person?

Please allow me to give you some simple common-sense advice that comes from a very experienced employer of people.

Always:

• Read the job ad very carefully. Note the prerequisites and requirements; the employer put them in for a reason and he/she would really appreciate it if you didn’t waste his/her time by applying for a position you do not qualify for.

• Always include a cover letter personalized for each and every job application. Your objective should be to convince the prospective employer that the job advertised is perfect for you and that you are in turn a perfect fit for the job.  If your past experience or skillset isn’t a perfect fit, use the cover letter to explain why it isn’t a problem and why you are still the right person for the job being advertised. All potential employers are impressed by someone who takes the time and trouble to align their skills and experience to the job on offer. Most importantly, use words and phrases from the job ad in your cover letter. This helps convince the potential employer that you have really thought about the position and have put intelligent time into your application.

• Clean up your resume, spell and grammar check it and convert it to a PDF for a much better and more professional looking presentation effect. All potential employers can’t help but appreciate a well presented and professional looking resume; it sets you apart.

In the end it is all about the initial impression you convey to the prospective employer. You have one shot so make sure it is a good one.

You need to convince your prospective employer that you selected their advertised job to respond to because it really interests and excites you and that you have the attitude, aptitude, character, experience and skillset required to make the most of this position. You have to convince them that you would be an asset to their organization.

It doesn’t take long to write a personalised cover letter, maybe an hour or two at the most and it should never be more than one page long. My final advice is that if you don’t think the advertised position is worth an hour or two of your time then don’t respond because you will be wasting your time. Don’t ‘shotgun’ job opportunities with multiple low-quality and non-selling applications. Instead focus on just the jobs you really like and then submit a smaller number of high-quality and personalised applications. I guarantee that your success rate will be much higher and that you will be asked to more interviews and that you will eventually get the job of your dreams.

The simple message is that you will get out of the process precisely what you put into the process. It is a tough world but in my experience effort is always rewarded. For your sake, please make the effort.

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?