Working 4 Days On, 3 Days Off

Having today returned to work after a bank holiday weekend, having finally felt fully and properly relaxed on the third day, and feeling so much more energised in work today as a result… it stuck me that this is something we should all do more often.

My own personal perception of the benefits is clear enough: the long weekend has been of obvious benefit to my work-life balance, and consequently I’ve been more productive throughout the working day because of my greater energy. The client has gained something through my greater energy, my family has gained a lot because of the extra time we spent together.

So why don’t we all do this more often? As always, let’s take a look at the maths.

I’ll start with a few basic assumptions:

  • You’re currently working a pattern of 5 days on, 2 days off;
  • Your daily commute is 1 hour each way;
  • Traffic is sometimes worse, or trains are cancelled, such that your 1 hour commute becomes 2 hours twice a week (making a total 5 day commuting time of 12 hours).

Scenario 1 – 35 hour week

If you’re one of the lucky ones, perhaps a civil servant, with a mandated 35 hour working week and allowed to take a short 30 minute lunch break (the minimum after 6 hours work according to Working Time Regulations), then your total time away from home on a 5 day working week will be 35 (work) + 2.5 (lunch) + 12 (commuting), making a total of 49.5 hours (an average of 9.9 hours/day).

Now let’s assume that you get agreement to distributing those same 35 working hours over a four day period, then your total time away from home on a 4 day week will be 35 (work) + 2 (lunch) + 9.6 (commuting), making a total of 46.6 hours (an average of 11.65 hours/day).

So you’ll recover 2.9 hours each week that are currently wasted from your life (which, over a 40 year period totals more than 5,000 wasted hours), and spend an extra 1.75 hours out of the house on the 4 days each week that you attend site, meaning if you would have got home at 5pm you’ll now get home at 6:45pm, but you’ll get an extra full day to do with as you please each week (whether that be gardening or going away for a long weekend) in return.

Scenario 2 – 40+ hour week

Now let’s assume you’re not so lucky, perhaps a contractor for a client who’s determined to extract everything possible from you each week, with a mandated 40 hour minimum working week and forced to take (or work through!) an unpaid 60 minute lunch break, then your total time away from home on a 5 day week will be say 42 (work) + 5 (lunch) + 12 (commuting), making a total of 59 hours (an average of 11.8 hours/day (already longer than Scenario 1’s 4 day week)).

Now let’s assume that you get agreement to distributing those same 42 working hours over a four day period, then your total time away from home on a 4 day week will be 42 (work) + 4 (lunch) + 9.6 (commuting), making a total of 55.6 hours (an average of 13.9 hours/day). Certainly it’s a long day, but then so is a 40+ hour week anyway.

So you’ll recover 3.4 hours (that’s half a working day for the scenario 1 worker) that are currently wasted each week (totalling 6,500 hours over your career, which covers about 3 working years!), and spend an extra 2.1 hours out of the house on the 4 days each week that you attend site, meaning if you would have got home at 6:00pm you’ll now get home at 8:05pm, but you’ll get an extra full day to do with as you please each week (whether that be gardening, visiting a museum, spending time with your family or going away for a long weekend) in return.

For any contractors paid a day rate who are concerned that doing the above will simply allow them to be exploited [even more than is already the case with the minimum working week they have signed up to under scenario 2] the solution is mercifully simple: you have agreed a day rate, now multiply that by 5 to get your weekly rate, and then divide by 4 to get your new daily rate. Obviously you’ll need to get a change to your limited company’s contract to reflect this, but then you would anyway to reflect the revised working arrangements. Remember that any contract should always accurately reflect the reality of the working arrangements. The principle is the same for permies too: you’re working the same number of hours each week so you should get paid the same for doing so.

Consider too that – regardless of scenario – if you are driving daily then your mileage will go down along with your costs of doing so, and of course your carbon footprint will also be reduced (isn’t this the way we’re all supposed to be going?), and if you’re staying over rather than commuting your hotel costs will reduce too (which leaves more money in your pocket). Whatever way you look at it, less days on site are a good thing.

So who may not go for this? At a guess:

  • Couples with children who have currently structured their start/finish times such that one parent drops off and another collects;
  • Companies determined to screw everything possible out of their staff by making them work past their contracted hours, every possible day;
  • People with no life outside work who therefore prefer to avoid the work-life balance problem entirely by never leaving work.

Wising up and looking into the future though it should be possible to have a 3 day weekend, work 2 days onsite and work 2 days from home each week. I doubt it’ll happen in my lifetime, certainly not in my working career, but the smart money is on it happening sometime. I’d like to see some enlightened UK companies piloting parts of this strategy in the relatively near future, not least because some US companies have already successfully implemented parts of it, and I’m told that many Dutch people working in Brussels have been doing it for many years too. Carsonified agrees with me.

It’s not just Carsonified though, take a look at these respected publications who also believe that I’m heralding the future here, and the current 5+2 pattern is destined to become history.

Attending site 5 days each week is simply an outmoded and unnecessary waste of everything.

If you enjoyed this post please share it with others, for example by ‘Liking’ it on LinkedIn, and/or leave a comment below. And if you disagree with me, and think that everybody should work 5 or more days per week, or simply that your one project is an exception for some reason… please share your reasons why.

Posted in Business Management, IT Management | Tagged , , | 3 Comments

The Web, Configuration Management, Y2K, ITIL, IR35, Theft & B2B IT Contracting

In my previous blog post in this series, the early years of IT contracting, I shared my experiences of working in the UK IT industry in the 1980s.

Sir Timothy Berners-Lee, creator of the world wide web

Sir Timothy Berners-Lee, creator of the world wide web

Sometime while I was busy doing all that, another (at that time) IT contractor and utterly brilliant Englishman, by the name of [Sir] Tim Berners-Lee cobbled together something he called the World Wide Web. If there’s any one truly remarkable thing, with world-changing benefit, that’s happened in the last quarter of a century… this is surely it. And the times were right for doing it, we were still (just) in the era when an “Englishman In His Shed” was a force to be reckoned with (although in truth Sir Timothy John Berners-Lee’s garden shed was CERN in Switzerland).

As an aside, this does prompt me to ask a question: Given it was invented by an Englishman in Switzerland, why do the Americans now act as though they own the internet? And why does the rest of the world, and in particular the European Union, not appear to care about this apparent theft of our technology and data?

Configuration Management Sheriff In Wild West

Contract Configuration Manager: A Sheriff for Hire to tame the Cowboy Programmers

Time passed and I gradually moved from programming into making sure others programmed properly, and their programs were safe. I started to focus more on making sure that software was tested before being released, that we had a copy of the source code of precisely what had been released to make patches later if necessary, and that we had a backup plan if a software release failed. Moreover we ensured that software was changed for approved reasons, which had been impact assessed, and not merely because a techie thought it was a good idea to lob in some untested wizz-bang tweak moments before something went live!

In truth this formal “Configuration Management” was a definite step forwards from the Wild West we had all enjoyed for the previous decade or two, and it was needed, but without that earlier freedom we’d never have achieved all that we had. It frequently wasn’t referred to as configuration management in the early days incidentally, merely “common sense.”

The Year 2000 chases a terrified PC with CRT monitor

The Year 2000 Bug aggressively hunted down any programming short-cuts

Three simple letters sum up the next big milestone, or hurdle to overcome: Y2K. The Year 2000 was looming fast and, unlike quality control or configuration management, it was a real and immutable deadline that even the most die-hard and belligerent of old-school managers could neither fight against nor postpone. Our great nation prepared itself for this potential disaster by dragging numerous COBOL programmers back out of retirement to fix-up what they’d previously short-cut due to machine limitations, and Britain’s world-beatingly flexible IT workforce, comprised mainly of contractors, got the job done in time. Y2K passed with barely a hitch. Lots of contractors made lots of money along the way (and rightly so as many sacrificed a lot to put in 100 hour weeks, and I still recall doing a 12 hour shift on 1st January 2000), and the government inevitably took a huge amount from us all in tax revenue.

Gordon Brown, Britain's worst chancellor ever

Gordon Brown shows his hatred of all contractors and destroys UK's flexible labour market

Britain’s flexible workforce was seemingly too capable for the worst Chancellor of the Exchequer that the United Kingdom has ever had the misfortune to endure however, and so a few months later in April 2000 old-school socialist Gordon Brown introduced IR35 to bring the flexible industry that had served the nation so well to its knees. The PCG was formed to fight it, and I’m proud to have been one of the 50 founder members that kick-started it all. The rest is history and, regrettably, we’re still lumbered with Brown’s legacy of avoidable red-tape.

Despite this attempted theft and extortion from legitimate businesses, run fully in accordance with English Company Law, I remained true to contracting and continued to move between clients, delivering guidance and expertise their own staff lacked, and support and assistance as needed. I was enjoying the challenge and, judging by the 50+ recommendations I subsequently collected on LinkedIn, the clients appreciated the quality service I was providing and deliverables I was achieving too. Some of the industries I worked in over the next few years, providing consultancy on things like software configuration management, process improvement and best practice included banking, transport, government, retail, publishing, aviation, defence, mapping, ecommerce, research and insurance.

For the benefit of anybody who thinks “industry experience” is the be-all and end-all of hiring the right skills I’ll say just this: It isn’t; the underlying principles of best practice pertain to all industries and in many cases you will benefit by introducing specifics from another industry.

The ITIL Service Lifecycle

The ITIL Service Lifecycle: Does it have, and should it even want, customers?

And while I’m on this subject, I’d also like to clarify another detail: The customers are the most important part of a business. The business exists to serve its customers. The business and IT processes exist to support and serve and the business (just like the staff do). The various software tools exist to support those processes, not define them. The role of the systems technology is to make those tools possible. And at this point I differ from ITIL (which also didn’t exist when I started contracting) because I prefer a far more entrepreneurial definition of a customer: it’s somebody external to your business who pays real money for something, with that money going from their account into your company’s, and in so doing enables your business to make the money to pay its bills. Whether a business wants customers or clients is another matter entirely however, and again I’d argue that under ITIL those receiving the service would far better be termed clients than customers (if indeed a purchasing relationship should be inferred at all) but now I’m splitting hairs and getting away from the point of this post.

Somewhere along the way, from Y2K to here, I partnered up with another contractor colleague and formed a niche consultancy. We had about 20 staff working for us in total, mostly sold out to various clients, and a turnover in the millions of pounds. As our company insurance premiums started to go out through the roof, an unavoidable feature of a society increasingly intent on blaming others and seeking litigious satisfaction rather than accepting responsibility for its failings, so he dipped his fingers in the till… which is where I found them during an unscheduled audit. (And you thought the “Theft” in the title was a reference to IR35, although that is too.) We prematurely followed our exit plan shortly thereafter, with much reduced profit for us both as a consequence; such is the price of one person’s greed.

Direct IT Contracting: Straight B2B

Approaching half of my contracts have been direct, against a simple purchase order; the other half have been through agencies. As time has passed my preference has increasingly moved towards direct contracts. The reason is simple enough: as agencies have got bigger, often through acquisition, they have invariably focused more on sales than service, and I have increasingly found myself trying to explain to somebody who was selling used cars or manicuring fingernails a few weeks earlier why I won’t compete on price with somebody who has 20+ years less experience than me! There are some good agents of course, and I’m always happy to speak with them and try to help out with my network when they’re looking for something or someone specific, but sadly they’re in the minority. And even when I do find a good agent, a person with whom I can build a relationship of mutual trust and respect, their back-office will normally go and screw something up big-time: that’s happened on three out of our last four agency engagements!

Perhaps because of this my preference is increasingly becoming to work with smaller businesses, who prefer to deal direct, and give them the benefit of my skills. I can’t do it all myself , of course, so I’m now partnering up with other entrepreneurial contractors with a view to building another multi-person niche consultancy. This is in its early stages at present, and we’re currently tentatively seeking a sales director, so as I type it’s far from a success story yet.

I'm happy being a genuinely independent consultant

I’m very fortunate to have enjoyed my 30+ years working with computers, and my 25 years in business: it’s a real privilege to have spent my working life having fun and making a difference. I’ve worked with some great people along the way, and made some proper friends too. I’ve also worked with fools and liars, who make promises they don’t keep, but luckily they’re easy enough to forget. The good people however will remain in my professional network, and my true friends closer still.

Coming next in this short series I will attempt to predict what the next 25 years holds for the IT industry. Until then, if you wish to comment to anything I’ve written above please do so below using the comment facility, and if you’ve enjoyed reading this post please use the various icons and social-media mechanisms to share it with others.

Posted in Quarter Century Review | Tagged , , , , , , , , | Comments Off

Review of a Quarter Century in IT Contracting – It Began in the 1980s

Fireworks celebrating 25 years in business

Something to celebrate

My first company was incorporated on 30th September 1987, 25 years ago last Sunday, and there’s been a lot of water under the bridge since then both for me and the IT industry as a whole. In this short series of blog posts I want to share a little of those years with you.

For the benefit of any younger readers, let’s be clear that back in 1987 the world was a very different place from now. I’m not so much thinking that the first branch of IKEA had only just arrived in UK; Saddam Hussain had yet to invade and loot Kuwait; that Apartheid was still law in South Africa; or even that wearing a seat belt in the rear of a car was still optional. Rather I’m thinking that a portable music player was called a Sony Walkman, and it played a Compact Cassette tape because CDs (and the later Sony Discman that played them – I had a D121) had yet to be invented; if you wanted to heat food you probably did so without a microwave, because most UK homes still didn’t have one; “mobile” phones did exist (just) but they were called “transportable” phones (and preceded the Motorola “brick”) and you needed to be strong to carry it any distance; a portable computer was available, but is was about the size of a small suitcase and weighed the same as one would if jammed full of duty-free booze; and as for the internet… in 1987 that wasn’t even a figment of anyone’s imagination!

So that’s where we were, 25 years ago, when I first decided to jump from “permiedom” into contracting. My hand was perhaps forced a little by redundancy proving irrefutably that there’s nothing permanent about a so-called “permanent job”, and it was a little scary at first, but my Dad (then a practising solicitor) quickly set up a limited company for me and with hindsight it was one of the best things that’s ever happened to me. And sticking it out for a quarter of a century has definitely turned out to be one of the best decisions I’ve ever made.

Compared with now the Computer Industry (as IT was then referred to, also getting itself labelled IS at some point) was something akin to the Wild West, but it worked well despite (or perhaps because of) this. To get a contract in those days you had to be able to demonstrate that you could do the work, as simple as that, and anyone who couldn’t usually found themselves leaving site with zero notice. A contractor was there to deliver a service, full stop. Now, in complete contrast, it appears that to secure a contract a litany of certificates, accreditations and exam results is what’s needed. Once onsite the contractor now appears to get treated more like an employee than a method of achieving deliverables, and the only time I’ve seen a contractor terminated and removed from site forthwith in the last 10 years was when I instigated it because the individual in question was disrupting my team. Compared with a quarter century ago it no longer seems to matter whether somebody actually does the job: it appears to be sufficient that they have certificates saying they are potentially able to, and are prepared to attend site to tug their forelock on demand. Personally, I don’t consider this to be progress.

At the early part of this period I was programming Windows 1.0 Software Development Kit (SDK) and for those who program Windows now I can only say it was very different then: I had one of only five Windows 1.0 SDKs in UK, and when we later progressed to version 2.17 I was one of about twenty-five UK-based programmers with it; DLLs were introduced then, although you had to write your own custom loader-code using assembler, and the remainder of the program was in C; C++ was more of a concept for the hardy few, and available only as a pre-compiler which then spat out heavyweight (rather than beautifully tight) C for the regular C compiler to laboriously chew through; Microsoft Windows UK Tech Support comprised two guys, both working part time in the role, and the support process comprised asking them the question, for them to then phone up one of the other SDK users who was doing similar… they were effectively facilitators of a mastermind group, which worked brilliantly and the relationship was fantastic.

Front Cover of MSJ

In my early IT days I enjoyed freelance journalism as well as programming

I was writing magazine articles too. I remember one about my early Windows SDK experiences entitled “Windows: A Clear Future Ahead, Or Just Another Pain In The Glass?” Another article, comparing Analyst Workbenches with full-blown CASE Tools, was published by (the long-since defunct) Systems International Magazine. And because I was the first person ever to get Windows 2 working with Oracle 5.1 on a standalone PC, and proudly demonstrated this at the Healthcare & Computing Conference in Harrogate in 1989, I was asked to write an article on Product Integration for the (also now defunct) Microsoft Systems Journal (MSJ) although I can’t recall whether it ever got published.

And all this started when I first played on a friend’s BBC Micro, following which my Dad bought me an Oric-1 home computer for £169 (a huge amount of money in the early 1980s) and I used it to teach myself to program games, which I then sold. So things had moved on a lot from there, even by the start of the quarter-century I’m discussing here. It does leave me wondering where the next UK generation (i.e. our children) will end up though, because the X-Box etc. don’t offer anywhere near the same educational experience suggesting we’ll no longer be a nation of IT innovators, and the youth of nations such as India and China will probably wind up leading the world’s IT forwards. The Raspberry Pi is making a belated attempt to address this, although I still don’t know any children who play with one at home. But I digress, and I should leave history to be the judge of that as I am with so much else here.

I moved from contract to contract, with proper contract terms in place like a cap on the maximum number of consecutive days without delivering service (even for a broken limb) before we got either terminated (if lucky) or sued for a breach of contract by virtue of non-delivery, necessarily taking holidays whenever gaps between contracts allowed. Compare that with now when many so-called clients even keep “holiday records” on their so-called contractors, although I always politely decline to partake in such nonsense as business is business and should remain strictly B2B!

Along the way I programmed for clients in various niches including market research, and retail banking, with a small supplier to a telecoms giant about 20 years ago being one of my favourite contracts (it was a rolling 2 week contract, that amazingly lasted for a full year, and for which I attended interview on a Sunday afternoon in bike leathers on my way home from Box Hill on my race-tuned superbike). Moving on from there I found myself getting security cleared to program some of the in-flight systems for the then un-released Boeing 777 (a machine on which I have never flown, with much of the software being under-pinned by Windows for Workgroups), before beginning a long association with an aspiring services provider (since bought out by a Japanese company and now a household name). I was still programming on Windows using C, of course, but by now I was getting into workflow systems and then CORBA in the then Object Software Laboratory as we strived to productionise software that had started life in the research labs. For the most part I was privileged to work on teams with a truly great bunch of people, and we had some great times and big successes as a result; some of my personal favourite achievements include being the first person to program a server ORB running on Windows 3.n, and being on a team of two to achieve the same on Netware and subsequently demonstrate it to Novell‘s VP who flew all the way from America just to see it.

They were heady days, where skill and innovation ruled high over certificates and exam results, and where remarkable people achieved remarkable things because nobody interfered and told them they couldn’t. It was also where I learned that something or somebody that’s good works everywhere: it doesn’t matter what niche or vertical market the client is in (and all-too-often now unwisely considers to be the all-important decider on who to hire). Good experience, good skills, and the right attitude work brilliantly for any client, in any industry!

In the next part of this series we’ll meet fellow contractor Tim, look at the arrival of the internet, discover formal configuration management, and leap into a new millennium. Stay tuned, or subscribe to get an update notification.

If you’ve enjoyed reading this post please say thank you by sharing it with others, and if you’d like to share your comments please leave them below.

Posted in Quarter Century Review | Tagged , , , , , , , , , | 6 Comments

IT Software Configuration Management a Black Art?

An IT Software Configuration Management Black Box (showing it as a Dark Art)

Is IT Software Configuration Management a Black Box or a Black Art?

“Configuration Management is a Black Art” or even “Change Management is a Black Art” are things that I sometimes hear on client sites, mostly from the senior management sitting far above the CM team itself. To an experienced Configuration Manager, this statement begs two questions: “Is it true?” and “Does it matter?”

Let’s take a quick look at those questions, starting with the easy one:

Is it true? The short answer is no, of course it’s not true. Software Configuration Management, indeed the entirety of Service Management, is something that can be analysed, documented, taught, learned and tested in the form of a number of “best practice” methods. If you disagree with that statement, then you also disagree with ITIL and everything that it stands for. If you can do that convincingly, then you can stop reading right now, and start your own consultancy business taking the world’s IT in a fresh direction!

More likely however is that anybody who argues that CM is not a discipline, and collection of best practices that can be documented and followed, probably doesn’t properly understand what it is. However, that shouldn’t stop them from benefiting from CM, just so long as they trust those who do understand it properly to deliver that benefit to them. By way of analogy: you may not understand exactly how every aspect of the ABS in your family car works, but that certainly doesn’t stop you benefiting from it.

Does it matter? First I want to clarify the question, because it’s really two subtly different questions: “Does it prevent the client organisation from benefiting from CM?” and “Does it affect the delivery of CM within the organisation?” In this context “CM” could be Change Management, or Software/Hardware Configuration Management, or indeed any part of ITIL Service Management. I’ll take those questions in turn:

First: “Does it prevent the client organisation from benefiting from Configuration Management?”

I can barely read music, certainly can’t write music, and struggle to play an instrument at anything more than a very basic level. My efforts at drawing and painting, specifically joining the dots and painting-by-numbers, are sufficient to impress a 2 year old with my skills but that (and painting a wall in magnolia) is about where it ends! However this doesn’t prevent me from going to a concert and enjoying the work of a talented composer, or visiting a gallery to enjoy the work of an artist; in both cases I benefit from the skills of others that I cannot hope to achieve myself. So even if CM is a “Black Art” (and I’ve already demonstrated that it isn’t as it can be documented, taught and tested) this won’t prevent those who open their minds, and trust the experts, from receiving the benefits it can to deliver to them.

A better example then is perhaps the nice cars those ‘Doubting Thomases’ in senior management drive to work every day. They drive their cars, and benefit from the comfort, safety and convenience those vehicles offer. But do they understand every detail of how to harvest and refine the fuel their cars run on? How to lay the tarmac their cars drive on? Or how to service their cars to keep them working properly, let alone how to design the car itself in the first place, or test it for safety and reliability? Of course they don’t, but those are all skills that can be documented, taught, learned and tested, just like ITIL.

Does it really make sense to trust a collection of complete strangers with your family’s safety (when travelling in your car), and then not trust your loyal and hand-picked staff/contractors/consultants with your organisation’s software configuration management? Of course it doesn’t! By the same token then, even if you don’t understand CM yourself, that’s no reason not to trust your specialist staff and independent consultants who do.

So, to the final question: “Does this opinion [that CM is a black art] affect the delivery of change & configuration management within the organisation?” The answer to this is yes, absolutely, when that opinion is held by the organisation’s senior management. This is so for any number of reasons, including (but definitely not limited to):

  • It demonstrates a fundamental lack of understanding of the IT area they are ‘managing’, and in so doing reduces respect held for the managers by those who are being managed (in this context, typically configuration managers and configuration analysts);
  • It pretty-much ensures that the organisation’s CM function doesn’t get the investment it needs, meaning that the organisation risks immaturity and excess costs as a result;
  • It demoralises and demotivates the CM staff in that area, so regardless of how professional they may be they are unlikely to give the best results.

The solution is fairly simple though: ensure that the IT managers sitting in the next few levels of the hierarchy above the configuration management and service management functions attend an ITIL foundation course, so they can better understand what those below them are doing on their behalf and how an investment in that area will be of benefit to the organisation. Either that, or just learn to trust their CM staff and external consultants in the same way as they do the unseen mechanic who maintains their family car at the garage…

If you enjoyed this article, please say thank you by sharing it through LinkedIn, Twitter, Facebook (or your other preferred social media mechanism) or by using the icons below. And if you have an opinion on this post, you’re welcome to leave a comment too.

Posted in Configuration Management | Tagged , , , , , , | 1 Comment

How Many Work Hours Per Year Does An Employee Deliver?

How Many Work Hours Per Year Does An Employee Deliver? It’s an important question, but one to which too few managers know the answer.

With modern automation methods it’s possible to capture some really good information about the effort involved in delivering services within a team, and to compile a comprehensive catalogue of services (a Service Catalogue) showing effort, frequency etc. With this done management can, with rapidly increasing accuracy, predict the number of man-hours required every year to support any system, and from this we should logically be able to accurately predict the number of staff required in the team to support it.

So far, so good. Amazingly though, in some organisations, it’s also where the problems really begin because we now need to understand how many hours of productive work an employee delivers each year…

The year itself comprises 260 (52×5) potential working days, from which (say) 8 days must be deducted for typical sick leave pattern, 7 for bank holidays, and a further 28 for planned annual leave. The actual working days obtained from a typical employee each year can thus considered to be 217.

When I once sought the opinion of a project manager (who should have a reasonable handle on actual work planned/delivered) about his thoughts on the proportion of a working day that a typical company technical employee spends on “productive work”, and that which is “overhead”, he appeared well informed. His opinion was that of the standard (in his company) 7 hour working day, 5 hours are used for “productive work” and 2 hours for “overhead” (meetings, official announcements, rah-rah, cascades, sundry reading, performance management, 1-1s, other non-core work, toilet breaks, shouting about football(!), dealing with personal stuff etc.). 5 hours worked out of 7 is 71.4% productivity. Assuming 5 “productive work” hours on each of those worked days then, a typical technical employee will thus deliver 1,085 (217×5) hours of work each year.

However, a senior manager within the same company suggested using a figure of 80% productivity, which means 5.6 hours of productive core work will be derived from a 7 hours working day. It may not seem like a huge difference, but this slightly different estimate brings the annual total of productive working hours up to 1,215; this is an increase of 130 productive working hours/year, which will take more than a month for an employee to deliver at a little over 25 productive hours/week.

So while the difference between 71.4% and 80% may not seem huge, as may not the 0.6 hour/day it represents, it’s also the difference between whether a team requires 10 people at 1,085 hours/year (10,850 hours annual total) or 9 people at 1,215 hours/year (10,935 hours annual total) to deliver a predicted 10,900 hours of service (see the Service Catalogue I mentioned in the first paragraph). That is also the difference between a team running comfortably with some spare capacity for unplanned work, and one that is already planned to be overstretched by about 10% (despite having a higher headcount) leaving little or no spare capacity, staff with a degraded work:life balance, and with a predictable overtime bill that would potentially exceed the cost of another employee.

I struggle to believe that any large organisation doesn’t have some pretty accurate figures for this derived from its various resource-planning and time-tracking systems, so my advice is to get a clear handle on how many hours of “real productive core work” you can budget on receiving from an employee every year and compare this with your service catalogue aspirations.

And consider too that in addition to often working longer hours than employees, contractors don’t need to be involved in the vast majority of the overhead activities that employees are either, so can easily deliver more hours of productive work each month. Bear this in mind when planning and/or budgeting and you just may be able to hit your milestones better, as well as having happier employees and more chance of staying within budget.

If you have found this post helpful, please say thank you by sharing it with others using the methods of your choice. And if you’d like to contribute to the discussion, please leave a comment.

Posted in IT Management | Tagged , , | Comments Off