NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Posts Tagged ‘consulting’

Introducing the Support and Services page

Posted by Preston on 2009-12-17

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.

Posted in Aside | Tagged: , , , , , , , , , , | Comments Off on Introducing the Support and Services page

Aside – This time, 10 years ago

Posted by Preston on 2009-12-07

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…)

Posted in Aside | Tagged: , , , | Comments Off on Aside – This time, 10 years ago

Why you should love timesheets

Posted by Preston on 2009-11-04

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.

Posted in Aside | Tagged: , , , | Comments Off on Why you should love timesheets

Aside – Consulting tips

Posted by Preston on 2009-07-19

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.

Posted in Aside | Tagged: , , | Comments Off on Aside – Consulting tips