| |
 There is a disease eating away at the IT Industry, and has for many years now. It has only gotten fatter because of the dot-com boom. It affects every project, and every firm that I have dealt with, and I'm sure these words will ring true with you as well. The industry has it's paradigm upside down, and regardless of the root cause, it's going to continue to burn out employees, sink projects, and destroy firms until something changes. The disease is this: we allow our customers to run their projects and make IT decisions, even if the customers are not informed or educated about IT. We let the customer make decisions about coding standards, features to add or remove, platforms to be developed on, delivery dates, layout, etc.
I think we can all agree that the customer has to have input, and they have to be happy with the final product. It has to be tailored to their needs. Truth be known, this problem is not entirely their fault. As with any person, the more control they can have when they're spending their own money, the more they'll take. That's natural. More blame lays on us, the IT industry. We have to learn how to say "No". No. It's a powerful word, and is intimidating because of its power. It stands on its own. It is its own statement. It says "Your demands unreasonable" or "That's not within the scope we already defined". We're afraid to say no because we're worried that if they do, the customer will go somewhere else. Yes, that's a risk you run, but honestly, if you tell a customer that what they want is unreasonable, and they refuse to accept your professional opinion, do want them as a customer to begin with?
 | | "The industry has it's paradigm upside down, and regardless of the root cause, it's going to continue to burn out employees, sink projects, and destroy firms until something changes." | | |
An honest mechanic wouldn't sit by and agree to do the work when the customer came in for an oil change and said, "Replace the muffler, change the spark plugs, make the engine a V-6, and I want the car to be green now. Oh, and I have this coupon. And I need this all done in two hours. My nephew's a mechanic in his spare time after school, and he said he could do all that in two hours so I want it in an hour." The mechanic would say "No" and list the reasons why. An architect would not sit by if a customer came to them and said, "I want you to use Qwik-rete here at the base of my skyscraper, and straw and mud over here, cover this with plaster and use glass for the roof". The architect would say "No". A surgeon would not follow orders if the patient said "Remove my gall bladder while you're down there doing my liposuction. I already have one bladder, I shouldn't need a second!" The surgeon would say "No" and give reasons.
Nevertheless, the IT industry is afraid to use that word. A customer comes in and says "I want my application to talk to SQL Server, DB2, and these four additional non-normalized Access 97 databases my employees have kept for themselves and read these XML files, it has be usable on our 333mhz Pentium machines, render geographic maps in stunning 3D with fly-over, export to Excel on the click of a button, automatically update according to the whims of Andalusian Goat Herders, and since we're hiring a college graduate to maintain it, I'd like you to do it on the web with ASP." Excuse me? No. What you want is unreasonable. I can do it, but I'm not going to throw out a figure or timeline and I can guarantee that for the requirements you just listed the figure I give you will not be to your liking. But instead, we all go "Hmm, okay, I know it CAN be done, so I guess I COULD do it. I haven't used ASP for 4 years, but I can try..."
Saying No is a Good Thing:
We're trained professionals and part of our job should be to educate the customer if they so desire, or at a minimum educate them that they are making poor decisions. Furthermore, we should be willing to make a stand when something is unreasonable.
Clients will make demands that while reasonable to them, are unreasonable to perform. And that's the nature of clients. A client would indeed prefer to get everything they've ever wanted IT-wise for free, and without maintenance headaches, and it should just work they way they expect. Those are ideal demands, they always want to have it their way, but folks, this isn't Burger King. Firms and their customers compromise. That's how business is done...except when we do business.
Many methodologies, including Extreme Programming, as well as other methodologies has shown us repeatedly, and we should all instinctively know and understand that there are four metrics for any structured project:
Quality is to remain fixed while the others fluctuate. Scope goes down and so can money and time. Scope goes up and so will money and time, and so on. However, what ends up happening is the client gets to set the scope. They get to set the deadline, the only thing they have no final control over is the money, and they still try to barter that down, and even there, we usually end up relenting. What ends up happening is that quality does suffer, which ends up hurting everyone from the client down to the developer. This happens because no one is willing to say 'No'.
Not Everyone Is A Programmer:
Many smaller businesses, the meat and potatoes of the IT Industry, and the economy in general do not have their own IT people internally. The closest they have is Bob, from Accounting, who did some Access VBA programming 6 months ago to build some little applications to help during inventory; or you have the owner's nephew who builds web pages after school and dabbles in Flash. Now the client is ready to move on to a more professionally built application that will take them to the next level, and they want do everything in their power to make sure that when the time comes, Bob, from accounting, can maintain the application. This is a lose-lose for everyone. Instead of the application being built in the best fashion possible, with the best possible tools, and in the best manner, it's been spindled and mutilated so Bob can do another job in addition to his normal one. Beyond that, who knows what standards Bob used when he created his application, but everything's now being done to his comfort-level.
The fact of the matter is that even though maintenance is not a fun time, it's a valuable resource for us as IT professionals, and it's good for the client if we do it. Instead of the client having to spend time and additional resources trying to extend their application they can continue to guide the evolution of their tools with the original maker. It's a source of renewable income. Welcome the chance to do maintenance. Moreover, say No to the client when they want everything tailored to Bob the accountant.
Your Buddy the Client:
We've heard this a thousand times. Clients are worried that once we build an application for them we're going to turn around and start our newly gained business expertise to their competitors. They express this fear at the same time that they're aggressively pursuing every customer in their market, INCLUDING their competitor's customers. It's a double standard, it's a silly one, and why should we abide by it?
| "We need to make money, and it is not made in being the customer's buddy." |
| | |
IT is no silver bullet. Having your IT resources all stitched up and nicely done will get you further in the business world, but it's no substitute for hard, honest work, taking care of the customer, and providing unique and innovative products. Regardless of how good our technology solutions are, they're not going to suddenly drive their competitors out of business.
We need to make money, and it is not made in being the customer's buddy. It's made in reusable libraries, shared expertise, and pursuing all available markets. It's made in taking those components you've built and spreading them across many customers. If we're partnering with many customers just to give them the warm fuzzies, we've spelled our own doom.
That isn't to say that you shouldn't have a relationship with your customer, only that this isn't high school and you shouldn't be going steady with your customer. When the customer demands that you work ONLY with them, say "No", unless they've given you a very good reason to.
Every Decision Has A Cost:
We need to recognize and acknowledge the cost of each decision they're making, as well as the limitations of each language, platform, and development environment.
Many times a company will ask their employees to make decisions, to make choices that are bad for the project, bad for the client, and ultimately bad for the employee as well. It takes courage to say 'No', and it can be risky, but it should be a requirement.
IT Companies live in fear that if they don't jump on an opportunity, or take a bid, regardless of the consequences, they will lose out to another company that will take that opportunity. Therefore, they take on risks they shouldn't have, and those risks get pushed downwards to the project managers, who them push the risks further down onto the developers. One single act of acquiescence on the part of one person in a sales meeting has stiffed many people. Someone needs to be willing to say no.
Not Every Challenge Is Worth Taking:
| | | "IT Companies live in fear that if they don’t jump on an opportunity, or take a bid, regardless of the consequences, they will lose out to another company that will take that opportunity." | | |
IT people have a strong competitive edge. Despite the often-flabby demeanor, and pasty skin, software engineers and other computer professionals view themselves as jocks. A client asks for something, and even if it's not a good request (especially if it's not a good request), or even more importantly what's best for the client, we all still think, "I could beat that challenge". Part of that comes from IT people thinking "I know it's not a good idea to do that, but I'm sure there's a way to do that!" An IT person doesn't want to say "No" from fear of appearing incapable, or weak, losing their jock credibility.
Nevertheless, that does not escape the fact that R&D work does not belong on one client's dime, unless the client has SPECIFICALLY requested it to be so. All of your clients should foot R&D costs. You and your company build something and then charge each customer that you have for your innovation. Just because you feel challenged to display 3-D graphics on a cellphone doesn't mean you should run out and do it on the client's dime.
So Where Do We Go From Here?
The only antidote at this point seems to be experience. As mistakes are made, people learn, and they hopefully are not made again. Hire experienced sales staff, work for experienced managers, and experienced clients. This will minimize the madness. Beyond that, educating your sales staff, your bosses, and your clients when they're in need of education is the next step. Unfortunately, most programmers, me included, are not the most socially adept people, so trying to transmit that knowledge upwards is painful and fraught with peril. We're also trying to explain something conceptual from one world, translating into a different world that doesn't have any good metaphors for what we're trying to describe. We often come off as condescending, frustrated, indifferent, or inept. That's where middle management has to come in, and help both sides meet. Middle management should have a grasp of not only the company objectives, and project objectives, but also the work that is involved in meeting those objectives. If management is ineffective, or unwilling to listen, we need to make a stand until we're heard, or, leave, and save ourselves the pain. If you are management, and you're not in touch with your developers, start now, and listen. We may not be the most effective communicators, but we know what we're talking about.
Talking specifics, I think it's beneficial that sales people meet, and spend time with the development staff. If sales people sit, and see what programmers do, the process of development, and the thought that goes into development, and how it's part math, part philosophy, and part linguistics, they have a better idea of what's involved. They won't suddenly make promises that the application will "work with Office 95 - 2003 Beta flawlessly". If they do, even after meeting with developers, they need to be reprimanded. I also think it's important to have a stable knowledgebase of what's been done and how long it takes to do things, so you can pass that information back up the chain. This includes code repositories, archives of completed project plans, bug databases, and functional plans for customer customizations that have already been implemented. But these are basic ideas, and I would hope most companies implement them already.
In the end, I'd look to other industries that have similar business models, and see how they handle these situations. How do architects handle clients that demand the unreasonable, and sales people who promise the unbuildable? How do homebuilders deal with clients that are vague and non-committal while maintaining a deadline? How does a plastic surgeon express to his clients that the nose or butt they want is just unattainable?
I hope this article helps to spark some debate and discussion. The more we communicate with each other, and the more we share with each other, the saner we will all be.
Thanks for your time.
About the author:
Maurice Reeves is a software developer for MortgageRamp and a writer. He's held over 27 jobs, including telemarketer, car salesman, security guard, restaurant manager, and bill collector. He lives in Pennsylvania with his wife, daughter, and 3 extremely stubborn, spoiled cats. |
|
