Consulting isn’t the glamour job that a lot of people think it is. Sure, you may get to travel and learn new things, but as anyone who travels a lot will tell you, it can be a bit wearing after a while, and you find yourself suddenly hankering for the most basic of simple meals after weeks at a time of hotel or restaurant food.

Nor do you do consulting for the fame. Sure, good consultants will get reputations in their fields, but we’re hardly household names (except maybe in particularly niche/geeky households). Undoubtedly I think the best consultants start with a passion for their field and a desire to learn as much as possible, but this will only get you so far. There needs to be something else to prevent burn out and to allow for personal growth.

I’ve been extraordinarily lucky to develop and keep long term customer relationships, carrying customers between my last company (which collapsed) and my current company, and equally having customers carry those relationships with me from one company to the next. At one level, they remain customers – but at another, as you’ve been working with certain customers year in, year out, you realise that the true value of consulting is the people you’re doing the consulting for. It’s not about being able to solve problems and challenges for companies that you deal with, it’s about being able to solve problems and challenges for the individual people you deal with. The first just pays the bills; the second one is what gives you the job satisfaction.

In the past couple of weeks I’ve had a few people I’ve been working with for years advise me that they’re moving on to other endeavours. It’s always at this time that I pause to think about the core reason I do this job: to help people.

 

While much of business has moved into the twenty-first century, one thing that continues to demonstrate a profound stuck-in-the-80′s mentality is the demand for on-site work. To be sure, there are some levels of work that have to be conducted on-site. It’s somewhat challenging to do hardware work remotely, for instance, unless you have a protein based robot at your beck and call on-site, in which case you may as well be there yourself in many instances.

Software work? Consulting? Let’s start being smarter about that. Let’s consider the following impasse:

  • Companies regularly require local presence when there is no need.
  • Companies regularly cite security concerns as a reason why people have to come on-site.
  • Companies want people to attend site 5 minutes ago when they have an issue.

This is the 21st century. We can get around these problems and help the environment by not requiring people to travel everywhere to do some work. (Red tape and bureaucracy alone should never be a reason to deny remote work – honestly, if it is used as a reason with a straight face, there’s something seriously wrong with a company.)

Despite what some would have you believe, I’d estimate that in 90% or more of the cases where security is cited as a reason to prevent remote access, security is not a sufficient reason. Let’s consider options here:

  • Legally binding non-disclosure agreements.
  • Isolated virtual machines, audited by both companies.
  • Physically isolated machines (e.g., incoming connection machine only plugged into network when necessary).
  • Fixed IP addresses for access isolation.
  • Audited, or even remotely monitored sessions.
  • One time passwords for login.
  • One time passwords on the remote access machine (at the consultant’s company) that are only provided when connectivity is required.
  • Encrypted traffic.
  • Encrypted traffic over VPNs. (I.e., doubly-encrypted traffic.)
  • Automatic lock-out of inactive accounts (e.g., not used in 5 days – lock out).

All of these and more will resolve all security issues in (again, I’d estimate) more than 90% of cases, and the remaining cases are as much as anything based on legal or military obligations. (Any case where it doesn’t resolve it due to red tape or bureaucracy is shameful.)

Let’s be frank:

  • We have too many cars/motorbikes on the road;
  • Diesel trains still consume an inordinate amount of fuel per passenger, regardless of whether that’s less or more than cars (this is frequently debated);
  • Electric trains have to get their power from somewhere, and for many countries that’s fossil fuel power-stations anyway;
  • Airplanes use large amounts of fuel too.

Sure, we have to acknowledge that when we use computers and network/internet infrastructure, we’re using power which in turn may be coming from fossil fuel power stations as well. But even a quick search reveals a plethora of studies that show telecommuting uses significantly less power/fossil fuel resources than regular commuting. Telecommuting doesn’t, of course, have to only be about employees, but it can be with contractors and other “on-hire” staff too. Not only that, companies that are reluctant to try telecommuting with their own employees can dip their toes into the water by making provisions for remote work from contractors, support suppliers, etc.

Now I’ll mention my biases here:

  • I do remote work
  • I do support work
  • I do on-site consulting work
  • I’ve done my fair share of lengthy travel for remote work
  • Lengthy travel doesn’t enthrall me.
  • Lengthy stays in hotel rooms don’t enthrall me.

But let’s also be honest – IT consulting is not a family-friendly environment. Long hours of both travel and on-site work can at times actually detract from the experience both for the person doing the consulting and the company engaging the consultants. Particularly when the work is running late, or out of hours, happy people work better than unhappy people.

Bottom-line/numbers person? Then let’s think about project costs. If you think that any company doesn’t build staff travel and accommodation costs into their prices, think again. (Actually, depressingly I do have personal experience in one major PC company that continually demands such stupidity from companies which they buy contracting services from – and they continue to leave a string of collapsed contractor companies and dejected, failed ex-company owners behind them who thought they could manage or hide those costs.)

In all honesty, continuing to insist on local site attendance for activities that can be done cheaper, more immediately and more comfortably for all involved is just ongoing collective business insanity.

If you want to do something for the environment in 2010 – and make business cheaper without losing profitability, how about you:

  • Suggest to your customer, if you’re a consultant, that an on-site activity they’d normally get you to do is one that you can do remotely (of course, only if it can be done remotely!)
  • Ask your consultants, if you’re a customer, whether they can do the work you want done remotely.

Of course, there’s always going to be situations where on-site work is required, but let’s start bringing consulting into the 21st century.

 

Regular visitors may note that there’s a new addition to the pages on this blog – one covering Support and Services.

I run this blog in my own time (probably using up a little too much of my own time to be quite truthful) and ask for no payment or reimbursement from my readers – well, other than an occasional pitch for people to buy my book, that is.

My day job however is a consultancy and support role at IDATA Resolutions, and the Support and Services page outlines some of the key things IDATA could do for you, if you happen to be looking for service, support, consulting or training for your environment.

If you’re looking for an independent review of your environment, or considering support options, looking at a new solution or needing some training (whether that’s one-on-one, customised or general), I’d invite you to check out the Support and Services page above to see what IDATA can do for you.

 

We’re now rapidly heading towards 2010. The world did not collapse at the start of the year 2000, thanks in no small part to the efforts of developers and system administrators across the globe in mitigating Y2K risks.

So where was I, 10 years ago?

Well, I was still working for the most part as a system/backup administrator for a large resources company. I was neck deep in Y2K mitigation projects, notably:

  • Major efforts on a Tru64 environment where the core application could not be upgraded to a supported Y2K compliant version, so the surrounding OS and underlying database had to be upgraded instead to mitigate the risk.
  • Ensuring all my NetWorker servers were running 5.1 so that I could rest easy, knowing that anything that might fail could still be recovered.

The first project was the most frustrating for me. Not because of the work, but because of the “technical project manager” assigned to it. I knew I was in for a long hard haul the first time I had a conversation with the TPM and it boiled down to a 1 hour discussion where I kept on trying to explain why you had to add disks to a machine if you needed additional storage. From that point on my colleagues always knew when I was on the phone to that TPM due to the look of exasperated frustration I would wear throughout the conversation. It was even more maddening that the TPM had a laptop so old and clunky that he could run MS Project or Outlook, but never both at once. That would mean significant delays in responses to emails…

The funny thing is – when I reflect back on that project these days, I realise that it helped to turn me into a consultant. The standard engineer/sysadmin approach to such challenging people usually doesn’t work, so you have to learn to be a consultant to actually make any headway at all. So thankyou, challenging TPM. 10 years on and I don’t find myself silently screaming when I remember that project – instead I’m grateful that I was assigned such a complex project where self management became very important almost immediately out of the gates; it taught me that I was interested in far more than regular system administration. Instead of just being part of a team that did managed services and consulting, it made me want to actually be a consultant myself.

(As to Y2K itself, I spent around 8pm through to around 1am for the crossover at my desk, waiting for the world to fall down around our ears if we’d got it wrong. In a beautiful case of irony, the only major system that fell over during the Y2K transition was the Microsoft Access database designed by some psuedo-admin in another division of the company at the last minute to record Y2K failures…)

 

This is no time to talk about time. We don’t have the time! (Star Trek: First Contact)

Are you one of the unlucky IT staff who don’t record timesheets? If you are, here’s what you can do to (a) convince yourself that you’re unlucky, and (b) convince your management that they need to change, quickly!

[Edit, 2009-30-11: I get a few visitors a few times a week from searches such as "timesheets are a waste of time". If you're one of those visitors, I hope I am able to convince you otherwise.]

When I was first a system administrator, I had to do timesheets. Each week I’d grumble about having to do them, but compared to others in my team who would frequently be months or more behind, I’d usually get them in “on time”.

In my next system administration job, I didn’t have to do timesheets and initially thought I was blessed. After a while I noticed though that a lack of timesheets made for some very odd management attitudes. I’ll get to those in a minute – they’re at the crux of what I want to discuss.

Then I moved out of system administration into consulting, and pretty much ever since then I’ve had to do timesheeting. In fact, I ran a team of up to 20+ engineers for a couple of years and they can probably all attest to the fact that I used to bug them weekly to make sure they had their timesheets up to date.

You might say that I’m a believer.

I’ll do some initial qualifications here – I’m not a believer in a micromanagement timesheet approach that requires accurate measurement of time in 6 minute incrementals. Anything less than 15 minute intervals is entirely wasteful and creates too much administrative overhead. (Alternatively, if time recording should be done in increments of less than 15 minutes, then it should only be done in systems where the work flow, and the recording, can be done automatically. E.g., in call centres, etc.)

There are two common complaints that IT staff tend to have about timesheets:

  1. They’re a waste of time that could be better spent doing “real” work.
  2. The perception that they’re used by management to micromanage or even “punish” staff.

In any normal work environment, neither of these are remotely true.

Let’s look at each one to see why it’s wrong, and point out the counter argument to it.

They’re a waste of time that could be better spent doing “real” work.

I used to get this argument from time to time – heck, when I was just doing standard system administration work, I used to give this argument all the time. The simple fact of the matter is – it’s wrong.

When we work for someone, our work duties entail … what we’re told they entail. If part of that is timesheet entry, then that’s real work too. Call it “meta work” if you will … it’s “work about work”, but it’s still work.

They’re not a waste of time either. If a timesheet system is properly run, managed and reported from, it exists to allow the company to determine how resources are currently being utilised and how they’re trending. It also allows management to see how long tasks take. For IT staff themselves, that’s by and large the most liberating aspect of timesheets.

Particularly in companies that do consulting, timesheets fulfill another very important role – they allow the company to see how profitable they are, which in turn allows them to plan work cycles, which (ultimately for us) means they know they can pay us. This Is A Good Thing.

They’re used by management to micromanage or even “punish” staff

OK, there’s no backing away from this one – in some companies this has been the case. But those companies are relatively rare. Most companies want this information so they can work out how much it costs them (for in business, time is money) to do particular tasks – most good companies want this information so they can plan for personnel growth – i.e., to help normalise hours. Since (in Australia at least) it seems that practically 99% of IT people are on salaries rather than wages, this helps people get their personal lives back by having sufficient staff to meet business activity requirements.

Why you should be thankful for timesheets

Recall before I said that timesheets are liberating, because they track how long tasks take? I’ll bet at least 50% of people who read that statement chortle and think I’m off my rocker. Trust me, I’m not.

Regardless of whether you’re a consultant, or an administrator, or an operator, having empirical evidence of how long an activity takes can provide significant shielding from unrealistic expectations. Not only in my own personal experience, but talking to people who complain about unrealistic management expectations of tasks, there’s a very common link between management who request extremely unrealistic deadlines from IT staff across companies – it has a high tendency to happen in companies that don’t do timesheeting.

Why? Because the management don’t know how long things take. They don’t know how long an operating system install takes. They don’t know how long it takes to setup a lab AD server. They don’t know how long it takes to fix networking between branch offices. They don’t know how long it takes to do anything – not because they’re deliberately ignorant, but because they have no data available. That’s why, for instance, at 4pm on a Friday afternoon they’ll flick someone an email about needing to have a full Oracle development server ready by Monday morning when the hardware has been waiting idle for 2 weeks.

Guess how you make management understand how long things take? Timesheets.

If you work in an environment where timesheets aren’t done, stop kidding yourself that you’re lucky. You’re not.

 

I regularly check on undrln, a site mainly focused on graphic design – or more broadly, the professional graphic arts. Recently they linked to “Keeping Clients and Projects on Task“. While the article is very much written for graphic design projects, it actually has a lot of relevance with IT projects as well … i.e., change the topics of discussion and suddenly you’ve got a valuable short reference document explaining four types of situations/failures that can occur within projects.

If you work in consulting, it’s worth reading.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha