Category: corporate policies

Do You Demand Flowers From Your Staff?

What are you supposed to buy for your wife for Valentine’s Day? Quick, first thing that pops into your mind …

Right: flowers. A dozen long-stemmed red roses. Because decades of consistent marketing has worked its magic on you. You could debate that it should be a box of chocolates, or jewelry, and I’d say that’s because those two industries have been advertising just as hard.

But have you noticed the hidden assumption? That you’re “supposed to” buy something at all. No matter how aggressively the flower, candy and jewelry industries market against each other, none of them will ever contradict this fundamental belief: That extravagant purchases are the approved way to demonstrate commitment.

Most modern American corporations expect you to demonstrate your commitment, too. But instead of flowers the symbol of your commitment is time. Time above and beyond the forty hours you’re supposed to work. Time eating at your desk instead of going out to lunch. Time on call via the Blackberry they gave you.

Doing good, steady work is better for the company. But late-night marathons of work get noticed. If you plan well and execute, you don’t need late nights, but then there’s never a clear moment for the boss to look at and say, “That moment really showed commitment.”

In a perfect world, the boss would take the extra effort to recognize good, steady performance. And that’s exactly what it takes: extra effort. Which is why it happens so rarely. Even if you’re doing things on time, it seems that sometimes you have to put in the late night to get noticed. Because this isn’t a perfect world.

But you may be in a position to make the world a little better. If you are the boss, make the extra effort. Publicly recognize employees who reach their goals during normal working hours. Make it clear that late nights are a symptom of poor planning. Demand extra work because it needs to be done, not just to show commitment.

It may be less exciting, and less obvious, but in the long run it’s much more productive.

How corporations spin a risk into a benefit

James Maguire, managing editor of Datamation, wrote in “Indian IT Firms: Is the Future Theirs?

“In the past, companies used to award IT outsourcing contracts that were longer, 7-10 years. They would hire one firm to do it, and that firm would have subcontractors,” Ford-Taggart says. Now, big clients split up major projects and request bids on individual components. “Then they’ll say, “Look, we can have this portion done in India for 30% less.'”

This might cause more managerial headaches for the client company, but in fact it’s less risk: clients have fewer eggs in a basket with any one IT firm, so if a projects goes bad or creates cost overruns, the entire project won’t take such a big hit.

Emphasis added.

I hate this corporate executive definition of “risk”. And before you think I don’t get it, I understand what they mean but I think they’re wrong.

When I talk about reducing risk, I mean that I’m making problems less likely to occur. What the execs mean when they take this position is that they’re diversifying the accountability. They want to be able to report that while 20% of the project is at risk, the other 80% is on track.

Well sure, the other 80% can’t be used without the 20% that’s missing. But the focus here should be that we’ve got 80% of the project on time and on budget!

If you admit up front that your process is increasing management headaches, you should realize you’re increasing the likelihood of problems. You may be mitigating the potential impact, but that’s not a given.

Any mitigation strategy that seeks to reduce the impact of a failure, and does so by increasing the likelihood of failure, is probably a bad idea.

Drug Testing as a Job Prerequisite

This topic comes up often enough online that I figured it would be more convenient to just lay out my thoughts on the subject once and point people to it. So here goes:

  • Most companies use pre-employment drug testing to filter people out because they don’t have any good performance-based measurements they can use. If they knew how to directly evaluate a potential employee, they wouldn’t need artificial criteria.
  • Some companies have a legitimate need for pre-employment testing: hospitals, pharmacies, chemical labs. Jobs where people will have unusual access to drugs or their components.
  • There are some jobs where you clearly don’t want someone working under the influence: bus drivers, teachers, etc. But if you’re going to make that argument, doesn’t it make more sense to do random screenings after they’re employed?
  • Some jobs have an inherent conflict with drug use: law enforcement. Enough said on that one.
  • As a job candidate, I would prefer that a company’s policies aligned with my own. But I recognize that most HR policies are about balancing various legal liabilities, and have little to do with the day-to-day business culture. So yes, I’ll take a test if they want one.
  • As a potential employer or hiring manager, I prefer not to know what an employee does when they’re away from work. But if my employer’s HR department requires a test, that’s the policy I’ll tell any candidates.

How to Fail by Succeeding

Dave Christiansen over at Information Technology Dark Side is talking about perverse incentives in project management, which he defines as:

Any policy, practice, cultural value, or behavior that creates perceived or real obstacles to acting in the best interest of the organization.

One class of these perverse incentives comes from the methodology police. These departments exist to turn all processes into checklists. If only you would follow the checklist, everything will work. But more importantly, if you follow the checklist you can’t be blamed if you fail.

How’s that for perverse?

A great example is that there is rarely any incentive to not spend money. Before you decide I’m out of touch with reality, notice I didn’t say “save money.” I said “not spend money.” Here’s the difference.

IT by the numbers

Let’s say you do internal IT for a company that produces widgets. Someone from Operations says that they need a new application to track defects. If you follow the checklist, you:

  • engage a business analyst, who
  • documents the business requirements, including
  • calculating the Quantifiable Business Objective, then
  • writes a specification, which is
  • inspected for completeness and format, then
  • passed on to an architect, who
  • determines if there is an off-the-shelf solution, or if it needs custom development.

At this point you’re probably several weeks and tens of thousands of dollars into the Analysis Phase of your Software Development Lifecycle. Whose job is it to step in and point out that all Ops needs is a spreadsheet with an input form and some formulas to spit out a weekly report?

Let’s put some numbers to this thing.

Assume the new reporting system will identify production problems. With this new information, Operations can save $100,000 per month. A standard ROI calculation says the project should cost no more than $2.4-million, so that it will pay for itself within two years.

Take 25% of that for hardware costs, and 25% for first-year licensing, you’ve got $1.2-million for labor costs. If people are billed out at $100/hour – and contractors can easily go three to four times that for niche industries – that’s 300 man-weeks of labor. Get ten people on the project – a project manager, two business analysts, four programmers, two testers, one sysadmin – and that’s about seven months.

If everything goes exactly to plan, seven months after the initial request you’re $2.4-million in the hole and you start saving $100,000 per month in reduced production costs. Everyone gets their bonus.

And 31 months after the initial request, assuming nothing has changed, you break even on the investment. Assuming the new system had $0 support costs.

But what if …

Way back at the first step, you gave a programmer a week to come up with a spreadsheet. Maybe the reports aren’t as good as what the large project would have produced. You only enable $50,000 per month in savings. That week to produce it costs you $4,000 in labor, and $0 in hardware and licensing.

You are only able to show half the operational savings, so you don’t get a bonus. You don’t get to put “brought multi-million dollar project in on time and on budget” on your resume.

And 31 months after the initial request, the spreadsheet has enabled over $1.5-million in operational savings.

How to Finish IT Projects Faster with Less Documentation

If you’re responsible for running an IT project you want things to be done on time and within budget. So how do you set your schedule and budget? Hopefully you define what you want to accomplish, and then ask the developers how long it’s going to take. If you’re putting out a request for proposal (RFP) you’ll have several different answers to that question. Typically the highest consideration in the selection is the total proposed cost. But really, the total time is a better choice.

Why that’s true is based not on ideas about processes, but on ideas about people.

Consultants live and die by billable hours. In the short term, they don’t have any incentive to finish their current project any faster. But in the long term, finishing faster should lead to more work as clients come to respect their ability to meet a deadline. If project managers and clients learn to value that behavior, that is.

How it Could Be

Let’s look at a production support issue for an example. Production support is completely different from most project work in one very important way: the problem is well defined. Something worked on Monday, it doesn’t work on Tuesday. Make it work just like Monday again.

For something with six-figure impact per hour of downtime – and if you think that’s an artificially-high number you’ve never worked with credit card processing – you don’t want a programmer with an impressive resume, dozens of certifications, and decades of experience with your primary programming language. You want Bob, the guy who wrote the system from scratch and demands $1k per hour with a four-hour minimum.

Once you’ve got Bob and his hand-picked team of support people, you get out of their way and let them work. Status reports might be no more than, “We’ve found the problem … We’ve identified the solution … We’re ready to test the fix … It’s live.”

How it Is

But when it comes to new development, companies play it “safe” and look for the best qualifications on paper. They hire based on keyword matching and offer rates based on industry standards for a given skill set. They require specific processes and deliverables (pet peeve: when did “deliverable” become a noun?) and status reporting becomes a significant percentage of the total budget.

Why the Difference?

There are two reasons expert teams get away with less formal process than is typical, but I can only prove one of them. The public answer business sponsors tell themselves to justify the exception to “official methodology” is that the experts have worked the methodology for so long that they can follow the same procedures without exhaustively documenting all the steps. And there is some truth to that.

But I suspect the larger reason is that experts get the work done so much faster there just isn’t enough time for documentation to build up.

The best athletes make things look easy that most people could not even do. A high jumper might clear six feet without even trying hard. Most people would never come close even with months to try.

The best IT people do the same thing. They complete projects in weeks that other people could never do. As “safe” projects drag on specifications are refined, status reports are produced, contracts are negotiated, updates are requested and provided. Meanwhile the expert team has just released to production – so it must have been a small project.

The hard part for the client is to recognize the difference between a project that went smoothly because it was easy, and one that went smoothly because the team made it look easy. But here’s the secret: You don’t really need to recognize the difference.

How to Do Better

The reason you hired someone else to do the work is because you couldn’t do it yourself. Which means you can’t accurately judge which projects really are hard, and which ones just look hard. So don’t judge the project, judge the people.

The people who seem to always be working on small, simple projects – after all, they always go quickly with no major problems – are better at execution. They will be better no matter what the project is.

Installing software is not worth my time

My PC is managed according to corporate standards. I can’t install anything without an administrator signing on and authorizing it. I asked if I could install the software to link to my cell phone and load my contacts into it. Otherwise I’d be spending a couple of hours over the next week manually entering them all in via the keypad.

The day after I put the ticket in, someone called up and asked where the software was. I told him I had it on a CD. The local support guy came up the next morning, saw that it was an OEM disk and not some random thing I’d burned, and logged in as administrator so I could install it.

Sure, it was two days before I got what I needed, but it wasn’t a compelling gotta-have-it-today issue.

Everything else on here is available as a network install, and is set up in my profile. When I get a new PC — I’m due to be refreshed in the next month or so — I’ll go to a single application, check the boxes for everything I need, and go to lunch. When I come back, everything will be installed.

Every application that I install myself I’d have to reinstall when I get a new PC. How many hours would that take? Multiply that by the number of users in my office, which just relocated earlier this year. Most of us didn’t take the hardware from the old location, we just came to blank systems at our new desks and kicked off the install process.

If I’m paying for it, it is not worth my time to install software. If my alternatives are to load all my apps on a new PC I’ve just bought, or to work a billable hour and pay someone else to do the installs, I’ll pay the Geek Squad to click OK and reboot 14 times. Why should I expect the company I work for, who owns the PC I’m working on, to make a different decision?