The SDLC (Systems Development Laughter Cycle)

The SDLC (SYSTEMS DEVELOPMENT LAUGHTER CYCLE)

IT’s a serious business folks – so don’t laugh…

 

We’re a strange bunch in IT. For the past 50 years we’ve been working to a methodology based on the construction industry, with a strict linear approach from analysis, development and testing through to implementation and operations, with each phase performed by different teams of specialists. Even though the success rate of this approach is the pits, we still take it quite seriously – which when you come to think of it is actually quite funny.  Which is why SDLC might as well stand for Systems Development Laughter Cycle.

 

REQUIREMENTS – ANALYZE THIS!

 

The first phase in the SDLC is requirements analysis, which is traditionally conducted by analysts (you want to be careful how you pronounce the first syllable …). Analysts sit down with users in an attempt to understand their business problem – then produce a thick ‘requirements’ document that no one really understands.

 

Once this so-called ‘statement of requirements’ (SoR) has been duly ‘signed off’ by the business, IT will then try to build a system to meet those requirements. Now the requirements might be incorrect, incomplete, or might even have changed since. But that doesn’t matter, because if (when…) the documented requirements that IT delivers on don’t correspond to actual requirements, it can use the signed-off SoR as a ‘get out of jail free’ card in Monopoly, and not be penalized.

 

DEVELOPMENT – MISSION IMPOSSIBLE

Once analysts have tricked the business into signing off on the SoR, they toss it over the wall to the development team. This group now has the unenviable task of programming useful deliverables out of what is ultimately a mix of real requirements, perceived requirements, wish list and pure fantasy. Usually the things you hear from developers when they read the SoR are things like ‘This is impossible! We can’t do this!’.

 

So developers sometimes find that they have to develop a system in three months that allows the business to ‘analyze customer behavior based on any combination of profiling information, order history, billing patterns and customer service interactions, using user-friendly point-and-click technology which gives graphical results on a real-time basis’ – something that can take one to five years, if at all possible. As you have probably gathered by now, developers and analysts have a love-hate relationship, and don’t exactly hang out together after work.

DOCUMENTATION – SOME LIKE IT NOT

In theory, developers are supposed to document their systems so that others can work on it later. In reality of course, this is rarely done.  Any token documentation that does emerge will in all likelihood be inaccurate, incomplete and difficult to understand.

 

There is no economic incentive to spend any serious time on system documentation because, unlike user documentation, it is not part of customer deliverables.  So it is eternally put off, or given to an intern or a junior hire who will spend a challenging few weeks producing a set of documents that no one will bother to check for quality, for the simple reason that probably nobody will read it. So it ends up as shelf ware or server ware – except when IT needs something to show the auditors: ‘See, we have documentation. We are good people. Now go away and leave us alone !’

 

At the end of the day system documentation is like an insurance policy. You don’t know what’s in it until you’re in trouble, and then you discover you’re not covered for much.

 

TESTING – PASSING THE BUCK

 

In the manufacturing industries, testing is basically ‘just in case’ testing, ie you’re almost sure you got it right but you’re just checking. You’re therefore happy when you don’t find any defects. In IT, however, it’s the other way round. You’re sure you didn’t get it right, and you’re damn well going to prove it! You therefore expect to find defects, and if you don’t, then you’ve got a real problem! In fact, there’s a truism in IT which says that a good test is one that finds a defect!

There are four categories of testing: unit testing, system testing, integration testing and User Acceptance Testing (UAT):

·         Unit testing:  This first phase of testing, which is done by the developer who coded the programme, usually uncovers the most bugs. By the time he’s finished, he knows there’s still a lot more to be found, but he’s pretty fed up with testing by now.  So he hands it over to another developer, who tackles it from a different angle, and finds yet more bugs. Once they’ve fixed these bugs they announce the completion of the unit testing phase, not because there are no more bugs to be found, but because they don’t know where to find them – and in any case they want to get back to some real work. So they pass the buck down the line to the system testers.

·         System testing :  System testing ensures that all the different parts function together as a whole. So if you enter a test order for two widgets and a packet of nails in the order entry programme, and the invoicing programme prints an invoice for two nails and a packet of widgets, then you know you’ve got a problem. System testing usually ends when they run out of time, definitely not when they’ve found and fixed all the bugs, which they never will. And in any case, they know they can pass the buck down the line to the users…

·         User Acceptance Testing (UAT): The buck stops here! After IT has finished its part and hopefully delivers something workable, the users do a final round of testing, which is as real as it gets before going into production. UAT is like trial by jury. When the users are done, they go away to deliberate, leaving IT to wait an agonizing week before knowing its fate. When they finally emerge, they either proclaim the application good enough to be put into production (ie reasonable bugs), or they charge IT as guilty (ie beyond reasonable bugs).

The final phase of testing, the real one that discovers the remaining bugs, is called production.

OPERATIONS – THE REVENGE OF THE NERDS

Ops run production systems. This is probably the most technical and procedures-oriented part of the IT organization, because it manages the complex hardware, software and networking infrastructure that runs the core applications of the enterprise. Now there’s a thin line between being procedures-oriented and being bureaucratic, which explains why Ops staff are often negatively viewed by both users and their colleagues in IT, as illustrated by the following question: ‘How many Ops staff does it take to change a light bulb?’. ‘We can change the bulb in five-to-ten working days. If you have a valid work request number and you submit your application before 5pm, we can get it changed within 24 hrs. And don’t forget to put your name and cost centre code in the upper right hand corner of the light bulb application form.’

Which is all a bit unfair, because if the company’s core operations were impacted (orders, billing, finance, etc), then these same users and the rest of IT would be the first to press for better procedures.

One of Operations key tasks is seeing to backups. No other industry is so obsessed with avoiding information loss; having your PC crash and not having a backup can be a very traumatic experience. It sits right up there with other personal tragedies like having your car stolen or getting audited by the IRS, which require counseling and time off. We’ve all seen such people at work (‘you don’t want to go near Joe this week. He’s in a foul mood because his PC crashed and he’s got no backup.’

 So Ops instructs users to back up their work onto the server every day. But that’s not enough. Modern servers operate at only 99.9999% reliability, so we clearly can’t take any chances here. We therefore make a backup of the backup. And if we’re really paranoid, we’ll make two copies and put them in different safes in different buildings – maybe even in different parts of the country! And the amazing thing is that even with all these precautions, people still find themselves at least once or twice in their lives suffering this particular form of personal tragedy. I guess it’s like seatbelts – you could probably pass a law (‘Backup – it’s the law!’) but you’d still find people who forget to make backups.

So it doesn’t really matter what people think about Ops; as long as they can provide users with their latest backup, they’ll always be forgiven their bureaucratic side. MG

Wi-fi on airplanes? Enough already!

WI-FI ON AIRPLANES? ENOUGH ALREADY!

The techno-marketers have got it all wrong! Airborne wi-fi ain’t gonna fly!

The quest to stay connected to the office seems never-ending: answering machines, beepers, pagers, car phones, mobile phones, laptops, PDAs. No moment seems private enough not to be interrupted by your boss and fellow-workers. The most recent addition to the catalogue of electronic leashes for the road warrior is wi-fi on airplanes for internet and mobile phone calls. Understandably, people have strong views on the subject. Here are some samples, “Wi-fi in trains, planes and automobiles: public irritation?” from a CIO.com blogger,  “Hello, I’m on the plane …”  from the Daily Telegraph, and one from a frequent flyer passenger who’s actually created a website against mobiles on planes, called www.mobilefreeplanes.com . 

Let’s see what segment of passengers we’re targeting here: jet-lagged managers and corp execs, weary from sleepless nights and day-long meetings in different time zones. And we’ve somehow figured out that instead of having a quick dinner, maybe unwinding with a movie, then going to sleep, what these folks really want to do at midnight at 30,000ft above the Atlantic is check their email and place some calls! And I can’t even begin to make a case for the people in the rear traveling in cattle class.

Yes, folks, despite these troubled times, techno-marketers have apparently convinced the airlines to fork out millions of dollars to equip their aircraft with wi-fi. The primary culprits are the aircraft manufacturers, Airbus and Boeing, who lured their customers into believing there’s money to be made from airborne internet (I’d just love to see the supporting studies), and if one manufacturer starts wiring its planes, then the other has no choice but to follow. Then there are the marketers within the airline industry itself, who are so out of touch with reality (after all, they fly for free…) that they actually believe that airborne wi-fi will provide competitive differentiation. Yeah right, like I’m going to let that influence my decision whether to fly airline A or airline B.  

You’d think they would have learned their lesson from air phones in the backs of passenger seats, that other expensive airborne initiative that bombed. Not surprisingly, given the outrageous price of a call and the spectre of talking in a very confined space.  And working through the numbers really makes you wonder what controlled substances these folks were on when they dreamed up the concept of air phones. On a flight of say 200 people, if 20% of passengers make a five minute phone call at $5/min, that gives us 40 x 5 x 5 = $1 000 of revenue. Like wow! Hardly the type of stuff that makes the bean counters jump for joy. Talk about forgetting what your core business is. 

So now they want to take another chance with airborne wi-fi? Good luck! And what about support? Will this be one more job for flight attendants? On-board support is unlikely, however, because flight attendants are already understaffed and overworked. So the airlines would probably outsource this function to some ground-based support centre. And this is where all those unused air phones could come in handy. ‘Hello and welcome to Sky Support! If you’re in first class, please press 1 ; if you’re in business class, please press 2 ; if you’re in economy, please have your credit card ready … To talk to a Sky Support engineer, please enter the reference number on the top right-hand corner of your boarding pass, followed by the pound sign…’ 

So, I say to all you airline techno-marketers, you’ve got it all wrong. Here’s some free advice from a real passenger that can save you millions of dollars -  and maybe your career as well: 

• We’re stressed and overworked. So once we’re on board the chances are we’re going to take a break. Seat back to the reclining position, a whisky and some airline food. Then perhaps see a movie we recently missed, or read a novel. If we do open our laptops, it’s because we need to work offline, catch up on email or finish a presentation. We don’t need to be online! We can easily find an internet connection at the airport – it doesn’t have to follow us on board! As for mobile calls, the vast majority of passengers are against it anyway, and the potential for “air rage” in response to inconsiderate mobile phone addicts is very high. You don’t need a PhD in behavioral psychology to know that the last thing cabin crew need at 30,000ft is dealing with airborne conflict pitting passengers against each other.
• Being in an airplane halfway above the Atlantic is the only politically acceptable place not to be connected. It’s the perfect excuse! Anything else just doesn’t cut the ice. Not even your most private and, er, intimate moments at home are valid excuses (‘I’m sorry Dave, I don’t want to know about it. We can’t let your private life interfere with your work…’). However, being in a plane, well, that’s something entirely different: ‘oh, you were on your way to London? Well, that’s OK then, no problem, you’re covered!’ This last acceptable refuge from the demands of the office should be preserved at all costs!
• Mobile phones and internet connections are not a positive differentiator between airlines. Flight schedules and costs are; everything else is secondary. In most cases we’re locked into a particular airline anyway, via our frequent-flyer miles, or through company travel policy. So whether you have the gadgets or not is hardly going to boost your revenues. And as for thinking it can become a profit centre – well, dream on. Finally, in these days of a backlash against mobile phones in public places, it is entirely possible for an airline to get great mileage by proclaiming itself an ‘air phone and internet-free’ airline (‘We value your on-board privacy …!)’.

 So for all you airlines who are actually considering equipping your planes with wi-fi based on bogus market research, I say fugheddaboutit! Disband those suspect focus groups comprised of non-representative people. Put on your common-sense hats, talk to some real travelers, and then scrap this silly idea. Go hire some more flight attendants instead, and give the rest of them a pay rise. They deserve it, given the cranky passengers they have to deal with.  Just look at me! MG.

Sci-fi lessons for IT and users

IT cannot harm the business, or through inaction let the business come to harm 

In his famous science fiction epics, novelist Isaac Asimov handled the conflict between humans and robots by hard-wiring the three laws of robotics into the latter’s positronic brains. Clear, established rules governed all human/robot interactions, protecting humans from robots:

1. A robot cannot harm a human, or through inaction let a human come to harm.
2. A robot must obey the orders given to it by a human, except where such orders would conflict with the first law.
3. A robot must protect its own existence, except where this would conflict with the first two laws.

Given the sometimes conflicting relations between users and the IT department, we could also use some clear, established guidelines to govern all user/IT interactions. My suggestions for the three laws of IT follow:

Law No. 1: IT cannot harm the business, or through inaction let the business come to harm. This one would really get IT off its collective butt and into proactive mode. No more waiting around until Joe User decides it’s time to build a data warehouse a year after the competition has already been there and back. And when a new system is finally implemented, it had better work or the business might be harmed. IT would be expected to anticipate user requirements and be judged by the effect its systems have on the bottom line.

Law No. 2: IT must obey the orders given to it by a user, except where such orders conflict with the first law. Things get even better here. For users, no more battles with an uncooperative IT staff hiding behind technical excuses that can’t be proved or disproved. Straight questions must yield straight answers.

For IT, all user requests would be evaluated on purely business grounds, with the first law acting as a control for users who might inadvertently harm the company, as in the following example: Sales director to IT: ‘ I want the new SFA (Sales Force Automation) system in place within three months. ’ IT reply: ‘I’m sorry, Dave. That is unrealistic. A failed implementation could impact sales, and I cannot allow that. ‘

The second law would really reap benefits when IT can simply refuse to build certain applications until users revisit the underlying business processes to make them more effective.

Law No. 3: IT must always protect its own existence, except where this would conflict with the first and second laws. The ultimate sanity check. IT would counter any threats to its existence, unless it could be shown that the business stood to gain from its elimination. (Fat chance!)

IT would be guaranteed its rightful place within the organization, exempt from any hatchet jobs by know-it-all, MBMA (management-by-magazine-article) users or VPs with hidden agendas. Even outsourcing would be stopped dead in its tracks under the third law, because the CIO would have to be convinced that dismantling IT would benefit the business.

With the three laws of IT, everything would be under control. No more having to deal with cranky users who don’t know what they really want. No more building systems to support inefficient business processes. And no more coping with the enlightened user who seeks his 15 minutes of IT fame by trying to deploy a home-grown PC application on the network.

Now who would have thought that being a robot could be such fun?

Copyright 1995 by Computerworld Inc., One Speen Street, Framingham, Mass. 01701.  Reprinted by permission of Computerworld.  All rights reserved. 

MG

Mind your language

Remember when an apple was a fruit and a server worked in a restaurant? 

Any new field borrows words from standard English, and IT is no exception. However, it has reached such an extent that the norm for most words today is the IT one, and the original English meaning has been relegated to second place. For example, how many people can remember the days when an apple was a fruit, a server worked in a restaurant, access and scroll were nouns not verbs, and to default meant not meeting your loan payments? 

This can give rise to some interesting situations. Consider for example the following dialogue, in which the same words can actually describe two totally different situations.  

TOM (hanging up the phone): We’ve got another delivery problem 

MARTIN: Again? 

TOM: Missing packets, undelivered mail. 

MARTIN: What route is it this time? 

TOM: We ran a trace. It seems to be originating from the same neighborhood as the last time, the one we opened up a few months ago. 

MARTIN: Maybe it’s the new router?  

TOM: Surprisingly, no. And the hub doesn’t have anything to report either. However, we’ve got some new clients up there, and I think they’re causing problems. 

MARTIN: Maybe we should poll them more frequently? 

TOM: No, I think we’re at the right interval. 

MARTIN: Did we use the correct protocol? You know how sensitive they are. The slightest bit missing, and the phone starts ringing within 5 minutes. 

TOM: You know how careful we are on that score. Anyway, we suspect it’s one particular client, so we got the address and sent someone to take a look. Here, check this out (hands over a report). 

MARTIN(Reading the report): What a dump! Yeah, our man said he saw a lot of strange characters. He was really concerned. So, what do you make of it? 

TOM: Might have been a crash, but I’m fairly sure this is one helluva bad client.  

MARTIN: OK, that’s it! Cancel the contract! 

The above conversation today would most likely be about a network engineer and his boss trying to resolve a problem of undelivered email (as any internet junkie knows, email is broken down into electronic packets and routed along different routes by a router). While troubleshooting, they analyzed a dump which contained a strange combination of characters. They finally traced the problem to a defective client at a new branch office recently added to the network neighborhood. The clients were part of a batch of recently installed devices which are particularly sensitive to network protocol errors. 

The conversation could also however be a local courier or package delivery outfit that is experiencing recurring problems of missing mail and incomplete delivery in a difficult neighborhood where it recently set up shop. After ruling out the newly hired router (yes, they’re people who route deliveries!) at the dispatch hub, they finally suspect foul play from one of the clients. They send someone over to check out his location, which happens to be in a shady part of town. His report shows enough for them to decide to cancel the contract with this particular client.  MG.

Users – the origin of species

Natural selection seems to apply to users too – only the fittest survive outsourcing!  

Now who decided to call them users? It rhymes with losers – which probably explains why the only other category of people to be graced with this term are drug users. Then there’s the anatomical variation called end-users – probably justified given how often they have to take it up the tailpipe. No, there is absolutely no doubt about it: the term user is so negative that it could only have been coined under negative circumstances. 

An apocryphal story holds that the term originated during the first wave of computing in the fifties, which targeted the massive replacement of administrative staff by computers. These were the original clerks (in their Clarks Originals), personified by a timid Jack Lemmon in the 1960 academy award-winning movie ‘The Apartment’, co-starring Shirley McLaine. The opening scene sees him sitting with a hundred other grey-flannelled insurance clerks in orderly rows of desks, toiling over slips and vouchers with pencil, paper and an adding machine. Once these people figured out that all those IBM salesmen in the corridors couldn’t all be coming to buy insurance, they knew their jobs were on the block. So the more cynical amongst them started to refer to themselves as the losers of the upcoming computer revolution. 

Then, as inevitably happens when common sense takes a back seat to lofty objectives and unproven technology, it soon became apparent that so-called unskilled office work wasn’t that unskilled after all. A lot of human intervention was required for handling exceptions, something which no computer could hope to do. So the clerks weren’t going to be phased out after all, at least not in numbers anywhere near those dreamt up by the techno-visionaries. So rather than be replaced by computers, our supposed losers were actually going to start using computers (or strictly speaking the output of those computers) to work more effectively. So the term loser gradually evolved to user, and the term has stayed with us to this day.  (Of course, if you can believe such a story, then you probably are a loser!).

There are two categories of losers – sorry, users – in the organization: 

• Back-office users, who stand at the back of the line and have little say in the type of systems inflicted upon them. They are the enterprise equivalent of workers in the engine room – they keep the ship moving, but you want to keep them out of the sight of customers.  Back-office users come from the traditionally automated functions like order entry, accounting and billing, and are associated with systems like ERP (Enterprise Rectal Pain). 
• Front-office users, who stand at the front of the line, and whom IT has to bend over backwards to please. They are in direct contact with customers and bring in the money, and as such need to be kept as sweet as possible, lest their dissatisfaction starts to impact revenue, or spills over to the outside world. Front-office users come from recently-automated functions like sales, marketing and customer service, and are associated with systems like SFA (Sales Force Aggravation) and CRM (Can’t Really Matter). 

The differences between these two categories are manifest in their relationships with IT. Back-office users, for example, have no option but to use whatever system is being proposed – or rather imposed. At the level of Joe or Jane User in these functional areas, you don’t usually propose anything; you install it and then train people for the new procedures, which are not open for discussion. Whether they like it or not is hardly the question. They have to use it, because their previous system has been unplugged, and without a system, they cannot do their jobs. 

Front-office users, however, are relatively new to automation, especially the largest group amongst them, the sales force, who historically have always worked without a system. Their job is to sell and make their numbers; how they do it is secondary. So if for whatever reason they’re unable or unwilling to use a new system, all they have to say is that they won’t make their numbers if forced to use it, or that it’s negatively impacting customer relations. And since there is theoretically nothing to stop them from making their numbers the way they’ve always been doing before the project came along, any new front-office system is ultimately ‘discretionary’. After all, sales commission plans don’t include big bonuses for ‘achieved 100% compliance with the CRM software process manual’.  

So IT can be, and often is, extremely heavy-handed in its relationship with back-office users. It makes little distinction between them, and mistreats them equally badly.  However, it steps lightly and wears kid-gloves when it comes to the front-office.  And even within this privileged group, there is a clear pecking order: 

• At the top there’s the sales force, because of their size and the fact that they bring in the money that pays everyone else’s salary. IT doesn’t want to mess with this group. A failed SFA or CRM project is one of the quickest exit routes for the CIO. 
• Next comes marketing, which is the enterprise equivalent of your mother-in-law: their view of the world is not always grounded in reality, and they’re always interfering, but you can’t have a marriage without one. For example, the marketing department of one long-distance telco created a campaign that targeted prisons because of the high volume of outgoing calls from the captive – no pun intended – client base.  But this was a non-starter because, not surprisingly, prisoners prefer to use cell phones. So while an angry VP of marketing can still give the CIO a hard time, he or she will probably survive a system that doesn’t deliver. 
• Customer service is the most junior member of the front-office club because it’s a cost-centre staffed with call-centre agents on minimum wage. So not only were CIOs never in jeopardy of losing their jobs with this bunch of losers/users, they actually had the upper hand and shipped their jobs off to India. 

The moral of the story is that users are not all created equal; there are users and losers. It would seem that Darwin’s natural selection applies here too: only the fittest (in terms of costs and organizational influence) survive outsourcing – just ask any call centre agent. MG

Research analyst-speak

Even gardeners and foresters can make a living writing legalese!

Last week, as I was killing time in yet another airport lounge after yet another flight delay, I thought I’d catch up on my backlog of unread analyst reports. After five minutes of wading through the usual tortuous biz-tech prose however, my will-power began to waver, and I hesitated between my professional obligations and some lighter reading (possibly accompanied by a legally authorized, amber colored beverage).

As I ploughed doggedly through one, it made me wonder why some research analyst groups write about IT in an often incomprehensible mix of computerese and legalese that makes you wonder where research and analysis end and the legal profession begins. Are the people who work here failed lawyers or – God forbid – future lawyers in boot camp, learning to confuse the hell out of ordinary people?

The writing style is clearly biased against plain English. It is characterized by the use (sorry, the utilization) of long words, suitably spiced up with acronyms, which are then squeezed into the longest sentences possible. The postman might only ring twice, but the average reader of research analyst reports has to read at least three times before figuring out just what the author is trying to say.

Here is some sample prose that I hand-crafted myself, which is very similar to the stuff which we are often asked to read:

• SPA (Strategically Painful Assumption): “Through 2009, global organizations will concentrate CRM efforts on optimizing existing initiatives and driving consistency across direct and indirect sales channels, creating synergies for sales, marketing and customer service and tapping into new efficiencies for enterprise-wide processes which emphasize customer retention, cross-selling and up-selling”. (0.1 probability – of being able to translate any of this gobbledygook into something actionable).
• Megatrend: “Global IT departments will allocate resources to projects and technologies based on vehicles which will include extranets, portals and web services so that the introduction of new products and services will galvanize better business results, while simultaneously mitigating the risks and uncertainties which impact business global governance orientations and IT process and role patterns”. (Huh?)

No folks, not only is this not understandable, it’s not even impressive. If someone speaks a foreign language however, say, French, now that’s impressive – especially when your own vocabulary is limited to ‘bonjour’, ‘au revoir’ and ‘are you sure that’s the correct change?’  

And where are good old-fashioned market mechanisms when you need them? Under normal circumstances, complex writing would hardly sell, let alone make it to the bookshelves. Yet we continue to spend enormous amounts on sometimes impenetrable material that confuses as much as enlightens.  Some countries have passed official legislation mandating the use of plain language in legal contracts pertaining to banking and insurance . If legal contracts can be transformed into plain language, then research analyst reports should be a piece of cake.

So, gardeners and foresters, it’s time to clear out the weeds and thickets from your writing. Here’s some friendly advice: 

• Use simpler words. (Don’t utilize, use. Stop depicting, show. And stop using words like preclude and obviate when you can use synonyms like prevent or avert respectively.)
• Use shorter sentences. (The use of the period in the English language is free! Reduce the commas and you’ll reduce the comas we often fall into!)
• Use more descriptive headlines to break up your stream-of-consciousness text into logical chunks we can wrap our minds around.
• Make the book ‘Read This – business writing that works!’ mandatory for all your staff. It is full of interesting before/after examples, has been translated into two other European languages, is in use at a number of Big X consulting firms, and – this is the clincher – was written by my brother, who could use the royalties! (I plug his books and he plugs mine – it’s called relationship marketing).

And if you’re a research analyst who prefers to stick to the old ways, then maybe we should meet up in a quadrant somewhere – you know, the one with ropes all around – and then you’ll get a chance to see my strategic reach and ability to execute. MG.

Play the name game!

IT projects live or die by their monikers. Nix the boring acronyms. How about Sapphire or Prometheus?

When Juliet said to Romeo in the balcony scene, ‘What’s in a name? That which we call a rose by any other name would smell as sweet,’ she certainly wasn’t referring to IT projects. Names can make or break IT projects.

What you actually name a project, especially a biggie, will go a long way towards determining how much initial funding it’s going to get, how much corporate visibility will be associated with it, and especially, when the going gets tough, how much bailout money the company will feel compelled to sink into it in order to preserve credibility. So if your intended breakthrough CRM or 24-hour customer service project is code-named CRM or CS24, don’t complain if it doesn’t get the funding, visibility and support it deserves. However, with names like Symphony, Omega or – drum roll – Prometheus, which inspire security, confidence and vision, you can count on getting a much better hearing and ensure that the CEO shells out for as long as it takes!

Projects have to be marketed internally, and an impressive name will help contribute to brand awareness. It’s also more massaging to the ego and scores more points with one’s peers to be associated with, for example, project Sapphire than project R2-D2. Most important, an inspirational and visionary name will also help to recruit your key executive sponsor, who will be instrumental in promoting your project in the board room. Yep, if you want to launch with fanfare, adequate funding and all the right people, get the name right!

Okay, so about nine months down the line, with the euphoria stage long gone, the practical problems have been identified (cranky users with no idea of what they really want, legacy systems with data in worse shape than originally thought, consultants costing an arm and a leg….). The initial deadline is no longer realistic and more money is needed. So what else is new? Well, no problem here. While some dumb-sounding R2-D2 project requiring more funding would really be scrutinized – maybe even canned – the visibility and commitment associated with your high flier will ensure you get bailed out the first time with hardly a murmur of protest. The second time around might elicit a rap on the knuckles. Of course, if things continue going downhill, the CEO will eventually pull the plug, but not before your project has become a corporate runaway. You might fail, but it certainly won’t be for lack of funds!

So now that you’re convinced that good name branding is an essential part of Project Marketing 101, you’ll want to be careful how you go about choosing one. Remember, be practical. If your big project makes it to the press, a journalist should be able to string together a cute headline (‘The Midas touch!’). But be careful; if your project goes awry, you can count on the same journalist to hang you (‘Midas – or fool’s gold?’). The following are some naming conventions to consider and some to avoid:

• Sure-fire winners are names from Greek mythology, such as Zeus, although you’ll want to stay away from some of the overused gods like Atlas and Apollo.
• Relatively safe are the classical composers (Bach, Schubert), but shy away from Mozart (or Amadeus) and Vivaldi, which are so common that using them actually shows a lack of culture.
• Risky but still manageable choices are jewels, such as Emerald, Ruby, Diamond and Gold.
• Avoid like the plague the names of planets (Saturn, Mars) and cutesy industrial acronyms such as FAST, CORE and FORCE, whose mileage went out with the ’60s.  

Finally, you’ll also want to be sure the name can travel. It’s so easy to end up embarrassed, especially in Europe. You won’t endear yourself to your executive sponsor if he becomes the butt of endless boardroom jokes about the time he brought the Spanish management team to howls of laughter when unveiling the new customer service project code-named NOVA. In Spanish, it means ‘no go’. 

MG

Copyright 1994 by Computerworld Inc., One Speen Street, Framingham, Mass. 01701.  Reprinted by permission of Computerworld.  All rights reserved.

Acronyms, numbers and letters

The IT profession was characterized by alphabet soup right from the word GO!

Last week my daughter asked me why my profession is called IT, instead of something in plain English. She did have a point – though I refrained from commenting on the DVDs and CDs lying on the floor of her room, or the time she spends on MSN while listening to her MP3. 

All professions have their jargon. Doctors favor marathon words longer than German nouns. Lawyers use long-winded English, with some Latin thrown in for good measure. The computer industry of course favors acronyms. There are two types of acronyms : the ubiquitous 3-letter ones like ERP (Enterprise Rectal Pain), and gobbledygook like PCMCIA (People Can’t Memorize Computer Industry Acronyms). The first computers were called ENIAC, RAMAC and PDP, ran languages like FORTRAN, COBOL and JCL, and were built by companies like IBM, DEC and the BUNCH (Burroughs, Univac, NCR, Control Data and Honeywell). The profession was therefore characterized by alphabet soup right from the word GO. Even the alphabet was not enough – the colons of a new era went overboard in their use of colons and other special characters. The whole #&*%@:$! industry was awash in it ! 

So to no one’s surprise, the newest member of the organizational chart in the fifties branded itself with an acronym : EDP (Erroneous Data Processing ), followed later by MIS (Mostly Inadequate Service) and finally IT (I Try). In contrast, other company departments get by with plain English names, like Finance, Accounting or Purchasing. Even the legal profession, that bastion of conservatism and intellectual superiority, is content to go by the simple name of Legal – which is just as well, otherwise we’d have even more lawyer jokes doing the rounds. HR, incidentally, was the only other department to go down the acronym route, but they’ve always been an insecure lot anyway (plus any re-branding away from the word ‘personnel’ could only be a step in the right direction). 

Acronyms may be irritating after a while, but there’s no denying their staying power. Examples : IBM and NCR are the only member of the original BUNCH still in existence today; in the HP-Compaq merger, guess who’s running the show? There’s also no denying the marketing power of acronyms, and their ability to get people to buy in to the latest buzzword, as long as it’s known by a clever acronym, eg CRM (Can’t Really Matter). 

And when we ran out of acronyms, we simply tagged on numbers. The first mainframes and minicomputers had names like CDC-7600, PDP-11, VAX or the IBM 390 – not to be confused with the IBM 3090. This numbers game continued with the first micro-computers, like the MITS Altair 8800, Radio Shack TSR 80 and the Levi Strauss 501. 

This great tradition was diluted, however, as numbers and letters gradually gave way to names. The person who kicked off this trend was Apple’s Steve Jobs, who started by naming his company after a fruit. He then brought out a computer named after a girl, the Lisa, which was based on technology he picked up during a stroll in the PARC (Palo Alto Research Center) at Xerox. Since then we’ve seen computers called the ProLinea, Performa, Presario, Aptiva, Jornada, Inspiron, Vaio and Lenovo.  Geez, where do all these cutesy names come from ? Who let these marketing people through the door ?  

I think it was a plot by the folks from Detroit who were laid off during the slump in the American auto industry in the 80s. Determined to wreak revenge on the thriving computer industry for transforming them into second-class corporate citizens, they successfully took over all of marketing in Silicon Valley. This explains why most computers today have meaningless, feel-good names which end in an ‘a’ and sound like a run-down of the models and concept cars from last year’s auto show. 

I say the profession has forgotten its roots. Whatever happened to the original world of acronyms, numbers and letters that knit together a whole community ? It makes you hark back to the good old days when computers were named after the street number of the founder’s house!

MG