Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
An Adventure in IT Consulting

An Adventure in IT Consulting

|Views: 48|Likes:
Published by Eric Nyati

More info:

Published by: Eric Nyati on Oct 27, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





For its next-generation application, XYZZY Software Inc. decided to do a major overhaul using the latestand 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 leastsix 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 itwill 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, “Lukesays 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 theexisting 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) coaxeseveryone 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 theschedule so they can have a beta version ready by their annual conference. Development doesn’t feel verygood about the adjustment, but they figure they can just work extra hard to make that deadline — andmaybe 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 towork.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 thecompany really knows what that code is supposed to do. They get existing customers involved in thediscussion, 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 hisoriginal prototype. It’s clear that the prototype didn’t do everything that will be required of the same pagesin the full version. The security and internationalization mechanisms of the existing system will not migrateto Plugh, and the replacements have not even been pondered. Luke finds himself in a maze of twisty littlerequirements, none of which are alike. Sales is still telling customers it will be ready by next year’sconference, but upper management is getting nervous. Development insists they can keep the project onschedule, but management demands a reality check.The employees decide to call in an outside consultant to validate their plan. After spending several daysexamining both the old and nascent forms of the application, talking to users and developers, and crunchingthe 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 unspecifiedrequirements you run into along the way. Throwing more developers on the project will not help. But I canrecommend a different approach that will make incremental improvements to your existing application andallow 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 theconsultant shows that the very first incremental improvement could be to the portion of the application inwhich users spend 80 to 90 percent of their time and which would make a great demo if it weren’t so uglytoday.1
Whether XYZZY Software followed the plan laid out by the consultant is not as important as the fact thatthe employees listened to what she said
to do.Prior to the meeting, at least 20 employees knew the project was headed off the rails, so why didn’t anyonesound 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 employeesfocused 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
different story).Unfortunately, many of these scenarios do not turn out as happily as the tale of XYZZY Software. I haveseen some companies sink several years and millions of dollars into these types of projects before comingto 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 youhave to say, the most you lose is the engagement. If they listen to you and it doesn’t work, things could getugly. You’re not part of the protected herd of employees who will be all too happy to blame you. So, you’reincented 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, butthe 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 someconsultants who don’t have the backbone to tell their clients that they’re making a colossal mistake.
What happened to Luke? He was promoted into project management, of course. From there, he worked hisway up to Director of Development before he had a falling out with management and became anindependent consultant.==
Sterling "Chip" Camden- 06/06/08 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?Reply 
Ed Woychowsky- 06/09/08 Again and again and again.Reply 
dofek@...- 06/09/08 most of projects' challenges are human. neither technological nor business. a modernIT consultant should focus on people dynamics. meaning, let them do their best by methods of brainstorming, mirroring, open comm channels etc. direct advice or activity is relevant only rarely and may betoo dangerous to both sides.Reply 
reisen55@... - 06/09/08 My company just picked up an account due to an IT consultant who totally lostcontrol. 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 oldconsultant panic'd, bought a 500 gb drive on his own dime, left it there and fled. WE come into a grandmess and after a heroic 2008 start have everything in place including standardized desktops, new server,2
verified backups, remote control and more. The old consultant - please, find another field. You will not be promoted. Ever.Reply 
Sterling "Chip" Camden- 06/09/08 ... if you've never restored from backup, you don't have a backup.Reply 
 jereg- 06/09/08 The larger the company, the bigger the mess. It happens all too often. A kid thinks he'sgods gift to programming comes up with a nifty idea that he has no idea how to implement it. But it soundsgood. 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 thedepartment because I had the nerve to point out the pitfalls. I learned to keep my mouth shut and let otherstake the heat when a project fails. I won't get promoted, but I get to keep my job. It's sad that this happensin too many companies, mostly because IT managers seem to have little experience with the IT industry.Reply 
Sterling "Chip" Camden- 06/09/08 That's exactly what allows these kinds of projects to go under. Me, Iwas 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.Reply 
dawgit - 06/09/08 It's one (of many, I'm sure) social skill I've never managed to aquire. If it is, it is, if itain't, I don't don't keep quite about it. <sighs quietly> -dReply 
techrepublic@...- 06/09/08 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'rereally showing your age! I will now disappear in a puff of greasy black smoke3

Activity (2)

You've already reviewed this. Edit your review.
1 hundred reads
developerskills liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->