Yesterday almost everyone in our office received one of the IRS tax refund scam emails that have been going around.   No one fell for it, but I can see how someone could.  Computer related fraud is becoming more and more common. 

During the sales cycle we are often asked how employees might defraud our application and cheat the company.  There isn’t a cornucopia full of opportunities for fraud in HRIS, but there are few and one spot in particular is time and attendance.  Stealing time from an employer is probably as old of a trick as employment itself.  Fudge 15 minutes here, a half hour there and pretty soon the company is paying you for 40 hours of work when you’ve only worked 30.

We allow for two basic types of (regular) time entry in our application: by the honor system and by time punch.  Which a client uses is usually a nod to the corporate culture of that client.  We’ve had client adamant about never using the honor system and we’ve had clients just as adamant about always using the honor system.

Here is how we work to prevent fraudulent time and attendance entries the application:

1.       Time punches: if used by a client our time punch system requires the employee to authenticate via username and password and then punch a virtual time clock.  The time for the punch is controlled by our servers.   By requiring authentication we’re making it more likely that the employee is punching their own "time card”.  By controlling the timestamp on our servers, we prevent anyone from cheating the system by fudging the time on the client PC.

2.       Rounding:  We round the punch or honor system entry by whatever rule the client has.  We all know people who work this angle.  If someone knows that until seven minutes past the hour the punch will always round back to the hour they wait until 6:59 past the hour to punch in, stealing almost seven minutes.  We track the rounding and measure whose favor the rounding is in and can report on these on an employee by employee basis.  Over time if an employee is being honest with their punches that give and take should average out to about zero: sometimes it will be in the company’s favor and sometimes it will be in the employees favor.

3.       Work Flow: For all of our time and attendance functions there is an associated work flow.  The workflow is defined by the client and can be (and should be) used as a check and balance.  If a manager is required to review and sign-off on an employee’s time and attendance then it is much more likely someone will be honest in their timekeeping and that any fraudulent behavior will be caught upon review.

Our controls for off-time work pretty much the same way. You have to go through very similar process esin order to take time off.  We track your requests for off time, put them through workflows, get them approved and report on them.

Not many employees cheat at the time and attendance game, but it’s important to be able to know if someone is stealing time.  Labor is a huge cost for any company.  If you were being shorted half your widgets on every shipment you’d want to know and would want to take preventative measures to prevent it.  The same is true for hours worked.  Every hour falsely worked is money taken from the bottom line, lost productivity and a theft from the company.

Defining what is or what is not a defect is a lot like defining happiness or love, but in reverse.  Happiness and love are fun, defects are not.  In two recent posts I discussed metrics and goal setting.  For me, and I think for IT in general, metrics are null and void if a company does not have a well defined set of criteria for what’s a defect and what’s not.

A lot of issues can masquerade as a defect and defects can come in many shapes and sizes.  Without being specific about what a request type is and means too many issues will get lumped in one bucket and the wrong people and groups will get saddled with the weight of that bucket come metric measuring time.

If you’ve read my posts Metrics 101 and Metrics 102 you know that we’re going to measure IT success (in part) at Achievant based on the flux within our ticketing system.  In order to have valid metrics we’ve identified 10 types of tickets:

1.       Data Update:  This category covers any data transformation, update, whatever.  These aren’t defects.  They are usually in responses to changes in state or federal codes or a change is business practice by a client.  For example, when the fed changed the convention for ethnicity codes that generated a Data Update ticket in our system as we complied with the change.

2.       Defect - Business Logic:  There are lots of flavors of defects.  We wanted to pin our defects down a little so we could better track where we are breaking down.  A business logic defect is one where the actual business rules are not followed.  For us a ticket is marked as Defect – Business Logic only if the developer coded the business logic incorrectly.  If we see a lot of these we know that we’re doing a poor job of communicating business requirements to the product development team and can adjust our requirements gathering and reporting accordingly.

3.       Defect - Hard Error:  Really you should almost never see these.  These are errors that are full on blow-ups.  You shouldn’t see them in QA and you shouldn’t seem them in production.  A developer doing his job unit testing should uncover any error so egregious prior to releasing his code.  If we see a number of these we know we’re either rushing the process or have developers who aren’t doing the due diligence they should.

4.       Defect - User Interface:  This means the UI has an issue.  Maybe the screen does refresh after a drop down list change or a button is in the wrong location on the screen.  These are strictly issues relating to the look and behavior of the UI.  Too many of these means we are not validating or work against the specs well enough or not following our own design rules.

5.       Defect - Validation Failure:  this category is exactly what it looks like.  The code failed to validate a data entry upfront and bad data has made it into the system or caused an error.  To many of this type of issue means we’re not taking the time to bullet proof the application and are rushing.

6.       Enhancement:  Enhancements are any changes to the app that make it better and which are not a simply a gap in current functionality.  These are for brand new functionality only.  If our applicant tracking module doesn’t allow for the upload of resumes in Word format that’s a gap, not and enhancement.  If we decide to add a module for union labor disputes that’s an enhancement.

7.       Gap:  Gaps are those things the application should do, but doesn’t.  Every application has these kinds of issues.  They are like enhancement in that they are new functionality, but unlike enhancements in that we should have thought of them while developing an actual enhancement but didn’t.  these are the slap your forehead, :why didn’t we think of that” kind of things

8.       Missed Requirement:  These are a failure in the requirements definition.  If a client MUST have duplicate copies of all emails sent to legal and we fail to note that and don’t develop that it’s a missed requirement.  These are things that come up in the sales and discovery process, but which never make it into a requirements document and are then never developed, but should have been.

9.       Performance Improvement: These are tweaks to code, SQL, OS configuration, whatever that make the application perform faster.  At Achievant we record the load time for every request of every page and regularly review the numbers to make sure we’re not slowing down and to also ensure that we don’t have any dogs out there.  Performance Improvement tickets address application slowness.

10.   Wish List: We all have this.  We might call it a portfolio, a backlog, whatever.  It’s those things that one day we’ll get to when all the planets and stars align and we’re not busy doing something else.  These are unique tickets because they sit on the shelf for a long time by their very nature.  When you’re measuring the closure rate, etc of your tickets this bucket can skew your numbers if not accounted for accordingly.

Just as important as defining what the tickets are is the goal of getting everyone to agree and to follow that convention.  We all know there are politics associated with the tickets in queue for product development.  If everyone follows the game plan then everyone is measured equally by the metrics.

Now that I have been blogging a while I have gotten a number of questions about what blogs I read.  So, even thought it isn’t related to time and attendance, HR automation software, performance management or any of the other HR topics I frequently cover I thought I’d list my top five favorites for anyone else who was interested:

1.       TechCrunch:  to me TechCrunch is kind of the insider Technology blog.  It covers all that’s new on the Net.  TechCrunch is more about the business of the Net than just the gee whiz gadget stuff you might find elsewhere.

2.       Red Herring: This is probably the most serious blog I read.  While the others certainly have real content Red Herring is more like news that any other blog.  Red Herring is a technology magazine dedicated to emergent technologies.  They are serious journalists and making it into Red Herring is a little like being in Time or Newsweek.

3.       CNET: CNET has a bevy of blogs.  I like the Beyond Binary blog and the Crave blog.  If you can’t find a technology related blog to read here you have no technology soul.

4.       Digg: a great way to stay on what’s hot at the moment.  Dig is essentially news bits (and other bits, too) rated by readers.  Either Digg It or don’t.  Get enough Diggs and you wind up on the Digg front page.  You may see the Digg icon on blogs, videos, news stories and a myriad of other things as you surf.  I read the Technology section of Digg.  It’s great amalgam of some of the best technology content on the web.

5.      Technorati:  this site is a collection of what’s hot right now.  It’s a great way to get your techno-blog on in a one-stop-shop format

You may work in a specific industry vertical (like, say, HRIS), but keeping up on the latest in technology makes you that much better at what you do.  There is a lot of crossover in the tech world and knowing what’s hot in music technology, bio technology, or whatever may very well help you serve your clients better.

Let’s talk metrics.  Not the Yard vs. Meter kind of metrics, but the kind that hopefully your supervisor shares with you and you share with your direct reports more than once a year. 

In my last post (Metrics 101) I talked about coming up with metrics for my team here at Achievant as we flesh out some of our own goal setting for our internal performance management.  It was a team effort and here is what we decided made good metrics for an IT group.  Our goal was to create a score card that told us how we are doing, how well we’re serving the client and how well we are supporting the other key corporate goals.

1.       Newly reported issues - this will represent all new cases opened in our ticketing system. This report will break down into sub-reports by client, by request type and by application function.  This report should let us know if one client is driving all of our work, if all of our work is being done on one specific type of request (defect, enhancement, gap, etc) and if one functional area is seeing most of the churn.  Knowing these things will help us gauge the strength and weaknesses of the application and determine how to best utilize resources to meet client needs.

2.       Released tickets - this report will show us every ticket released to production.  Knowing this will help us judge our own productivity and when we group the report by client, request type and functional area will let us know if we are serving our clients appropriately, spending the right amount of time on each request type and if one functional area is getting far more (or less) attention than all the others.  If all we’re doing is fixing defects and never releasing enhancements we know to shift focus early upstream to diminish the number of defects in order to free up resources for enhancements.

3.       Current Bucket Volume - this report will tell us the count of tickets (that are active) in each request type.  This will let us know if we are being deluged by a single request type or if the distribution is as expected.  If we see a high defect count we know we’re not doing our job unit testing and QAing.  If we see a high enhancement count we know we are lacking features.  We’ll complex this report by client to see if a single client is getting pelted by defects or is requesting an inordinate number of enhancements and we’ll also complex the report by functional area to see the same in a more generic context.  Historic trends of this report should tell us if we’re improving our QA, adding features fast enough and serving the needs of the client.

4.       Ticket Fail Rate – this report will tell us what tickets were rejected from QA back to product development.  We’ll complex it not only by developer, but by client and functional area.  Watching this should alert us to any inherent quality issues and help us be proactive to address any such issues before they become defects in production. It will also help us identify any developers who may need additional training or a change in workload.

5.       Difficulty – this is a report that reports at the weighting we assign to tickets.  No two tickets are the same and if we’re going to use these metrics as a performance management tool we need to be able to level the playing field.  A ticket to correct a spelling error on a single screen is not equal to a ticket to rewrite the encryption algorithm we might use to store sensitive data.  We need a way to differentiate such things so that developers are judged on a level playing field. 

We’ve decided to review these metrics weekly and include in them the historic trends for the previous year.  This way we can see data to the moment, but also stay aware of trends up or down and make sure each metric we measure is headed in the right direction.  It will also allow us to see the impact, or lack of impact, of any corrective action we take.

 As a group the development team decided that early and often is the best way to catch negative trends and to strengthen positive ones.  We will meet as a group and review the week’s reports.  Everyone will get to participate.  We’ll role these metrics into our HR automation platform (which we use internally) and keep track of them through the performance management module.  Each week we’ll be able to note changes good or bad, improvement, lack of improvement, etc.  When it comes time for our annual reviews we will have well thought out, detailed data culled from throughout the year with which to performance the reviews.  The reviews, really, should be just a formality.  Everyone should already know where they stand.

Hello World. 

Every entry level programming class begins with its students building a program that displayed the words “hello world”.  Since this is my first blog, I found it fitting. 

Now that I’ve gotten the worry of sounding cliché out of the way, allow me to introduce myself.  My name is Byron Pitney and I am Ed’s guest blogger (thanks for the blogstipation intro).  I am also the Software Architect on Ed’s team here at Achievant.  I’ve spent the last seven years writing code, but this is my first year writing HRIS software.  I have always enjoyed building things that are useful to people.  Working on a system that benefits employees and their employers definitely fits that bill.

Not too long ago Ed sent me an email with an attachment he affectionately refers to as The Bus Document.  In other words, if he were to get hit by a bus we would (in theory) still be able to continue on without him based on the information in “the bus” document.    

At first I was laughing at the way he was so carelessly talking about his own demise, but then the wheels started turning in my head.   What would we do without him?   What if instead of getting hit by a bus, he got a really good offer from a start up state-of-the-art search engine and left us behind? 

Do we have a plan B?  Being makers of HR automation software we should certainly have a succession plan for our key employees.

I know that leaders of any business have a lot of responsibility (what they choose do with this responsibility might be a blog for another day).   It is important for them to groom their employees to someday fulfill their roles.   I’ve seen first-hand how neglecting succession planning can cause major headaches. 

A company that I worked for struggled with this concept.  For sake of protecting the innocent, let us call the company Company X.   During my time at Company X I worked under a manager that was heavily involved in developing his team.  Next to getting the job done, team building was his top priority.  His was a sound philosophy. 

In order to be successful, he surrounded himself with successful people.  He made sure his team had proper training, and that they were reaching their clearly defined goals and objectives.   However (this is where the neglect part comes in), Company X did not have job descriptions or career paths in place.  In the eyes of the company, his standard for developing employees did not meet the same standard the company had (or in this case didn’t) set.  When the manager eventually stepped down, he recommended his replacement.  Since Company X hadn’t given time to succession planning they treated the recommended person the same as any other resume off the street.  To make a long story short, instead of losing one employee, their lack of succession planning eventually cost them four.  In retrospect, having a plan B seems like common sense.  Unfortunately, common sense does not always prevail.

Blogstipation (blŏg-stə-pā'shən)

1.       Difficult, incomplete, or infrequent blogging.

2.       Writer’s block.  Hectic work schedule.

As some of you have noticed and a couple of you even complained the posts on my blog have diminished in frequency.  It’s not that I don’t like being witty and urbane (ok and maybe a little wordy).  It’s just that sometimes I come up blank for a day’s post or have so much to do that I can’t crack open Word and jot down my thoughts on a given subject that day.

So, that said, I am going to turn my blog over to a “guest blogger” once a week starting this week.  Not only will a guest blogger help cure my blogstipation, but it will lend a fresh perspective to the blog, inject a new perspective and give an up-and-comer a chance to have a voice.

There have been a number of cases of “what belongs to whom” in the news lately.  One sensational case was the Tom Cruise Scientology video that’s has been shown on every media outlet in the known universe and another more hum drum case was a recent court ruling regarding corporate email and a company’s right to restrict how that email is used.

It’s the hum drum case that should have our attention.

I have always been amazed by how unaware most people are regarding who really owns the emails they send at work and the personal content they keep on their work-owned PCs.  We all use our work email and PC so frequently that it becomes second nature to treat it as our own.  The only problem is: it’s not.  That PC and email account and everything on and in them belong to the corporation and not the individual.

In my career as the reluctant email and PC content police I have come across people who sent inter-office love letters to people not their spouses (only to have those letters then become public after an inadvertent print) and even racy photos and provocative drafts of personal ads that become office gossip after accidently being shared via a shared network drive.  There are cases where someone has even been convicted of murder based on instant messenger logs and emails which were subpoenaed and then used at trial.

What does all of this have to do with HR automation software, time and attendance, learning management and performance management?  Chances are that your HR system, like our HR application, stores a variety of data from performance management comments to disciplinary notes to emails.  Knowing what is and is not proper content in those instances can sometimes be challenging.  It requires clear guidelines, a well educated staff and some due diligence. 

For our own needs here at Achievant keeping a handle on content is pretty easy.  We have a Professional Services and Consulting staff with deep experience in such practices.  We have well defined usage policies and keep our employees up-to-date with HR alerts on any recent developments in this space.  We arm our staff with knowledge so they know how to make the right decision.

If you’re not keeping your staff up-to-date, training and educating them on what is and what not valid content for reviews, emails and other forms of communication you’re setting your employees up for potential failure.  It can be an easy task to put off because it’s not needed until it’s already too late.  Take them time and wrap some best practices around corporate communication no matter what form it takes.  You’ll be glad you did: it’ll drastically reduce the chances of an issue and will provide clear guidelines when as issue does arise.

At our last Senior Staff meeting here at Achievant we set about to define the corporate and departmental goals for this year.  We’re a new company and this is a relatively new exercise for us.  We didn’t make it really far.

Mostly we couldn’t agree on what a goal was or was not, or what kind of goals we should measure or how to organize those goals.  It’s not like we don’t have experienced people with 20+ years of leadership experience each or haven’t done this a million times before.  We do and we have.  The issue, as it always seems to be for these kinds of things, was finding where to start.  Do we start at the top or at the bottom?  Should the goals be broad or specific?  Should we list them by department or by category?

For me, especially as an IT guy, goals are a series of more and more refined needs.  In the mid 1950s an American psychologist named Abraham Maslow created a hierarchy of human needs.  It pretty much said that simple needs precede complex needs.  I need to have shelter and food before I can worry about emotional and intellectual fulfillment.  I believe the same is true of goals.  Specific, but simple goals precede more general and complex goals.  You have more of the former and less of the later until you have at the top of your pyramid one goal everyone within the company strives to succeed.

Revenue, for most companies, is that tip-of-the-pyramid goal.  But revenue isn’t really a goal.  It’s the result of well executed goals.  So, like Maslow put self-actualization at the top of his pyramid I put revenue at the top of mine.  Maybe in the tier below revenue we put actual dollar amounts for gross revenue by quarter.  Now we’re getting a little more specific.  We’re getting to something tangible an IT guy like me can wrap his mind around.  What do I need to do in order to help make those quarterly revenue goals?  What goals can I pass on to the individual members of my team that they can strive for and be tracked against?  I could say that my group will develop brand new features X, Y and Z which will increase the client base which will then generate revenue.   But is that a goal at which I can succeed?

I don’t think they are.  For anyone who has ever managed a portfolio of IT projects we all know that today’s critical, must have feature is tomorrow’s forgotten enhancement.  Software is remarkably fluid.  What the market wants, what your existing clients want and what your next big client wants juggles priorities like a California earthquake juggles fine china.  Saying that four months from now I will be working on X is, to me, a goal that is largely unattainable.  Anyone who has worked in IT knows that it’s hard to say what you’ll be working on at the end of the day let alone at the end of the quarter.

Instead, I would frame my goals differently.  I would manage my performance management differently.  Goals that are strategic more than technical should revolve around trends, not specific actions.  Maybe we should make increasing the feature count of the application our goal, but not what those specific features are.

This way the fluidity of the environment is reflected in the goal and the goal itself will be as valid three months from now as it is today.  We don’t need to see feature X at the end of the quarter to know we succeeded, because tomorrow we may learn that features X, Y and Z are not as critical as features 1, 2 and 3.  What we do know is that more features are better than less.  We can set tangible goals without setting too tangible specifics.  By the end of Q1 we can increase our feature count by 25% or 33% or whatever the right number is.  We’ve done what we needed to do to support the goals above us in the pyramid and have done so without knowing exactly what it would take to meet the goals. New features mean a greater appeal to a larger client base which means more revenue.  We’ve traversed our way up the pyramid without locking anyone into a goal that may or may not remain valid.  We’ve succeeded.

This is just a single example.  There are many others and they are as varied and as complex as can be imagined.  The important part is that we are able to define specific goals that are measurable and which will not become obsolete over time.

As any of my frequent readers have certainly noticed (and a few have commented) the regularity of my postings has wavered as of late.  The primary cause of that fluctuation is the topic of today's post: data conversion.  If you've worked in IT or have been the user of a data intensive system for any length of time you've probably come across a data conversion or two.  They are frequently the foundation of a new system and they can be either the bane or the blessing of any project.

Let me start off my rant, I mean post, with a little full disclosure.  I love data.  I know it makes me an Über nerd, but I have always believed knowledge is power and the root of all knowledge is data.  As for data conversions I have a lovehate relationship.  I love transforming the data from one configuration to another. I also enjoy the detective work that's required up front to make sure the conversion goes well.  I hate the myriad of headaches you'll inevitably come across and the concessions you sometimes have to make.

HR automation, time and attendance, performance management and all the other things our app does use a lot of data.  Names, SSNs, addresses, EEO codes, job titles, departments, classes taken, pay history... a billion and one things.  Literally hundreds of fields per row and sometimes tens or even hundreds of rows per user.

I've done a data conversion or two and have learned a few hard truths.

1.       The data will never be what you expect

2.       Regardless of what column or row delimiters you choose the data itself will contain those values.  Choose tabs, pipes, commas or whatever and you're sure to encounter them.

3.       Either some data condition will exist that your app doesn't account for or some data condition will not exist that you need.

Let me give you some examples from some of our more recent conversion projects: Under the Didn't Expect That category we had a client who had a deduction code for every payment level under a single benefit plan (Employee, Employee Plus Spouse, Family, etc).  We'd never seen that before.  Under the No Matter What Delimiter You Choose category we had one client for whom every address line ended in a comma followed by a tab. Some of the addresses had a pipe in them and almost all had commas.  Go figure.  As for the You Can't Get There From Here category we had employees with job titles that didn't exist in the job titles and description look-up the client provided.

When importing converted (or soon to be converted) data I've always had a few rules:

1.       Get IT out of the conversion racket as quickly as possible.  In our case this means providing tools to our Professional Services team so that they can perform a data conversion from start to finish on their own.

2.       Isolate the data as your first step of importing.  Put it in staging tables that are normalized, but are defined with data types as forgiving as possible and which are not tied to your production tables in any way.

3.       Inspect the data in every way you can think of before moving it from the staging tables to your production tables.  I inspect for simple things like length and data type, but also compare data to look-up tables, perform cross-correlations and check for reasonability. 

4.       Provide a user interface for the data import that allows all of these activities (plus corrective action) to take place.  I like to provide what we refer to as a “bulk edit” feature that shows every line of data for every user (broken up logically) with discrepancies highlighted.  Each field is editable and I like to track the changes to those fields, who made them and when. 

5.       Test not just the data, but the processes driven by that data.  Our app has about 40 workflows straight out of the box.  We’ll run each to make sure the data imported doesn’t somehow impact a business process in an unexpected way.

Data conversions happen every day for us.  Pretty much every new client or project involves bringing in new data.  We probably deal with this issue more than most companies just by the nature of what we do.  As the first step of introducing a new client to our system we take it very seriously.  It is the corner stone on which the rest of the relationship with that client will be based.

Defects happen.  It’s a reality that all software has defects.  Defect free software is just software where the bugs haven’t been found yet.  This isn’t a fatalistic view of the state of modern technology. Or a capitulation to the inevitability of software failure.  To me it’s just reality. 

Software does more and more each day and therefore becomes more and more complex, skyrocketing the permutations of its use until it becomes impossible to guarantee it is defect free.   I think it’s possible to QA to a level where you have faith that your software is defect free one or two nines to the right of the decimal, but a 100% guarantee would be an out and out lie.  For most businesses the cost of QA comprehensive enough for such due diligence is too high as is the time involved to bring such software to market.

What matters when something does go wrong is the response.  Over the holiday break I experienced two very separate responses to defects that solidified in my mind what a good software company does when software goes bad.

Defect #1: While checking out of a major retailer I was using a number of gift cards I had received as presents.  Half-way through the transaction the retailer’s point of sales system (cash register for all you non-geeks) hiccuped (stuck it to the customer for all of you geeks) and my sale had to be voided.  All of the gift cards I had used suddenly had zero balances.  The store was unable to restore those balances and I had to wait a week before the issue was resolved, even after an hour and a half wait. 

Defect #2: Just as my patience with defect #1 was reaching its end I received a text that one of our clients was having a problem.  I drove straight from the retailer to our offices and verified the problem.  We’d paid three people wrong in a payroll file.  I verified the defect, checked the entire payroll file to find all impacted employees and then notified the client with my findings.  We then went back and checked every payroll file ever for any more errors and did root cause analysis of what had gone wrong.  It turns out we had a defect that impacted 0.005 of all transactions ever.  We tallied them up, gave our findings to the client, admitted our wrong and fixed the defect.  It was a bad day. 

The difference between defect #1 and defect #2 is simple: the response.  Defects happen.  I get that.  What I don’t get is a response that is anything other than 100% all hands on deck.  I wrote the particular piece of code that caused the three employees to be paid incorrectly (about $10 each).  There was no way I was going to let that defect live past sundown and no way we as a company would make the client wait for corrective action.  And definitely no way we wouldn’t be 100% forthcoming.

I’ve seen software companies ignore defects, hide defects and deflect culpability… everything imaginable.  That doesn’t work for me.  Maybe it’s my Midwestern upbringing, maybe it’s my belief in karma, maybe it’s being a good guy.  In HR automation when things go wrong the result can benign or not.  Time and attendance affects people’s pay.  If it’s broken it needs to be fixed.  Benefits integration affects someone’s well being.  Learning management might affect your performance management. 

My personal philosophy has been that you can tell more about a vendor (or a person) when things are going poorly than when things are going well.  Real character shows under stress.  So, when you are selecting a new vendor and doing due diligence ask a reference when the last time something broke was and then asking them what the vendor’s response was like.  It’ll tell you more about the quality of that vendor than anything else.

There are two phrases I hear a lot that I just don’t really like: The Customer Comes First and Controlling Customer Expectations.  Call me a rebel, but I think neither of those is a good thing.

The Customer Comes First

This sounds great and is a wonderful platitude.  It looks good on a marketing slick.  But it isn’t true.  In software what has to come first is the right people who with the right training and processes use technology and relationships to deliver the right product to the customer.  The customer comes second.  Not because we don’t value the customer above all else and not because we don’t want to provide the greatest customer service possible.  We do.  But before that can happen we have to have done the following:

·         Recruited the right people both for talent and personality

·         Motivated those people to achieve the level of service our clients expect

·         Trained those people so that they are as well equipped to do their jobs as possible and understand exactly what those jobs and associated goals are

·         Put in the processes that allow those people to work effectively and efficiently

·         Built the relationship among staff, vendors and clients to ensure open and honest communication

Once you have the who, what, how and why in place you can start to deliver to the client.  If you don’t do that upfront prep-work you won’t be putting the client first in any way because you won’t have the means to serve the client.  The product and the service have to exist before the client in order for the client to truly be served by the product.

It may seem obvious, but I have seen plenty of software vendors who want to build the features and functionality after they have the client base.  These same vendors generally talk liberally about controlling client expectations.

Controlling Customer Expectations

To me, it means you’ve gotten yourself into a place where the customer’s expectations and your reality don’t match.  If so, that means you’ve done something wrong.

My biggest brush with setting the wrong customer expectation came when I was working as a consultant for one of (what was at that time) the big five consulting firms.  Reporting for the first day at a new consulting gig I joined the client contact and his larger team in a meeting room.  During the meet and greet phase I was introduced by the client contact as having credentials I didn’t have.  During a break I called our technical sales rep and asked what was going on.  He’d made the consulting sale by flat out lying about my experience with a specific technology, years of experience and just about everything else.  I came clean with the client, explained what my real background was and offered to make the deal right in any way I could. 

In the many years since I have come to value a few axioms of technology sales:

Don’t’ sell what you don’t have.  If your software simply can’t do what the client needs be honest and tell them that.  Back out gracefully.  You might make the initial sale by lying, but you’ll find yourself between a real rock and a hard place when you can’t deliver.  You’ll alienate that client, all the potential clients they know and chances are you’ll alienate your staff as well.  Nothing is worse than getting handed an implementation that is destined to fail.

Don’t promise what you can’t deliver.  Maybe you and the client have agreed to a software enhancement in order to close the sale. It’s a common thing and your larger client base generally benefits from the new functionality and you generally get paid to add a feature you needed to add anyway.  Just make sure the timeline you offer up is one you can stand behind.  I can’t tell you how many times the sales guy (or gal) has pulled me aside after the sale and asked “is this doable?”.  Find out beforehand.  Client service isn’t just saying yes.  It’s saying yes knowing beforehand you can deliver and then delivering.  Don’t throw the greater organization under the proverbial cross-town bus by making a promise you (and ultimately they) can’t deliver on.

Don’t pretend to be what you’re not.  If you sell green widgets and your prospective sale needs orange widgets and you just can’t make orange widgets don’t pretend green is the new orange.  I’ve seen software companies completely distort who they are and what their product can do in order to make a sale.  Unhappy clients are not the way to fortune and fame.

Instead of “controlling customer expectations” I prefer “setting customer expectations”.  Go into the deal setting the right groundwork.

I don’t know about you, but I’ve never wanted to build a data center.  It’s a ginormous task that most people underestimate, takes months or years to do right and requires an expertise not found in your average corporation’s IT department.

I’d much rather let someone else worry about sonic rings, halon fire suppression, security cameras, biometric access devices, redundant power feeds, and so on.  I have always used a data center rather than hosting my infrastructure myself.  It solves a lot of problems and has a costbenefit ratio I find positive.  However, it does bring up one question.  Now that you’ve gone to the trouble to find the most reliable, most secure data center and have built a virtual Fort Knox around your hardware how do you get to it?

Essentially, what you’ll have to do it punch a hole in your security in order to give yourself access.  The question is how big does that hole have to be and how quickly can you close it if you have to?  Do you give every device in your environment a public IP address?  Do you create a VPN from your corporate network to the data center?  Both have drawbacks.  An external IP for every box is like leaving every window in your house slightly open when you leave and a VPN means your data center’s security has become only as strong as your corporate office security.  Usually there is a big difference between the two.

At Achievant each of our core modules (payroll, time and attendance, benefits administration and other HR automation) holds a great deal of sensitive data.  Keeping it locked down and secure is a task we focus on and revisit almost daily.

A solution I have used that works well for large or small environments is the idea of the bastion box.  A bastion box is a single server used for nothing other than providing a single door through which you enter to access all of the other boxes in your environment.  Obviously, some boxes (such as your web servers) will have public IPs, but using a bastion allows you to make everything else private and to hide it as deeply as possible.  It also gives you only one road in.

You can give everyone who needs access a login to the bastion and from the bastion they can SSH, RDP or whatever you like to the other devices that have private IPs.  Why is this good?  It allows you to control access through a single point.   That means you have fewer logs to inspect, viewer places to manage login privileges, user rights, etc and if a breach were to occur it gives you only one door to close to shut out the intruder.

All of the administration that surrounds access can be limited (largely) to this one box.  You’ll have logins on other boxes, but you can focus most of your attention on the bastion.  

While shoveling out from under the first real snow of the season on Sunday morning I couldn’t help but think about applicant tracking.  Ok, actually I was thinking about some hot cocoa and a steaming bowl of chicken noodle soup, but I needed an intro to today’s blog and took the literary license.  I hope you’ll forgive me. J

I enjoy writing applicant tracking software.  I even am the technical contributor for an ATS patent or two.  Knowing who is in your recruitment pipeline, what positions are open and having well defined, repeatable and predictable hiring workflows are all great things.  Clarity around the hiring process saves time and money both pre- and post- hire.  You can save time by automating tasks and weeding out unfit candidates early in the pre-hire process and can avoid wasted training and ramp-up time for bad hires post-hire by having a better vetting process.  There’s nothing worse than spending weeks or months working with a new hire only to have that new hire not work out.  At Achievant we have a four step interview process for technology candidates:

·         Step one is a personality test that measures things like work ethic, team orientation, flexibility, friendliness, etc.  It by itself is not a pass or fail hurdle.  It’s a tool we use to help the interviewer customize questions based on the apparent strengths and weaknesses of the candidate.  If the test indicates my candidate is a completely lackluster slacker who never finishes what he or she starts I am going to ask a lot of questions around that particular topic.  If the test indicates your candidate is a great team player who thrives in a collaborative environment I am going to drill into that.  The test is a way to get a leg up on understanding candidates and their personalities when face time is going to be limited to an hour interview.

·         Step two is a one-on-one technical screen and interview during which we use the results from the personality test to match up to the “gut” feel of the interview.  We also do a mid-weight technical screen to gauge the technical competence of a candidate.  The technical questions asked during the one-on-one are the same for every candidate and while neither easy or hard are used to gauge the candidate’s ability under pressure as much as his or her technical skill.  During the interview I let the client respond to technical questions using a white board.  I want them to be as engaged as possible and I want to see how well they can express an idea or concept.  I also want to put them on the spot and see how the handle that.  I always drill down to a level in each subject area until the candidate has shown either very deep technical understanding or is unable to answer correctly.  Seeing how someone handles such a situation is a great insight into how they will the pressure of real life development.

·         Step three is a hands on coding test during which candidates have one hour to complete what is essentially the coding equivalent of a word problem in algebra.  This gives us a great chance to see someone’s actual code.  We look for completeness, quality, efficiency and all the other hallmarks of good (or bad code).  At least several senior members of the team will review the code.

·         Step four is a meet and greet with the entire team with which a candidate will work if hired.  This is strictly a personality thing.  We want the candidate to get to know the team of which he or she will be part and I want the team of have buy-in on hiring a candidate.  A strong technical match is no more important than a strong cultural and personality match.  Hiring someone no one wants to work with will not get the job done.

A good applicant tracking system should be flexible enough to conform to different hiring work flows for different positions.  If you have a ten step process for hiring position X and a four step process for hiring position Y your ATS should accommodate that.  It should also clearly and quickly tell you where candidates are in the process, who a work flow is waiting on and all the other basic details one needs at their fingertips to adequately manage talent acquisition.

As an IT guy I see a lot of different applications of the idea of performance management: I manage the performance of the network, of the application, of the database and as a manager myself I am responsible for the performance management of staff.  I’ve always found that last type of performance management to be the most important. 

Having spent several years as the CIO of a very successful performance assessment HR automation company I am deeply familiar with performance management and performance management software.  I am a big fan of 360 degree feedback and 360 degree feedback software.  Getting the input of superiors, peers and subordinates is a great way to measure how you’re doing.

In short the HR application of performance management can be defined as establishing the definition, communication and measurement of predetermined individual and collective goals that further the greater corporate goals as set forth by a business.  Giving appropriate attention to this kind of performance management has allowed me as an IT leader to achieve the performance management of those IT related metrics because my staff is aware of our objectives, how we’re tracking against those objectives and how their individual goals fit into the bigger picture.

There are a wide variety of performance management tools.  Below are some of the steps I have found useful in my career as an IT manager to help keep staff aware of goals and the progress against those goals:

·         Informal, frequent and clear communication of objectives and progress.

o   In projects were immediacy is paramount (especially if there are a lot of moving parts) I have (sometimes daily) 15 minute standup meetings were a leader from each stakeholder discusses their progress against very specific project related goals.  We also discuss roadblocks, needs and successes that are either preventing us from getting where we need to go or that have helped us get there.  This has helped keep us all on track and moving as a single entity toward a well defined goal.

·         Informal, semi-frequent performance reviews.

o   On a less frequent basis I will meet with each employee and go over broader short term goals and how those goals are progressing.  I do this in a generally informal setting and use the opportunity to ensure clear understanding of goals and status.   During these meetings I make sure there is a “meeting of the minds” on the metrics that will be used to measure goal progress and a clear understanding of the goals themselves and their associated deadlines.

·         Formal, scheduled review of objectives and goals and overall performance.

o   These I have traditionally held twice yearly and involve (at least for me) 360 degree feedback.  During these performance reviews I take the opportunity to more formally recognize progress (or sometimes lack of progress) against objectives and involve at least some members of the larger organization.  I make sure that in the 360 degree feedback the widest range of (as appropriate) business units and people are involved.  During this semi-annual reviews I’ll also cover non-goal related performance such as attitude, effort, etc.

In order for a group to achieve any goal that group has to understand what the goal is, how it is going to be achieved and who within the group is responsible for what.  I am a huge fan of getting everyone on the same page, creating clear task assignments and then measuring our progress against those tasks.  Having a well draw map and knowing where you are on that map will generally allow you to get wherever you want to go.

Today I am going to take a step back and dial down the detail a level of magnitude or two and talk about what HRIS Software is and what it can do for you.

HRIS, or Human Resource Information Systems, is generally a collection of software modules that help accomplish four specific functions:

1.       Payroll

2.       Time and attendance

3.       Benefits administration

4.       General HR management. 

A strong HRIS system may also cover learning management, performance management and other HR automation.

Payroll: the payroll module should take all of the tasks surrounding employee time and attendance and automate it.  This will include direct deposit information, time and attendance, off-time requests and tracking and all of the small nuances that go into recording employee time and reporting on it.

Time and Attendance: the time and attendance module will automate collecting and managing employee time and labor information.  It should have automated process for requesting time off, tracking time off usage and accruals, calculating overtime and tracking hours worked.  It should have workflows processes for approving or denying timesheets, approving or denying time off, etc.  It should allow all levels of management and employees to have a transparent view of their off-time plans, holidays and hours worked.

Benefits Administration: the benefit module should allow employees to opt in and out of benefit plans, record dependents, record beneficiaries, track coordination of benefits and integrate to a company’s benefit carriers as well as other benefits related tasks.

HR Management: the HR management module should cover a wide variety of HR automation.  It should record all of the personal information one collects on employees, allow for pay raise workflows, bonuses, commissions, transfers, all of that day-to-day HR work that happens inside any company.

Some HRIS Software will have modules for applicant tracking, performance management, learning management (aka: training) and other common tasks.  A good HR Automation package should serve an employee’s HR needs from application through retirement and at all points in between. 

At Achievant we have all of these modules in our HCMS (Human Capital Management System).  We are constantly evaluating, expanding and adding to our functionality as the HR workplace grows and changes.  In fact, one of the reasons we created our blogs was in order to communicate with other HR professionals and generate an on-going dialogue of what is and what is not important in HR software.

One of the bigger challenges I see IT leadership facing is participation by other business stakeholders in product development.  Since IT is generally where the rubber hits the road and nifty ideas become reality the IT folks sometimes get left holding the bag for half-baked initiatives.  The next killer app can sound great in a sales and marketing meeting where a 100,000 foot view is as deep as it goes, but when the nuts and bolts need to get tightened down you, the IT leader, can find yourself in a ghost town of partici