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!