Leadership optimize

An Adventure in IT consulting

Chip Camden presents a fictitious scenario in which a project goes off the rails, and an IT consultant is called in to offer wisdom. Find out what IT consultants can learn from this example.

For its next-generation application, XYZZY Software Inc. decided to do a major overhaul using the latest and greatest "best practices" framework for enterprise applications: Plugh Version 2009.

To do the prototype, XYZZY hires Luke, a bright young developer who has been using Plugh for at least six months. In no time at all, Luke whips up a working example of what the application might look like -- well, three pages of it anyway. Everyone who sees it says "ooh" and "aah" and wants to know how long it will take to convert the entire application -- salespeople in particular show special interest in that question. Luke (who knows very little about the existing application but has seen the regular demo) tosses out "oh, probably about six months."

This becomes a war cry for the sales force. They descend on all levels of management with cries of, "Luke says it can be done in six months! We desperately need this new look and feel ASAP in order to compete!" Upper management asks the Director of Development if this really can be achieved so quickly.

During a development meeting, the old-guard programmers lay out all the (known) complexities of the existing system in order to show Luke how far off he is in his projection. The Director of Development (who doesn't want upper management to think he's being a nonagile wet blanket about the project) coaxes everyone to agree that it can be done in two years. Of course, they'll have to release an interim version of the company's current product in one year for regulatory changes and bug fixes, so there will be ongoing parallel development.

Management, marketing, and sales approve of the plan -- after sales gets three months trimmed off the schedule so they can have a beta version ready by their annual conference. Development doesn't feel very good about the adjustment, but they figure they can just work extra hard to make that deadline -- and maybe leave a few of the lesser-used features out of the beta if necessary.

A new team is formed, and Luke is named the lead programmer. The team also includes several of the old-guard programmers, a couple of testers, a documentation specialist, and a project manager. They set right to work.

The team soon discovers that not all areas of the application easily translate into the Plugh framework. When they attempt to define the requirements of these sections, they realize that no one who is still at the company really knows what that code is supposed to do. They get existing customers involved in the discussion, which leads to the startling discovery that nobody agrees on whether the current behavior is a bug or a feature.

Six months into the project, they only have several more input forms developed than Luke had in his original prototype. It's clear that the prototype didn't do everything that will be required of the same pages in the full version. The security and internationalization mechanisms of the existing system will not migrate to Plugh, and the replacements have not even been pondered. Luke finds himself in a maze of twisty little requirements, none of which are alike. Sales is still telling customers it will be ready by next year's conference, but upper management is getting nervous. Development insists they can keep the project on schedule, but management demands a reality check.

The employees decide to call in an outside consultant to validate their plan. After spending several days examining both the old and nascent forms of the application, talking to users and developers, and crunching the numbers, the consultant renders this verdict:

"Your current approach is doomed to failure. From the sheer size of the project, it will take at least three, possibly four, years to even get to a usable beta version -- depending on how many other unspecified requirements you run into along the way. Throwing more developers on the project will not help. But I can recommend a different approach that will make incremental improvements to your existing application and allow you to release a new version every year without massively parallel development."

The employees (except sales) breathe sighs of relief. And even the sales team is mollified when the consultant shows that the very first incremental improvement could be to the portion of the application in which users spend 80 to 90 percent of their time and which would make a great demo if it weren't so ugly today.

Whether XYZZY Software followed the plan laid out by the consultant is not as important as the fact that the employees listened to what she said not to do.

Prior to the meeting, at least 20 employees knew the project was headed off the rails, so why didn't anyone sound the alarm? Because they worried whether being the naysayer would damage their career. Their fear kept them silent and prevented them from thinking about alternative solutions; instead, these employees focused all their energies on achieving the impossible.

Truth in fiction

Even though there is no XYZZY Software or Plugh development framework, I have seen this same story play out many times. I have played the part of Luke, the Director of Development, and the consultant (though I've never been a woman, but I have played one on stage -- that's an entirely different story).

Unfortunately, many of these scenarios do not turn out as happily as the tale of XYZZY Software. I have seen some companies sink several years and millions of dollars into these types of projects before coming to their senses. I genuinely feel so badly for them that I don't even smile when I say "I told you so."

An outside consultant can provide the voice of disinterested honesty. If the client doesn't like what you have to say, the most you lose is the engagement. If they listen to you and it doesn't work, things could get ugly. You're not part of the protected herd of employees who will be all too happy to blame you. So, you're incented to be as honest as possible about what will and will not work. Also, be sure to keep yourself out of office politics. Obviously, you're going to feel beholden foremost to the person who signs your checks, but the best service you can provide the client is to tell it like it is.

There are many more companies that never even call in a consultant to tell them so. And there are some consultants who don't have the backbone to tell their clients that they're making a colossal mistake.

Epilogue

What happened to Luke? He was promoted into project management, of course. From there, he worked his way up to Director of Development before he had a falling out with management and became an independent consultant.

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

23 comments
jereg
jereg

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.

PMPsicle
PMPsicle

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

Sterling chip Camden
Sterling chip Camden

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

PMPsicle
PMPsicle

In my experience, it is more likely that the ex-technical manager continues to make the same mistake they made when they were technical ... they underestimate the difficulty involved. (That by the way is a study proven common issue for technical types). It's not that they are intentionally macho and overly ambitious -- it's that they honestly believe that the work is doable in half the time it will really take (and that the complexity is 75% of reality). Now truly non-technical managers are a different thing ... they don't have a clue but they believe that the rules that apply to operations applies to projects (i.e. reduce the budget by 10-20% in order to get rid of fluff - which doesn't work for projects). Glen Ford

A_dangerous_mind
A_dangerous_mind

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.

Sterling chip Camden
Sterling chip Camden

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.

techrepublic
techrepublic

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

techrepublic
techrepublic

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

Sterling chip Camden
Sterling chip Camden

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.

dawgit
dawgit

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

reisen55
reisen55

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.

Sterling chip Camden
Sterling chip Camden

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

reisen55
reisen55

My manager from Aon Group has become a certified BCP/DR planner and consultant and the one aspect of backups that SHOULD ALWAYS BE DONE at some time is to TEST what you are backing up to make sure it does work WHEN YOU NEED IT TO. I do not like making discoveries about life at 2:15 am on Sunday morning, and because of my World Trade Center background, I consider one of my most important jobs is to COVER THIS GROUND thoroughly. Of everything we do in our field, this is the most important. Disasters do not happen reguarly, thank Microsoft for at least something good. But when they do, those backups are your best friend IF TESTED AND VERIFIED on a frequent basis. This cannot be done remotely either, you have to BE there, on site to see how it all works. Miscellaneous Notes Forget tape, Hard drive is better, cheaper and far faster. Took me 35 seconds to restore valid data for a client one night that only represented his entire business. Know how your client operates his business, do not just be a consultant on the sidelines. Accept fault when you mess up and be prepared to un-do your mess quickly. TEST before you make changes and be prepared to RETURN back to what you did before you did to make your mess.

Sterling chip Camden
Sterling chip Camden

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?

PMPsicle
PMPsicle

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

Sterling chip Camden
Sterling chip Camden

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.

PMPsicle
PMPsicle

Actually the key is that projects usually fail because they couldn't succeed. There is a tool from the construction industry which can predict success or failure with an 80% accuracy rate. The last step in the review is the hiring of the project manager. Basically it measures the quality of your approval process and how open you are to a quick dose of reality. Unless you are willing to admit that project as approved is impossible you can't be prepared to modify your expectations to meet reality. The other piece is that you need to be prepared to stop the project until you have identified what the real project is and then approve that. Many management teams are unwilling to accept the loss of face involved in stopping a project let alone accept the possibility that the project should never have been started in the first place. And that the product/scope needs to be heavily reduced in order to achieve a doable project. Glen Ford

reisen55
reisen55

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.

Sterling chip Camden
Sterling chip Camden

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

reisen55
reisen55

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.

dofek
dofek

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.

Sterling chip Camden
Sterling chip Camden

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