Hidden Costs of Contract Hiring

I wrote this today in response to another article more favorable to contract employees as a resource alternative. Because I've both worked with contract employees and been one myself I thought my perspective offered insight that was lacking in the other article. I'll try to cite the original piece if I remember.

Contract Hiring is touted as a remedy for an uncertain economy and high costs associated with hiring permanent employees. For some companies this can be true, but there are situations where the hidden cost of contract employees can far outweigh the benefits of hiring an employee on a permanent basis.

Benefits and Drawbacks

For businesses whose work functions are highly standardized and those who have kept pace with the changes in current technology and workforce, contract hiring can be utilized most effectively to achieve a desired result with cost savings. For others, contract hiring can easily be oversold as offering the following benefits.

Agility: Today’s business environment is characterized as fast-moving, quick to change, and requiring companies to be “responsive” or even “agile”. Contract hiring promises a “quick fix” to the need to rapidly shift business functions, by making available a wide variety of expertise from the “agile” contract workforce.

HR Cost Savings: A contract employee does not require benefits such as health insurance, paid vacation, sick time or other perks associated with full-time employees. In addition costs associated with recruitment purportedly are minimized, as are severance costs.

Training Cost Savings: A contract employee can walk in off the street, sit down and begin working.

Risk Management: Because contract employees do not work for the company directly, liability for business risks can be spread or externalized.

Productivity: Because contract employees work in commoditized areas, theoretically they can “hit the ground running”, arriving with the needed skills in place. In addition they can be hired and released in whatever numbers are needed to complete a project in a particular timeframe.

Focus: Contracting out “non-essential” functions provides a way to allow permanent employees to concentrate on the essential parts of their jobs, to the extent those can be separated.

Barriers to Successful Contracting

For all of these benefits to be realized certain background assumptions must be addressed beforehand. As with most rational activity, successful planning is the key to achieving successful outcomes.

Standardized Processes and Technologies: In order to find a contractor with a particular skill set, it goes without saying that the needed skills must be available in the marketplace. Companies and departments whose internal processes are “home-grown” or ad-hoc may find it difficult to articulate their exact requirements to those outside the immediate area. And companies leveraging obsolete or uncommon technology platforms tend to have a large number of adaptive legacy business processes that increase training burden required to make any new employee effective, whether contract or full-time. Worse, an ad-hoc business process employing a standard technology may lead to the impression that a standard skill set should be sufficient to understand the unique local parameters of the job.

Failure to Plan: Does the hiring manager understand the exact requirements of the job? Can the necessary knowledge be transferred to someone who walks in off the street with no understanding of the company, its policies and procedures, or its culture?

Lack of Process Orientation or Understanding: The inability to see your business activity in terms of processes is a sure indicator of the difficulty a contract employee will have learning what is needed to do a successful job. If the contracted function contains a large number of inputs or near-upstream variables, this may indicate that a sub-function may need to be developed for contracting purposes.

“Quick-fix” mentality: Often an employer relies on a contractor to think creatively how to fulfill the requirements of a job, especially in situations where manpower is constrained and deadlines are close. In this situation the employer runs the risk of cost and time overruns as the contractor struggles to fill in the preparatory work needed to understand facets of the job that should have been explained up front. In addition, the risk of failure is increased by the arms-length relationship that contracting entails: the contractor knows the job will end with the contract term, and will be prepared to leave at that time, whether the work is completed or not. The liability for flawed or broken processes can hinder the success of a contract relationship, but unlike internal liability for completing a project cannot ever be shared with a contract employee.

Variations among Contract Employees: no two contractors are alike. Some are highly skilled, some less, some are professional and service-oriented, some individualistic and indifferent to the needs beyond the stated job description. Some have more people skills, some more technical skills. These human factors cannot be specified in a contract to the extent needed to make a difference. A job relying on any of these personality traits—and most do—may need to bring in several different contractors for the same position before a good fit can be established. Not only that, the more competent and professional contractors tend to be in greater demand and therefore less available than those less stellar performers.

Solutions for Successful Contracting:

Know your business: Managers who do not understand their own business processes cannot rely on contract employees to fix them. Identify the areas of your business most likely to require additional temporary resources, and invest time in activities such as process mapping or risk assessment to evaluate whether the jobs are ready to be handed off to a contractor.

Know the contract market: Some skill sets are readily available, some are harder to find, and some are virtually impossible. An informal survey of potential contract firms can help assess what functions can be contracted readily, and at what cost.

Establish relationships: A mutually beneficial relationship with a contracting firm is characterized by the same features as a good relationship with any other supplier, or with a customer or an employee for that matter. A sense of common goals, mutual understanding and good communication cannot be commoditized, but must be developed through repeated interaction. This is where a full-time employee justifies the additional cost devoted to recruitment, development, and other employer commitments—unlike a contract employee, a full-time employee has a vested interest in the continuing success of the employer.

It takes additional commitment on the part of management to achieve a level of trust and responsiveness with contract firms or, even better, with a set of contractors themselves. Initially it is important to establish rapport with contract service providers. Beyond simply knowing the skill sets they offer, it is important to gain a sense of their commitment to satisfying your needs. Do they respond promptly to your communications? Do they answer your questions? And for your part, is your business likely to be a good customer for them in the future? Do you understand your own needs and requirements? Can you articulate what is important to you? These are the kind of informal benchmarks that indicate potential for a successful contract relationship that lives up to the promise of an agile resource base available at a competitive cost.

A Guide to Process Mapping for Managers, Workers and Casual Observers 5/15/09


Process Mapping Exercises are a management technique for “getting a handle” on an area of the business. In the hands of a thoughtful person the technique can be a useful tool for understanding. The point of the exercise is usually said to have something to do with improving execution of business processes.


Most of the time the process goes something like this.

1. Meetings
2. Process Maps Are Created
3. Process Improvements Occur, Managers Achieve Results
4. Problems Resolved, things return to normal.


Let's look more closely at how this works. First, though, some background about the idea of processes themselves.


What is a Process?

“Process” refers to just about anything that happens anywhere. Because the term is so adaptable it is very useful as a conceptual framework for managers, auditors, and really just about anyone. If it sounds like some kind of fancy manager-ese talk, well, that's because it is.

But like anything other pair of glasses, you have to choose a particular frame over other available choices, and while it shows you some things in focus, other things get distorted. Some of the benefits and drawbacks of process-oriented thinking are these:

* Linearity. One thing happens, then another, then another. Processes work well when the real world is like this, as on an assembly line. If events all happen simultaneously without one depending on another, as when a bunch of people with different jobs need to do some work separately but still talk to each other sometimes, trying to force the situation to appear as a process causes the process mapper to believe the situation is out of control, even if in reality things work very well.

* Not Person-Oriented. In a process it does not matter who does what job, whether they're good at it or not, or even whether they sometimes do not show up for work. Process thinking assumes people are an interchangeable commodity performing what we call “functions”. Basically, you're a robot that can be programmed to put car doors on cars, tighten bolt number 123-A26 to 6.25 ft/lbs, or send an e-mail to 3 different people's bosses when you get a phone call from robot number 20500X in Human Resources. In reality, work flows much differently when one person fills in for another, or when a person is called away to address some other situation that needs their expertise, or even on different days of the week. Besides that, a lot of the people I've worked with want to make decisions every now and then, and consider themselves conscious agents. People don't really like to be robots.

Of course people do like to have regular, predictable jobs, and do expect someone to define what is expected of them. And processes are abstractions of particular tasks people are expected do, not exhaustive descriptions of who they are. But this distortion can sometimes cause the process mapper to miss a crucial dependency or two.

* Not Time-Oriented. Time is an important factor in business. Process thinking often fails to take time measurement into account, so every operation is similar to every other one. This can lead to leaving out time-based process steps that occur in the real world, such as waiting for something to happen.

* Gödel's Theorem. Another word for “process-oriented” is “systematic”, that is, believing what you do is an organized and orderly System. That's great if you actually do it. In the real world businesses tend to be more messy than that: conditions change, exceptions happen, people and departments must react to events that (oh, no) management has not planned for. This tendency of systems to not really nail down every aspect of the real world is called “openness”. Systems that acknowledge these limitations and are intended to adapt to changing conditions are called “Open Systems”, but those that do not have this understanding are just called “systems” (You can possibly notice the evolutionary sequence there.).Openness is really not a problem in itself, but it leads to two problematic outcomes: first, managers and other people who do not understand systems very well react to openness the way most people naturally and rightly react to difficult problems: first by digging in and struggling to deny the difficult reality, then by strategizing to either get rid of the problem or merely escape to a comfortable conference room with soft chairs. The second problem with openness is that it leads the less fearful managers to think that systems and processes cannot possibly describe the real world, so it makes no sense to even try understanding anything this way. While it might appear to be a “realistic” attitude, this approach can be even more dangerous when you think of its implications. The obvious question that nobody asks is “then how is it you put the pieces together?” and the answer usually is either something like “um. I dunno” or “well, you see, I think in realistic terms, and those crazy things other people try to do just don't ever work.” In other words, My Way or the Highway. And what those “realistic” terms are either must be too complicated to explain to anyone else, or must be “however I happen to put things together at the particular moment.”


But returning to Gödel and his theorem, the point is that systems and processes do actually work to describe the real world if we observe, as the old mathematician did, that a complete system cannot be closed (what I described above), and a closed system cannot be complete. Nobody thinks much about closed systems today, but they should. A good process map may describe a closed system. It shows what happens in a particular situation, from beginning to end. And it is incomplete. That is, it does not mean to describe everything that ever happens or everything that could happen. Just a set of ordinary conditions. The truck arrives at the dock, the boxes are received by the receiving clerk, the parts are unpacked and entered into the computer, the receiving clerks put them on carts and take them to wherever they're supposed to go, and so forth.

Process Mapping in Ordinary Organizations

In the hands of most managers, process mapping is a powerful weapon that confers authority and righteousness on the person that wields it. Process mapping sessions can cause great annoyance and even fear in the hearts of workers who are trapped into participating in it. Process Mapping is a precursor to the thing managers attend seminars to learn how to force on their organizations: the dreaded “Change”. Here is how the process of process mapping works, why it should be feared as a disruptive and burdensome activity by those unlucky enough to be caught up in it, and what to do if you are caught in that situation.

Step One: Meetings.

Like many Change initiatives thought up by management, Process Mapping begins by assembling a team. The stated purpose of the process mapping team is, naturally, “Process Improvement.” The idea that things could be better is how the hook is baited for the naïve participant. For most people the real motivator is the directive that “you have to do this.”Then there are others who seek personal gain from the exercise, and it is those people that you have to watch out for.

The process mapping meeting begins innocently enough. The manager or consultant in charge typically thanks everyone in advance for participating. They talk about how they are not down “in the trenches” every day and would like to get a better idea how things really work. Then comes the kicker: they want you to teach them what you do, so they can possibly help make things better. The smarter ones will tell you that it is the group assembled in the room that will gain the insights to help make things better, not the manager or consultant.

The temptation to participate in the exercise rather than to run away as fast as possible comes from the implication that management supports this effort. In fact there are some actual benefits for the person who keeps their eyes open, which I'll discuss.


Step Two: Mapping the Processes.

The manager or consultant now goes through the mapping exercise, which consists of describing the day-to-day work in process terms and creating charts for each process they've identified. In organizations not accustomed to process mapping it can be a little unnerving to see the work you do stuck onto a chart full of little boxes and arrows connecting you to other people and their work. There are some good reasons for this, but for now we go on with the exercise.

If a person is familiar with flowcharts, they'll know there is a standard set of symbols that are used for representing the different kinds of operations in a process. Few people know or use them all, but generally the important ones are these three:
o A rectangle , which represents an action or function (e.g. “scan the item with the barcode scanner”).
o A diamond , which represents a decision, usually a Yes or No decision (e.g. “does the part meet the tolerance?”).
o Arrows, which join the different shapes together and represents a time sequence or flow of events.

So




This is basically how process diagrams look. In themselves they are no cause for alarm, and may even be useful for getting a description down on paper for a group to look at. Using a diagram ensures that everyone is looking at and talking about the same thing, which is desirable if you are working with people who will actually help you solve a problem instead of making things worse.

So the key part of process mapping consists of creating these diagrams that show everyone how things happen on a normal basis. From there, the story goes, the manager / consultant and the team will look at the diagrams and brainstorm about how things could be made better or more efficient. This sounds good, and often it happens this way, and actually leads to improvements. But in an entrenched organization this is not the whole story.

On the Chart and Off the Chart

There are parts of a process which never make it onto the diagram. You see people's tasks, work operations, process decisions, and a wide array of other activities. You never see management activities or certain other kinds of disruptions in a process diagram. Process thinking is a rational process, and by nature an incomplete process. This incompleteness is not a problem, but what is a flaw in this method is its bias toward what is functional and rational and against anything that is not. Problems always get framed in terms of what shows up on the chart, and anything caused by time or personality factors will likely be ignored.

Another unfortunate side effect of a process approach is the tendency we all have to idealize processes, that is to draw our diagrams to show how we think everything “should” work, with no variation for time, work volume, or personality considerations. I do this. He does that. She does this other thing. Simple. But if only we really could work this way. When we idealize processes we tend to think it is wrong for us to deviate from acting like the parts of a machine. Looking at the chart we feel there is moral benefit to becoming robots. Shut up and do your job. Think on your own time. Or do the work unconsciously with one part of your brain while you're living your life with another separate part, like talking on the phone while you're driving a car, paying only enough attention to not crash but never enjoying the drive.

For routine work instructions process thinking is at its most useful. For problem-solving it has disadvantages. If problems always are stated in terms of what is on the chart, and all that is on the chart are the ordinary things people do in the course of everyday work, what is likely to be available as a solution? One of two things: reshuffle the boxes and arrows so things happen in a different sequence, or perform surgery on the parts of the process we identify as problematic.

Once the process has been diagrammed and described, somehow it is used as a basis for discussion of what works well and what does not. How this materializes into problems and solutions depends greatly on things that are not on the chart. The personalities and working relationships within the group are a major factor in its ability to use the process mapping opportunity to really address systemic problems and create solutions. Just as important is the degree to which company management will support the solutions the group offers. At both levels, within the group and between the group and the organization's higher-level decision-makers who sponsor the exercise, trust is an important component of ultimate effectiveness of shared effort to effect systemic change. Trust is at the root of effective communication, and is the basis of commitment.

Trust is a mental state that cannot be dictated by management but must be developed organically. Functional or superficial trust is the most common kind and is effective for maintaining most work relationships. Often this kind of trust can be assumed, as when we assume a person who shows up for work on time their first week on the job will continue to do so on most days thereafter. Trust comes from life experience and the way our brains work, assuming that if a pattern becomes familiar then it is also reliably predictable. It can be confused by a naïve person as a permanent state that can be counted on once it is promised. “You said you'll be my friend and never do me wrong, so I trust you.” But when a person's naïve trust has been betrayed a few times, the same mental habit of predicting future events from past patterns creates another related mental state that is more difficult to betray: mistrust.

We can show up at work every day believing that it is in our best interest because of an important factor reinforced by functional trust: every two weeks or so we are given the assurance that no matter what happens day-to-day, the organization will reward our sacrifices. This assurance comes in hard material terms in the form of a paycheck. As long as the payroll cycle is not disrupted, functional trust can be maintained with nearly everyone in a business organization, without exception. Whether well- or poorly-paid, each of us can count on regular income from our work, and this cycle is a powerful reinforcer of trust. For purposes of process mapping, payday is always off the chart.

For managers to continue to pay their workers a certain amount of functional trust is necessary as well. Managers expect a number of repeated behaviors from the people who work for them, which leads to reliability, another word for predictability. These include showing up to work, doing the tasks described in the job description or other instructions, reacting to situations in a socially acceptable manner, and so forth. Because upper managers rely on middle managers to get work done by the people who report to them, and people throughout an organization must rely on the predictable work of others to assist them in performing their jobs, functional trust is created and maintained throughout the organization. Another name for all these kinds of trust is security.

In addition, because neither people nor the conditions they work in are always perfectly predictable, functional mistrust also exists simultaneously in organizations. A great deal of work goes into maintaining positive trust over negative mistrust, but in either case if people can reliably predict what is going to happen they feel secure in their day-to-day lives.

The relationship between process mapping and the various kinds of security is easy to understand. Process mapping initiatives signal healthy mistrust from management, and is likely to be met with equally healthy mistrust from people in the organization whose processes have been designated for mapping. Care is taken to ensure that this mistrust is wrapped in innocuous terms. Appealing to a mutual interest in “making things better” is the most basic presentation technique for this – it's not the people in the organization you mistrust, but something harder to identify. Process Mapping in this sense appears as a tool for shining a light into this darkness and maybe spotting a demon or two that can be exorcised. It works well for this because a process diagram is not difficult to create and appears to be an objective, mutually agreeable device to look at everyday work as we all believe it is or should be. In short, it is a tool that can be trusted. But as I have described, it can simultaneously and rightly be mistrusted.

Step Three. Improving the Process.

Regardless of what the diagrams indicate, the ability of participants to work together or their inability to do so, combined with the same ability of an organization's decision-makers will determine whether or not the process mapping is likely to succeed or fail at improving the lives of those in the organization. However, a few things are clear about process mapping.

- It diagrams everyday work as it is or as it is idealized.

- Problems can only be identified On-the-Chart.

- Off-the-Chart problems will be ignored.

- Solutions must be developed On-the-Chart.

A few other things come into play:

- A process mapping exercise indicates management's expectation of solutions. It is usually unacceptable to fail to come up with any beneficial outcome.

- Those who participate in the exercise have some amount of power to provide for their own security by producing some kind of positive outcome.

- Nobody wants to be identified as the “problem”. But by working together we can all keep things as they are and provide security for each other.

- Those whose activities are contained On-the-Chart are at risk of blame. Therefore it is in their best interest to participate in the exercise if allowed to do so, in order to avoid blame.

- Process mapping can make people in an organization aware of what others in related areas do, and this can be helpful to improving their interactions. If they already know what each other do, the exercise can sometimes refocus individuals' attention beyond their own area of work and toward the larger picture that includes those around them.

- The beneficial outcome sought by management can be as simple as team-building. If everyone feels good about participating in process mapping and it can be stated that the exercise was worthwhile, contributed to everyone's better understanding of what they do, or such like, then it can be considered a success.

So whether or not process mapping allows for the solution of the real problems that systemically hurt an organization, it can improve the working relationships of people within that organization by simply building awareness. Ultimately, though, the manager or consultant who led the exercise will take credit for its inevitable success, will be rewarded by some kind of superficial recognition and trust, and will ultimately earn the right to do more work. The members of the process mapping team can feel a degree of success, avoid blame, and ultimately will go back to a world not very different from the one they left for the process mapping meetings. But there is still one possible issue to be addressed.

Step Four. Implementing the Changes

If a process mapping team somehow manages to propose a substantive solution to a process issue, there may be a price that someone must pay. The solution will need to be proposed to upper management.

The manager or consultant who led the team is the natural person to handle proposing the solution. But then there can be an even more worrisome outcome: management approval, and resulting implementation. Fortunately, most organizations are insulated against such change by systemic factors: management was not involved in the process mapping exercise that identified the problem, and so are unlikely to understand the importance of the issues that led to the diagnosis, regardless of how serious they are. Further, management is likely to be biased toward its own agenda, which did not plan for the problems in the first place, and which would require some amount of difficult work by management to take these problems into account. In all likelihood management will consider the problems carefully, give some thought to whether the independent team's impression of things matches their own, and if not will craft a cleverly worded solution to thank the team for its work at making the organization better, promise to take their findings very seriously, and explain away any further requests for action.

Good process diagrams likely will be no help, since their scope is limited to an idealized version of the work. Bad process diagrams, with long criss-crossing arrows, confusing complexity, and imprecise terminology are better at expressing the existence of problems, but are never clear about what the problems are.

In the unlikely event that the process mapping team's work results in further management-sponsored improvement initiatives, implementation responsibility likely falls on those who are close to the situation, possibly the original process mapping team itself. Those people, especially the manager or consultant who led the whole thing originally now open themselves up to fresh new mistrust from everyone whose work they once so innocently placed on the chart, indicated by boxes and arrows. But that story is for another discussion and another day.

Until then, here are some points to remember:

Employees' Guide to Process Mapping

1. If there is anything you like about your job, keep it off the chart.
2. Rewards are never assigned for anything that appears on a Process Map.
Embrace Change – you have more to lose from failing to participate in process mapping than you do from participating in it. So be supportive of Management's interest in “improving” your work environment, but not so much that you get put in charge of the Improvements.