comment 0

Their Problems Should Be Our Problems

By Tamara Wilhite
An IE in IT

The book “How to Become a Rainmaker” is geared toward salespeople but applies to businesspeople and businesses as a whole. The book says that customers buy for only two reasons: to feel good or to solve a problem.  IT teams too often forget that fact.

Software rarely helps people feel good, unless it is a game. In that regard, games like Candy Crush manage to make a lot of money and many people happy. For everyone else in IT, software changes must solve a problem to be worthwhile. The problem many IT managers, programmers and developers face is aligning their solutions with the customers problems.

Before planning any software changes, upgrades, updates or whatever term you’d like to apply to the process of altering your application, ensure that the answer to at least one of these questions is a resounding “Yes!” before you go forward.

1. Does this change solve a user problem?

While reviewing the facts, verify that the problem it fixes applies to enough people that making one customer happy doesn’t annoy many others with the downtime or lost productivity of installing a new version.

2. Does it fix something we ourselves broke?

These software changes should take priority, in order to restore the company’s reputation.

3. Have we verified that this update or change is what the customers want?

Too many software changes are implemented because someone in engineering or IT considers it cool, cutting edge or the next big thing. However, it may not be what the customers want.

4. Does this change or improve an attribute customers consider critical?

A software change to improve IT security doesn’t need customer approval – we already know that no one wants to lose their credit card information or have personal information leaked.
Software changes that improve system uptime can be assumed to meet customer needs if reliability and uptime are critical to the customer base.
Software changes to stay in compliance with ISO, CMMI or another standards organization standard that customers want or need to achieve are worthwhile.

5. Have we verified that our change isn’t going to create problems?

There is a joke that all that matters in real estate is: location, location, location. In IT, we need to have the adage “test it, test it, test it”. All software changes need to be thoroughly tested for all environments and operating conditions, user types and transactions. Verify that the new functionality works – and that it doesn’t break anything else. And never remove functionality in order to add new features without verifying with the customers that they don’t need the old functions. After all, it was there for a reason.


In IT, it is essential that the problems we choose to solve are the ones that matter most to our customers, not the system administrators or techies that dominate the software development group. Focus on what matters to the end users, not the performance metrics or high tech projects that look best on someone’s resume.

comment 0

The Major Goals in IT – And How to Reasonably Achieve Them

When it comes to quality, the goal is zero defects, but Six Sigma quality of near perfection is considered good enough. Yet IT often sees goals for 100% perfection. What are some of the goals set in IT, and how can you actually make progress toward meeting them?

Goal: 100% Uptime

This goal is often set after repeated outages or a disastrous one.

There are several potential solutions to meeting this goal in IT.
• Track all outages after they occur, including the duration and scale of impact. Identify root causes so that they can be resolved long term.
• Focus on reducing the severity of outages and their duration when large scale infrastructure is required to prevent them altogether. For example, improving automated reporting of outages or access to servers by those who can reboot them shortens the duration of outages before a new mirrored server is installed.
• Appreciate a reduction in the duration and/or severity of outages in the quest for improved uptime.
• Run your systems off Linux and Unix instead of Windows servers. There are Unix and Linux servers that have approach 100% uptime.

Goal: 100% Customer Satisfaction

Installation time, bug fixes, time to release and other metrics are variable and can change release to release. However, many organizations want their customers to be happy. So they seek 100% customer satisfaction.


• Track satisfaction on a five or ten point scale instead of a yes/no request. If users can report intermediate responses or “It’s OK” are less likely to pull down the satisfaction rating because their only options are “perfect/not”.
• Ask for more information when people say they are dissatisfied. Did software install incorrectly? Are they unhappy with customer service when they requested a refund? Does the software no longer interface with another tool? Is there a bug in the new release, or is someone upset that your product doesn’t have the latest feature of a competitor? Identify root causes that aren’t your fault so that you don’t inadvertently ding the team for factors they cannot control.
• Separate enhancements for defects in customer surveys. Track the recommended enhancements but don’t count them as dissatisfied customers unless you actually removed the feature they want to add back.

comment 0

There Can Be Only One?

I worked for a company that found that its dozens of disparate PDM systems were a source of inefficiency and thus wasted money. Checking three different PDM systems was by definition inefficient and a waste of time. Add in the effort to maintain all these systems, their servers, redundant user accounts and you can see why this was far from ideal.
The logical solution was migration to a single PDM system. It required multiple migrations, but a common PDM system evolved. IT support costs, user efficiency and licensing costs went down.
However, a single software system is not always the right solution.

SAP has a strong financial and payroll system. Visiprise Manufacturing is a good inventory tracking system. However, when it comes to its manufacturing management system, the process of creating routers is notoriously difficult. PTC’s Windchill application is a decent PDM application. It can be used as a content management system. However, it can’t track as-built configuration information for individual assemblies or track depot parts. Each tool has its strengths, they all have their weaknesses.

The mistake an organization could make is trying to eliminate software tools that are not actually redundant.

Let’s take a different example, many small businesses use QuickBooks or another financial software application. These tools track spending, generate invoices and print pay checks for employees. These applications may be able to handle MRP with an add-on module, but otherwise trying to use this tool to track inventory, manage to do lists, track team calendars or store legal documents isn’t ideal.

It easy to say, “There should be only one.” However, the caveat is that there should be only one tool in the organization per category or intended purpose. You cannot use a single tool to run many businesses, or you’ll be as inefficient as the company that has too many tools.

The Evolution of an IT Policy and Pragmatism

In a recent argument with my eight year old son, I complained, “You put more work into avoid the work than it would take to actually DO it!” Shortly thereafter, it came time to review and sign the IT policies, an annual task for our employees.
The IT policies themselves have evolved to include social media acceptable practices, the near prohibition of streaming media unless you work in PR and apps, something that didn’t matter ten years ago. I realized that the very process of employees signing off IT policies has evolved.

The Olden Days

IT policies were printed out on paper. Employees were supposed to read them and review them. This typically occurred at a large meeting where handouts were given. Questions were answered. Everyone was expected to read them and sign them before handing it out.
Advantages of this process included the opportunity to ask questions of knowledgeable staff and some supervision to ensure that it wasn’t just signed off and turned in. The downside was the sheer volume of paper it required.

The Introduction of Content Management Systems

Content management systems or CMS allowed IT policies to be posted online. Employees could read the documents online. In the first generation of the CMS, the sign off process was simply clicking a check box that said “yes, I have read these policies”. Managers could generate reports about how many people had read the policies and identify those who had not.
The advantages included elimination of pounds of paper, the ease of distributing new policies and reportability. The disadvantage that was later discovered was the same thing I run into with pre-teen children – the desire to do as little as possible, and the effort that may be expended to avoid the perception of work. Employees sometimes visited the site, clicked the check box and were done. When later iterations required someone to open the file before the check box was visible, staff would occasionally open the file long enough for the check box to appear and then check it off.
The shortcomings of this system were clear when people were terminated for watching streaming video shows on their work computers and shocked that this was not allowed, despite the IT policies clearly stating it wasn’t. (The fact that they had enough time to watch an hour of TV on a work PC is a separate matter.)

Content Management Systems with Workflows

The downside of the initial CMS model was the human factor and tendency to efficiency. So the next generation of the content management system included a workflow. You had to open each document and close it before you could verify that it had been read. All IT policy documents had to be opened and at least load before it could be signed off as done. While you could theoretically sign it off as read after 30 seconds, the CMS tracked the time it was open. Managers could identify who signed off ten documents in less than five minutes compared to those who took an hour to read all the forms.


The irony of all of this was the realization that the IT policy sign-off and tracking system had evolved to try to counter adults acting much like my eight year old, seeking the most efficient way to race through a task to move on to what they’d rather do. The only difference is that in my child I’d call it laziness, while most adults would consider it practicality or pragmatism.