Discussion on:

An Adventure in IT consulting

Parts of this story came from at least four of my clients, one former employer, and at least three prospects who didn't listen.

How about you?

Again and again and again.

most of projects' challenges are human. neither technological nor business. a modern IT consultant should focus on people dynamics. meaning, let them do their best by methods of brain storming, mirroring, open comm channels etc. direct advice or activitiy is relevant only rarely and may be too dangerous to both sides.

You're right -- the human part of the equation is always the hardest part to solve, especially because it often actively resists solutions.

I am sure we all have seen one of these...

At Aon Risk Services in that year of false disaster 2000, a contract was signed to install a new total management control system that did "everything" for reinsurance, and it was called BRIDGE. Beautiful thing. But remember this is calendar year 2000 when we were new to Windows 2000, Windows XP was 2 years away and the world was mostly Windows 95 or 98 with NT around.

Nobody noticed that BRIDGE only ran on Windows 2000.

Every single computer was running Windows 95 and every single computer (maybe 200 of them in our office alone) did not have enough power for Windows 2000.

Ooooooooooops
PANIC
MASS PURCHASE, GHOSTING, BOXING, LABELING OF OLD COMPUTERS, SHIPPING, .......

*****

My manager scheduled a meeting to discuss the vulernability of the World Trade Center with corporate IT. The meeting was set for September 19, 2001.

Told ya so.

Oh man -- that would be funny, if it weren't so very, very sad.

The in-house IT department rebuilt the World Trade Center infrastructure within 2 or 3 weeks, pending a few souls who were too shell shocked to return to work so quickly.

Can you imagine the time delay and Service Level Agreement meetings if this was handled as an "outsourced" project?

*****

But outsourcing does have it's benefit, for the outsourcing company, not the client. To wit: CSC agreed with Aon that a specific project would consume 20 hours of billable time. Done deal. The in-house technician (who was now employed by CSC before being fired in late 2005) did the project in Ten (10) hours, not 20. What did Aon pay? For 10 hours or 20 hours? You guessed it if you went for 20. CHEAPER, FASTER and BETTER.

Periodically, I get a call to help a project that has derailed.

Now being just slightly experienced in this field (28years in IT, + 10 in construction), I know that projects USUALLY don't get derailed. If managed reasonably they take exactly the length of time the product needs them to take.

Projects (usually) get "derailed" either because the original concept was out to lunch , the original estimate was out to lunch or because the people involved are working on a different project than what management thought they were working on.

So I've started asking before I even start - "Are you prepared to cancel this project?". If the answer is no, then I know that they aren't really interested in saving the project -- just their face. And I turn the contract down (with a suitable explanation of why I ask the question -- and the comment that if they are not prepared to accept bad news I probably can't help them since they are unlikely to be willing to make the hard decisions which may be necessary).

It's amazing how many companies answer no - even after the explanation! (And of those that do say "yes" the number who refuse my (typical) first recommendation of putting the project on hold long enough to redesign the project).

Glen Ford

That's a great point. No project should be a sacred cow, because a failed project would undoubtedly cost the company more than never attempting it at all.

But oftentimes a company has an urgent need to do something to meet their needs or the needs of their users, so manybe when they say "no" they're not really answering your question because they think that canceling the project means doing nothing instead.

My company just picked up an account due to an IT consultant who totally lost control. Server crash in late 2007 and they lost all of their accounting data because the consultant was backing up OTHER OLD DATA on tapes too small for capacity, so everything was useless.

The old consultant panic'd, bought a 500 gb drive on his own dime, left it there and fled.

WE come into a grand mess and after a heroic 2008 start have everything in place including standardized desktops, new server, verified backups, remote control and more.

The old consultant - please, find another field. You will not be promoted. Ever.

... if you've never restored from backup, you don't have a backup.

The larger the company, the bigger the mess. It happens all too often. A kid thinks he's gods gift to programming comes up with a nifty idea that he has no idea how to implement it. But it sounds good. The more experienced staff know that it's doomed from the start. Management NEVER wants to hear the down side.

I've spent 25 years in IT and this happens every day. I know I've lost my status in the department because I had the nerve to point out the pitfalls.

I learned to keep my mouth shut and let others take the heat when a project fails. I won't get promoted, but I get to keep my job. It's sad that this happens in too many companies, mostly because IT managers seem to have little experience with the IT industry.

That's exactly what allows these kinds of projects to go under. Me, I was never able to stand idly by and watch the train wreck. One time, it might have indirectly cost me my job to speak out, but it has always helped more than it has hurt.

It's one (of many, I'm sure) social skill I've never managed to aquire. If it is, it is, if it ain't, I don't don't keep quite about it. -d

I call what you mention "Committing the Truth". Often, when you do this you become the pariah and are labeled "not a team player". As a consultant, I don't have to worry about that. Honesty is, in the long run, the best policy after all.

Oh, and I loved your "Adventure" references. You're really showing your age! I will now disappear in a puff of greasy black smoke! :-D

Ha -- I wondered who would notice first!

Yes, my programming career begins in the late 70s.

One of the early Fortran versions of the Adventure game was the program that made me want to become a programmer. I was amazed that a computer could be made to understand, albeit primitively, commands that you typed -- and respond to them. I had to know how it worked, and began teaching myself computer languages.

Yes, with my bare hands.

I've been in the field since 1973. I loved playing Adventure. I couldn't wait to get my hands on the source code to see how Crowthers did it. Amazing for the day.

With your bare hands!?! Amazing! You have just killed a giant with your bare hands.

or

You have just killed a little bird. Its body disappears.

Fond memories. :-D

It's not that the managers don't know IT (at least not those in IT). It's that they've learnt the same lesson as you did ... shut up or get branded "Not a team player".

Now outside IT ...

Glen Ford

.... resulting in the inability to do anything truly daring, while perpetuating the inane death march.

In the story, Luke started the ball rolling by delivering a SWAG estimate to non-technical people. I've learned to avoid doing this ever, and point to the need for gathering requirements, design, etc. Three other things I've experienced that you could have added: the non-technical (or no-longer-technical) project manager who insists on making technical decisions, and the virus that hits the team at a critical juncture through the hero who never takes a day off, and leaves most of them throwing up when they expected to be coding, and the unscrupulously ambitious but mildly talented developer who keeps on trying to undermine the efforts of others. Death marches tend to be the outcome of overly macho management with overly ambitious timelines with assumptions that all the questions have been answered and their developers are too good to encounter problems.