Frozen Zone Sneakers

A « Frozen Zone » is a well known concept of the IT Production : at some critical calendar dates, all changes will be frozen (ie : blocked, not iced) to allow a « smooth » run of some vital jobs. Typical frozen zones include the last and first days of the month, quarter and year (to allow accountancy matching, invoicing or inventory check-up for example). Some frozen zone can be declared in summer, while all the technical experts are away on vacation, or when a critical production run is performed for an usual order in a factory…

The “Frozen Zone” comes with two paradigms:

First, it’s a further proof that one of the foremost (the main?) causes of incidents are changes (many of those being corrections to previous changes).

Second, no matter what you do, you can’t change human nature (even with process consultants): some people will always try to sneak around the Frozen Zone, by obtaining derogations for THEIR changes.

Those people tend to be (according to their own opinion of course), “the only ones who’ve got a real job”…

That’s why, even in Frozen Zone, critical incidents occur, by the fault of changes…

Premium IT Service

Customer relationship is not always easy... But after all, we must keep in mind that we’re running computers, not space shuttles nor jetfighters (even if the cost is the same). It is very unusual for a IT Production to have lives at stake (well maybe those who work for hospitals). Most of us work in offices, endangered only by back pain and dry air conditioner. So, when tone is rising in meetings, when clients and techies are angered, when people insult and threaten each other, keep cool and relax: it’s just about machines, we’re not killing or saving people!

And remember: always try to deliver the best service for your clients, within the scope of your SLA!

the return of the CAB - real life experiment

People can’t help it : their changes are always either “urgent”, “most urgent”, “critical break fix” or “an emergency”. No matter how well (and how lean) you design and run your change process, there will always be a lot of “bypass” (or attempts at least). Perhaps the true solution lies elsewhere, far from our ITIL reflections. Perhaps people just have to understand and above all accept that they are not alone on earth nor the centre of thereof. There are other people around us, with equally important claims for urgent changes and swift incidents resolution.

Perhaps ITIL is about people, after all… Not about computers…

Improve the service! (or at least, think about it!)

Summer : time for holidays, traffic jams, desert open-spaces, and (for those happy enough to remain at work), budgets elaboration…

As usual, vital projects are “arbitrated” (cut in half) while costly consulting missions are commissioned to produce emergency advices on how to improve the services… However, their recommendations will (probably) imply vital projects. Projects that will have to wait at least a year to begin (meaning that most of the recommendations will be obsolete). Projects that will be cut in half, just to be sure we still have enough money to pay for both the new consultants and the old – now meaningless- projects, dragging desperately behind the schedule…

Sounds familiar?

Paint It Black

No matter how many layers of paint you lay, no matter how fashionable it is, a good paint will NEVER fix a broken engine...

Improvement of the Customer Relationship needs, from time to time, to REALLY improve the service, and not only the way we report on it... :)

I Got a New Job

That's true, "Happy IT" lay dormant for many weeks, idle as an unplugged, unmonitored broken cluster of obsolete servers.

But now we're back into business.

I got a new job, about Operational Risk Management, I'm knee-deep into Basel II, and more eager than ever to publish stupid strips on the most laughable aspects of the "IT Services Production" and its relevant "Best Practices"

ITIL: Best What ???

It's amusing to see the difference between the dithyrambic managers who attend “best practices seminars” and the day-to-day realities of the IT Production, full of misdemeanours, incidents, errors, errand processes and ping-pong email cycles.

If I was sarcastic (which is, of course, no the case), I would say that the managers who attend Best Practices Seminars use to get all the Best Practices to the seminars, so we don’t have any one left for the IT Production…

Incidents: the infernal cycle

Life in the IT Production is a sinusoid: some curves are always going up while others are going down. And when something reaches its peak and starts to diminish, other values begin to rise up from the bottom… That’s life, up and down.

Of course, there is a strong correlation between rising and diminishing trends. And particularly in the field of changes and incidents managements. That’s why it is so important to measure and publish pertinent indicators, and to steer the activity in partnership with the Clients and the furnishers, using visual management, SLAs and common vocabulary and processes.

And if all those best practices can’t make your day, try something leaner. Such as the Colt 44 magnum.

Happy IT Week!

ISO: Flexible ?

To describe an activity with processes is relatively easy and very logical... In theory.

Practically, the production is seldom exactly working with the ISO processes described in the Quality Management System.

Often, to go ahead quickly with ISO certifications, "standard" processes are designated, drawn and described, and... That's all.

When it comes to real work (real people with a real job), nobody uses the described process... People even often "learn" their process before ISO audits. Something very stupid, since the processes are meant to describe the real situation...

This, and the infernal cycle of audits, certifications, remarks and new norms, creates a powerful entropy force that constantly steers the quality system away from the real world of the IT Production.

It requires a good helmsman and a steady hand to keep things in line.

However, no matter how you call or describe it, you ARE working according to a process. ISO and ITIL are just here to help you describe it and tune it. The quality norms and best practise are NOT meant to be a smokescreen for inefficiency...

Business as usual ?

Well... As many of you have noted, "Happy IT" is somewhat lagging behind schedule nowadays...

I cannot explain all the "how and why" of this unfortunate service interruption, but this has a LOT to do with IT Production (the real one).

Nasty people will say that, at least, I found myself a real job...

More news very soon (I hope)

Welf

Incidents Mismanagement - For good and for worst

Incidents… No matter how many projects we run, no matter how many people we task to problem solving, no matter how much money, time, sweat and blood we invest in IT Production, there are always INCIDENTS !

Their management tends to be an end in itself, a core business for many people that (perhaps?) need incidents to justify their jobs, proficiencies, and lives even.

Enough of empty words: perhaps you want to learn something useful here?

Here’s a recurring question: “how d we account incidents” ?

Basically, there are two approaches (who said “that of the IT Production and the good one”?)

1) The IT Production monitors all IT services by itself. It thus can detect incidents, often before the end users. Monthly reports of how many incidents were spotted by the IT Production are then sent to the Client -> that’s a bad approach, because you give numbers irrelevant to the users. This gives the impression that the IT Production is always in a mess. Ok… It’s true most of the time, but still: the end user don’t give a shit about that, this just might be used against you

2) The IT Production lets the end users report service interruptions. Then, it tries frantically to restore the service. At the end of the month, you will have a report of the total number of incidents spotted by your end users (who said “Clients”?). However this is a bad approach, since everybody will blame your lack of anticipation.

Now the “best practice”? You must adopt the “first approach” to manage incidents, and the second to report on incidents… This should minimize the incidents actually impacting the users, and diminish the number of incidents on monthly reports…

Otherwise, there are plenty of “bad practice” tricks to cover-up, makeup and hide incidents… But… Hey… I don’t know them, of course!

Nobody does…

At least, not in our IT Production!

Visual Management: Right or Wrong ?

In IT Production, people work on the intangible: virtual jobs, virtual processes, virtual environments… but hey, incidents are real, money is not so virtual, and, above all, users and clients tend to be very real…

When you work in a factory, it’s “easy” (well… not so in fact) to “see” the problems: stacks of parts, idle machines, piles of raw materials…

IT Production is a “virtual factory”: our stacks, spare parts, stores, inventories… Everything is “virtual”.

So? How do we make visible the invisible ?

Try Visual Management of the Performance: one of the key features of the Lean!

However… You might have some (bad) surprises. You might discover stacks of waste, piles of lost time… There is always room for improvement!

Happy Week End!

Welf, Happy man in the Happy IT Production

Mips! Moooore Mips! (monitor that!)

Thanks to the Moore Law (and the hard work of some scientists), the raw power of computers is ever increasing. Faster that any curve of economic growth.

However, the “consumption of power for business needs” is increasing just about as fast. That’s one of the downsides of the Moore Law: IT Production is always trying to cope with business needs, even in periods of economic downturn.

Thus, one of the key issues is to monitor CPU consumption. But remember: when you observe something, you tend to alter it somehow… Especially if monitoring solutions are provided by cumbersome corporations who sell the power: that’s being judge and party!

Get Back to some Real Work: The CAB is back!

At least, we're back to business...

It's good to see that the stripgenerator is up and running... Like all users in front of an IT incident, all that I could do was to walk in circles, cursing the IT Production...

We'll... The stripgenerator is free: that's value for my money :D

Anyway, let's get back to the Happy IT Production... Today, let's wander to the CAB... As you can see, people never run out of pompous vocabulary and hyperbolic metaphor. Especially if some Big Blue Corp Consultants are in the neighbourhood. That's one of the great benefits of ITIL and ISO: to provide geeks and nerds of the IT Production new words and a degree in "corporate language"...

Happy IT: Real Incidents suck!

Well... The "stripgenerator" I use to create the strips for this blog is down since Monday 18(stripgenerator.com is not responding)...

This time, I've been caught back by the true realties of IT Production. I feel like any user...

*Sigh*

I hope Happy IT will be back soon...

Welf

Production Incidents around the world

Life can be so... Different, wether you work for the "real" industry (real people with real jobs), or for some kind of IT Production, far away from the real world, in a remote galaxy well preserved from Clients...

Spirit of nonsense...

Life in the IT Production can sometimes be somewhat frustrating...

The nightmare...

For many of us, in the IT Production world, incidents, problems and dysfunctions are “normal life”. It may seem odd, strange or even weird for normal people, but for IT Production teams, when something’s running OK for more than half an hour, a sudden state of anguish arises while suspicion grows. We immediately need to check what’s going wrong… Err… Right.

True, many IT organisation models are built not to get things running, but to fix what’s not running. Thus, we put the emphasis on “incidents managements”, not on “production management”.

There’s a long way to go, on the never ending (and steep) road of processes improvement…

While on the road, why don’t you get yourself a real job? :)

Management for Dummies: Motivate your troops!

IT is one of the world’s most difficult management environment. Perhaps just behind hospitals and Delta Forces. IT Teams are a bunch of young geeks who cannot do the same thing twice, old mainframe techies who “always did things that way”, self-proclaimed experts of obscure languages and freshly graduated long-toothed crooks.

IT management operates with strenuous budgets. The clients (real people with real people) want to control their IT budgets. The golden era of neverending budgets is over, gone with the first internet bubble in 2000. Now, they want some bang for the buck, and don’t want to spend a dollar more for IT, while their demands on IT explodes.

Thus, it is often hard to motivate the “troops”, within changing organisations, pressure, norms, incidents, angry users, weird changes, loopholes, complex processes and ever evolving technologies.

Managers must animate their teams. But not like puppets. To get the most of people while preserving a happy mood for work is a hard thing to do… Motivation does not comes free.

“Want to get heard? Speak slowly and carry a big stick” (Theodore Roosevelt).

Times of Crisis : communicate on simple measures!

Sometimes, there is a true crisis: not an “IT crisis” coming from some weird incident in the batch process. A real crisis, coming from the real people who have a real job: the “business”. Often, there is a direct impact on the IT Production. As the dependence on IT is more and more important for all fields of economic activity (from industry to insurance, through banks and even agriculture), IT teams need to react quickly to alleviate the pain of the crisis, to fill the gaps, to hold the line… We are the new rank and file soldiers of the 21st century conflicts.

Sometimes, we are a bit bewildered by what might seem to be some kind of overreaction or under reaction from the IT and Business management, who often push odd changes quickly. Anyway, this is always good for at least one thing: communication to the investor and public. They will have the feeling that IT teams are doing something against that blasted crisis that threatens their profits. And since neither the public nor the investor are usually proficient in IT complex issues, it is often more useful, while you really check what’s wrong, to announce simple measures that can be understood by everybody.

That’s the art of crisis communication: positive and simple, yet efficient.

Never forget one thing, though: good crisis communication never fixed any crisis issue. It only gives you some time, at best.

Man in the loop: The Flawless Computer

When coping with complex problems and sensible data, it is sometimes difficult to advert dangerous errors and losses.

Fortunately, there is always the “Technical Innovation paradigm”: no matter what the problem is, somebody will come with a technical solution. Even (particularly?) if the problem is not a technical issue.

While it would be more sound and sane to dig up the process, to optimize the workflow and to improve the way we work, we often run into the next technical innovation, aptly sold by a brilliant consultant.

Thus, the level of entropy increases, as the everlasting problem is handled by more complex technical platforms which, like anything else, have their own unsettled issues.

However, in the mind of most investors, managers and even clients, the computer is still a “flawless solution” in regard to the “error prone man in the loop”. They just forget one thing: computers are designed by humans. Choosing a computer to perform a task is just a way to shift the source of errors from the man who was in charge to the man who conceived the computer.

Errors still happen, and there is still room for improvement, process tuning, procedures enhancement… And even sound and well-thought technical innovation, sometimes…

Incidents Management : No Solution?

Amongst the many golden rules of incidents management, there is one that must be kept in mind everyday, everywhere, at any time : « If there is no solution, there is no problem ».

Thus, is something happens that YOU cannot solve, then, it is not YOUR business. You MUST call somebody else as soon as possible (the ASAP paradigm, as usual). There is no shame to call for help if you cannot fix it!

As an addendum to this golden rule, there is always something that you can do in the meanwhile, to keep the initiative, communicate with your clients, furnishers and hierarchy, and still pretend to lead the resolution of that blasted incident: create a Task Force.

To create an optimum Task Force you must:

- Pile a dozen of telephones on a table, even if they are not plugged (pretend to lead a “wireless IP phone solution”),

- order some twenty pizzas (and eat them cold),

- brew pots of coffee (and drink it cold),

- remove all neckties,

- print big “Task Force 1” on A4 papers, and stick some on the doors of all offices (and the lavatories).

- stick on the walls many complex (yet meaningless) charts, diagrams and listings, and use a red pencil to underline the must “relevant” parts,

- get a paperboard, and jot raw ideas on it,

- stick Post-It(TM) everywhere,

- call the people of the Communication, so they can take a picture of your Task Force, and publish a paper in the next internal newsletter.

Thus, you can send this picture of your Task Force (preferably from the Blackberry of your team manager) to all your clients, furnishers, partners, top managers, and so on…

Everybody will be sure that YOU are in charge, fully committed to solve this problem. Even if you don’t get a shit on it.

And remember… It there is no solution, there is no problem…

Project Management: Blame it on the other one!

As we discussed last week, Project Management is often a synonym of « deep space tunnel to far away galaxies », where ideas tend to drawn in the warp.

The people behind, the Project Managers, are spread between two contradictory trends: to give the feeling that they work hard, while nothing happens on their project.

Thus comes the next logical step: finding third-party scapegoats to explain why the project is lagging eons behind schedules while everybody is committed, sleeves-up, round the clock, seven days a week.

What’s wonderful with IT Production is that there is ALWAYS a third party to blame. Since you cannot invite everybody in project meetings, you can always shift the burden one somebody who cannot defend himself.

Project Management is a wonderful world, for people who can’t get themselves a real job (like, say, programming or system engineering)…

Blogging: Shit Happens

A throng of fans (ok... two of them) noted that there were no post on this blog yesterday... Sometimes, shit happens...

See you Monday! Let's pray the Helpdesk God! Let's sacrifice young virgins to Yog Sottoth!

The New Norm 2: Project Management

Project Management is one of the foremost activities if IT Production. A world in itself.

Sometimes, to kill a stupid idea (or, more often, a good one), you just need to start a project. Here comes the times of “project meetings”, “steering committees”, “scheduling meetings”, “project management tools”, “project management document repository tool”, “project follow-up committees”, etc etc etc…

99% of the Project Manager time (and budget) is sucked by “methods, norms and compliance”. Consequently, it spins off, drags, and falls into oblivion…

Yet, sometimes, you can see boasts and claims of marvellous projects delivered “in advance on the schedule”. There are many accomplishments in the IT Production to be sure. But, often, they are re-qualified as “project” once they are finished, and subsequently entered in the “Project Management System”*. In the meantime, the actors of the project were able to use 99% of their time on it…

Or “PMS”, or “Pre Menstrual Syndrom”: somewhat annoying and recurring, and nothing to do to advert it!

ps: I thank my Lean Coach for the "kill the initiative with a project" remark yesterday...

The New Norm...

ISO norms have become, in the recent years, more than a tool to increase quality, interoperability and efficiency. The era “ISO standardisation” is fare from us. Now, ISO norms are business arguments. If you can tell your clients that you have an ISO certificate that nobody have, you can be sure that it will increase your business.

It doesn’t really matter if the norm is stabilised, efficient, or even useful to YOUR business: What matters is to have the certificate before your adversaries (at best) or as soon as possible we they have it.

That’s a business issue!

the Holy Grail of IT Production

Today's strip is dedicated to all fans of the Monthy Pythons (nothing to do with objects-oriented language, geeks).

There are many of them, in just about any IT Production, in any IT Corps. All of them seek frantically the Holy Grail of IT Production: the “open source workstation”. Everybody knows it’s a desperate endeavour, but everybody is investing pots of money and time into. Mainly because it is fashionable, and because “our adversaries are doing the same!”.

However, the “open source workstation” is a kind of mirage in the desert: tricky, always seeming to be “at hand”, and always disappearing into the sands of time.

So, what is the “open source workstation” ?

Well… Let’s say that it is a bit like pornography: it is sometimes hard to define, but you can be sure everybody will recognise it when (at last) we’ll be able to see it (someday, somehow). The only fear is that it will turn to be like “cold fusion”, “hyperspace drive” or “user friendly IT Production”…

(thanks to Knarf for the "open source idea")

Service Level Agreement 2: our service offer

It is one thing to sell a Service Level (anybody with a pretty necktie can do it) and to be able to fulfil the commitment (ie: do some real work without Power Point).

To do that, you must be able to get from your technical teams a “Service Offer”. It is not as easy as it seems, though. Technical teams are full of technicians (hopefully). They are here to put their hands into dirty machines, to solve hard(ware) problems, and their background comes from laboratories, universities, technical courses… Not from commercial courses and MBA.

Thus, relations are sometimes strenuous between the “IT commercials” who sell the Service Provision and the corresponding Service Level, and the technical teams, who have the burden on their shoulders. Like “What the f*ck ? You sold what? 99% availability on all platforms, round the clock?”. Many of them don’t actually know what a SLA is, or why it matters. Some people even think that the technicians don’t even know what “Client” of “Business” means. Perhaps there is no ASCII or binary equivalent.

Anyway, to do the techs full justice, many commercials selling the SLAs don’t know the difference between a Mainframe and a LAMP server, or between ORACLE, a pair of socks and a frying pan.

Security 1: keep it simple!

Security is a big issue for IT Production. Especially for some risky businesses (banks, nuclear industry, R&D, harmonica factories in Libya and the like).

There is a general trend to view IT security as a stacking of infinite layers of firewalls, secure network bubbles, DMZs, encryption protocols, secure ID tokens, RFID chips, etc etc etc…

However, no matter how modern and technologically up to date the IT security might be, it still depends on human rules and regulations, and there is always a man in the loop…

Thus, in the “real life”, most security breaches and real estate losses are caused not by hackers and IT attacks, but by physical errors, misconducts, neglects and, sometimes, seldom, premeditated crimes and massive frauds (banks, please take note).

90% of securities issues in IT production can be solved at a very modest price, with a bit of personal commitment, common sense, and logical behaviour. Never jot passwords of scraps of paper, never put some sensible data on an USB key attached to your keying, always use the paper shredder to destroy confidential documents… And above all, SHUT YOUR MOUTH when you are in public transports. Every year, I can hear sensible conversations about big contracts in the train, by the same people who advocate to invest 5 millions in the latest RFID Security Architecture to ensure “full IT Security”…

Service Level Agreement 1: what the Client wants!

A long time ago, back in the history, the IT Production was a strange room of scientists, performing fundamental research of supercomputers running at 10 Mhz. Everybody wore white shirts, black ties, and held a PhD in either mathematics of physics (or both). Funds came from the army of from big universities, or from the army through big universities. The ultimate goal was research in itself, and everybody was 8-bits happy.

An then came the business.

Factories, banks, phone-operators, public administration… A lot of people wanted some computers to run for their business… But the IT Production was still a bunch of scientists, university nerds, former military researchers, wearing white shirts, black ties, and obsessed by the fundamental research on their computer. The IT Production was an integral part of its corporation, sometimes still under the “Research and Development Department”. Nobody had ever heard of the “Service”, the holy grail of business.

Everything was well, however, since a common knowledge was that “you only need to invest money in the IT to get 20% return on investment yearly”.

Alas, in the merry kingdom of IT Production came, one day, the awakening of the Client.

Was the Client wants is a good service, not fundamental research. He wants a good “bang for the buck”: something like hard tack for his money. And he wants it there and now, not in ten years. And he wants to be able to measure it.

Thus we invented the “Service Levels Agreements”. The IT Production, running like a service provider, will commit itself to a reasonable service level, in accordance with the business needs.

However, everybody soon discovered that it was sometimes hard to turn geeks and nerds into business-centric service providers. And, on the other side, it was sometimes difficult to explain to the Client that the IT Production was not going anymore to be able to go beyond the agreed service level for free… Nobody answered the phone after 5pm anymore. Nobody stayed on week ends for free. You had to pay for just about everything... The SLA is not only a wip for the Client: it is also a shield for the IT Production.

The morale of this story is: “A Service is Defined through three components: its quality, its costs, and its delays”…

Recruitment 1 : mundane questions

One of the most difficult tasks for IT managers is to recruit the right person for the right job. With the proliferation of new languages, norms, technologies, protocols, operating systems and so on, there is often an “arms race” on the resumes, with more and more glorifying terms like “blackbelt”, “master blackbelt”, “senior blackbelt”, “shaolin grand master of Wu”, etc…

But behind this cluster of pompous titles, people are sometimes unable to answer the most mundane questions, asked by sadistic managers who are true “recruitment blackbelts”. This is called the “destabilisation attack”.

What Churchill said about war is true of recruitment: it is a game that is played with a smile. If you cannot smile, grin. If you cannot grin, stay out of the game”!

Be ready to answer the most mundane questions!

By the way… TCP/IP means “Transmission Control Protocol (TCP) / Internet Protocol (IP)”

Introduction to the TCI/IP

ps: no matter how "irrealistic" this strip may seem, it is in fact a true story (special thanks to Knarf, the sadistic manager)

Incidents Mngment 2 : MIND YOUR OWN BUSINESS!

There is one thing to keep in mind with « Incidents Managements » : it is meant to “manage” incidents, not to solve them. I guess that’s why it is not called “Incidents Resolution”…

Thus, often, “Incident Managing” means “passing through the hot potato while keepin’ the head barely out of the water”.

To add some fun, “Incident Management” tends to be rigidly organised by strict procedures, regularly audited by ISO Inquisitors. They are meant to prevent chaos, erratic processing of the information, bypassing by friend of the friend of the friend, multiple resolutions of a single incident, loopholes and so on… Some people even say that procedures could, to some extent, in some cases, improve efficiency and help to perform some good work. Well… Some parts of some legends are sometimes true.

Procedures are both a sword and a shield for the IT Production. We can hide behind them, to weather the wrath of unhappy users, and we can use them to our profit, to slaughter the other levels of IT support, if they do not comply with (which is more important than to solve the incident, since we don’t have an “Incident Solving”).

However, be careful: a procedure is sometimes a double-edged weapon, to be wielded with some caution.

And remember one of the golden rules of Incident Management: MIND YOUR OWN BUSINESS !

To test or... Not to test. That is the question.

Change management is a wonderful world. You take an IT Production that is already running with patches, temporary fixes, recurring incidents and IT Heroes committed round the clock to preserve the fragile balance between order and chaos and, instead of doing necessary long term investments in time, money and people to cleanup and stabilize what painfully exists, you decide to change something, there, now, at 4:55pm, five minutes before the night batch starts running 1500 jobs on 500 servers…

Of course, the test procedures are, more than often, resolved through the “GANEMITBO paradigm”: Go Ahead, Never Mind the Bollocks!

Tested or not, the change must go ahead, because it is a “business issue”. More than often, the change is just a correction of a bug caused by another change. Not yesterday, but last week…

Anyway, tests are often useless. Not because we don’t have time to. But because test platforms environments do not exactly match those of the production. Nobody never have time to work on test platforms: everybody’s committed to fix the bugs on yesterday’s changes…

Family Life - week-ends...

Sometimes it's hard for IT Teams to "disconnect" from work at home. Particularly since the advent of emails, blackberries and secure remote accesses.

When the mind is perpetually connected to the IT Production, family life can become... Strenuous at best...

Happy week-end!

Change Management : The CAB

The « Change Advisory Board » is a board of people in charge of giving advice about the changes on the IT Production. Clear enough?

Years ago, IT Teams changed what they wanted and when they wanted on the IT Production. This often led to some “discomfort” for the end-users.

Even between IT Teams, changes were routinely mismanaged (yes: more than now sometimes): network teams changed IPs without warning, mainframe teams decided an IPL at 10:15am, DBA teams cleared tables around 04:56 pm… And the like.

One of ITIL “best practices” is to introduce this body of representative people.

Thus, the “official ITIL definition” is:

An authoritative and representative group of people who are responsible for assessing, from both a business and a technical viewpoint (wow!), all high impact Requests for Change (RFCs). They advise Change Management on the priorities of RFCs and propose allocations of resources to implement those Changes. The Change Advisory Board (CAB) will be made up of Customer (what? who?), User (gosh!) and IT representatives, and may also include, depending upon the nature of the Changes being considered, 3rd party and other administrative business representatives (argl!). The CAB is chaired by the Change Manager.

You see, real people and nerds, in the same room, trying to speak the same language. Sounds crazy, hu ?

So the IT Teams had to learn some kind of new “vernacular communication mediums” (words) to be understood by their counterparts who, in turn, tried to plunge into the abysses of IT vocabulary.

Sometimes, this leads to curious situations, with IT teams trying to “hide” a change under a somewhat curious terminology… But of course, this is always for the best reasons!

Incident Management 1: Good Procedures!

Incident management is a core business of day-to-day IT Production. Nobody exactly knows why but, no matter how clever IT people are, no matter how well changes are prepared, no matter how modern the computers are, no matter how users are responsible and compliant, incidents WILL happen. This is one on the main IT Laws.

Some incidents are worst than others. For instance, if you loose some data on a test machine, it could be a "class 3 incident" (never mind the bolocks). If the scheduler for the whole IT Production goes down in the middle of the night batch, it will be defined as "class 1 incident, condition very red"...

Incidents are times of crisis for the IT Production. And when a crisis arise, Humans often panic. However, good procedures, incidents bibles, proper processes and clever communication will help to get the hell out of here.

BUT... No matter how well a procedure is written and followed, it will NEVER do the actual job for you...

FIX IT!

A State of Anguish 2: the consultants

When the situation becomes REALLY critical, it's time for the IT Production to get an "external point of view". Precious advice from costly consultants...

Audit: Burn the Witches!

Audit: a very usefull moment in the IT Production to check what's right and wrong. It helps to detect best practices and no-so-best practices...

Problem: audits sometimes tend to become witch hunting, seeking "who is guilty of heresy against the Norms Dogma". The culprit is then burnt on the Altar of IT Sacrifice.
Eppur si muove concluded Galileo Galilei after he accepted the remarks of a famous audit...

A State of Anguish

Sometimes, the relation between the IT Production and its "clients" is not very good. And sometimes, it gets worst.

Those are times for the "crisis cells" and "task forces" between top managers, to find innovative ways to weather the storm (and improve the service)

Visual Management: send in the geeks!

"Visual Management": plain paper on the wall, with hand-built charts. For up to about 100 items a day, its ok to work with a pencil (provided the chart can be seen by the whole team).
You can "visualy manage" your daily activities, and follow their evolution. Very usefull (and sometimes disturbing)

Six Sigma: a method from the industry (and very popular nowadays in the IT Production) to eliminate defects. Works well with laaaarges figures (beatifull gauss curves with 1 million entries)...

5S for dummies: get rid of the useless

"5S" is becoming increasingly popular in IT Production. Coming from the industry (real people will real jobs and real products), it is a Japanese method to "clean the workspace and get it fit for optimal work". It requires a bit of day to day commitment (like many things), and a bit of clever thinking. It can be successfully applied to "virtual workspaces" (yes, your hard disk and its zillions-branches tree).

However, some people tend to assimilate "5S" with "dump the useless"... Well... It's always a good thing to get rid of the useless, hu?

Want to know more about 5S? : http://en.wikipedia.org/wiki/5S_%28methodology%29

Lost in ISO?

Quality norms are a powerfull tool to enhance... Quality. But sometimes, they are drafted by people who speak a strange language, far from the "ground chatter" of IT geeks. Getting lost in ISO is easy. It's a bit like a jungle. Some people are clever to sneak around the big trees, and other will work their way through, with a bulldozer...

Jurassic Solutions for a small planet

I love Big Blue Corps... They always have the "best engineering solution". A bit like the T-Rex: the most potent dinosaurus... But hey, chaps: sometimes, you just need a good bacteria. You just need yeast to brew beer, not a marvel of engineering...

IT Production: Directions!

Sometimes lost in the Wonderfull World of IT Production? Try this excellent Functionnal Map...!

Happy New Year!

Well... Every journey has its beginning

This blog is dedicated to the "joys" of IT Production... Weird norms, strange projects, best (and worst) practices, erratic management, fuzzy incidents, naughty geeks, surrealistic schedules, cryptic quality management, incidents (mis)management and the like... Enjoy!