Slashdot Mirror
Making Changes to an IT Business?
everythingeverything asks: "Recently the IT development company I work for has undergone many changes, mostly focused on the streamlining of the development teams. Three people have recently been laid off, and massive pressure is being exerted on myself and my colleagues to develop more efficiently and delivery bug-free code. This is great - very positive changes. However it's blatantly obvious to many of my workmates that the sales and accounts team are not meeting their end of the bargain. They consistently oversell our services, write incomplete and inaccurate project specifications, set deadlines and budgets without consulting a TA or a developer, and frequently give in to clients when they want to change the spec halfway through. Management have agreed that there are problems and we have given them detailed research and documented solutions, but nothing happens. How have other employees in similar organisations brought about an effective, non-hostile and mutually beneficial resolution to the problem?"
Perhaps the best model for an IT company is an old fashioned one -- Start small, don't spend money you don't have, and try to keep your customers happy. If you try to go at breakneck development speeds on a skeleton crew, you wind up overextending the company, becoming unstable, and then falling apart after a few bad quarters.
Slow and low -- that is the tempo.
Got Rhinos?
The only reason they get away with this is the the uppermanagement has let this happen. Your boss should be standing up for you, your projects, and your teams outlook. If you have problems with the salesmen the way you say, you should get them all in a room with everyone involved and figure out who is saying "you guys do this". Why on earth would uppermanagement want to saddle down the salemen, when they sell something and you guys are on salary? If you don't get overtime and someone is making unrealistic goals for you who cares. Not uppermanagement, they are all for the slave labor bit. Sounds to me your in a job that is taking advantage of you, get a backbone, get gone, or bring it to boil. People use people because they don't say anything or standup for themselves. Your scared you might be over payed, or would have trouble finding a job if you got fired. Figure out which it is, face it, and move on.
I say this as a spinless jellyfish that is in the same boat. I recently got a backbone, had it snapped and handed back to me.
Neck_of_the_Woods
#/usr/local/surf/glassy/overhead
>and frequently give in to clients when they
want to change the spec halfway through.
If they are smart they have a clause in the contract for a "change order"
and bill for it.
When I was freelancer , a poorly written spec and a change order clause
was like the client forcing you to take extra money.
Have you considered that "give in to clients when they want to change the spec halfway through" may be part of their sales tactic, and that major changes is already in the budget for the project?
In any case the best you can do personally is keep track of the resources spent implementing a project. This will enable the sales persons to better estimate how much a project should cost. It also enables you to provide much better estimates for future projects.
This will of course not help right now, and it could be a bit delicate to point out that they have problems keeping the customers in line. Do you eat with them at lunchtime? If you do then drop a line like "uhhh... that new feature X in project X will take some time to implement"
If you were an AC asking this question I would have bet money you were someone I worked with.
I feel for ya, man. I really do.
Software Wars
How have other employees in similar organisations brought about an effective, non-hostile and mutually beneficial resolution to the problem?
In my experience, management fires the techies who speak up the most, leaving nothing but a week-knee'd devel department who cave in to the endless demands of the Marketing department.
See? No conflict!
OK, I took some flak for hiding. I admit it, I wrote the anonymous post about working down the hall...
Seriously, though, there are days when I feel like Dilbert.
What is your Slash Rating?
I'm guessing that your sales teams do not contain an engineer (I'm including IT guys in my definition of "Software Engineer). This may or may not be possible, depending on the size of your company, developments teams, and projects, but here's my suggestion: Always have an engineer at every meeting between your company and the client. Ideally, a project manager or head coder (Even better if those are the same person).
At my company, (granted, we're smaller than you appear to be...), our engineers deal with their engineers. No salespeople to get in the way, and it works very well.
Get out the old Resume, and start perusing the classifieds.
We've gone through a similar transition but things are now getting better.
.com bust, and probably thought they could hide in the glut without any technical knowledge -- not anymore.
The only thing that really works is to cut the problem off at the the root. Get rid of the preppy Ivy-league MBAs who don't know anything about building real software. A lot them are probably hold overs from the
Replace them with seasoned sales/marketing folks who've been burned by over promising before. Best situation is to get some former engineers into the business side who are willing to push back against the unrealistic.
The market ought to be full of good people these days, the trick is to have some software experts on the interview panel, rather than accepting blind recommendations from someone's rich parents' friend (unless you're interviewing prospective US Presidents, rich parents are apparently enough).
Don't blame me, I get all my opinions from my Ouija board.
That's an organizational misstep. The sales team should NOT be writing spec. The sales team should NOT be estimating hours. The management, having realized the problem, have the responsibility to restrict the authority of the sales department.
'course, in our company, the project managers are highly involved with sales, and it's worked well. I don't think we have a full time salesman that isn't our CEO.
i actually really liked the consultant... probably because he ended up telling the owners what I'd been telling them for months (the obvious problems mentioned above). everyone was pretty pumped up for a change.
three days later we were all called to a meeting where it was explained to us that "now that all our past problems have been solved...". i was baffled... we hadn't actually implemented anything the consultant had proposed, we merely talked about it. i stood up and said "I don't understand. What have we done to fix the stuff we've been talking about?" to which I got stares and bewilderment. Everyone was thinking the same thing (several folks told me afterwards), but I was the only one with the balls to actually say it.
I was fired within a week for my "attitude problem".
my point is -- real change is hard; 90% of folks would rather just talk about hard stuff than actually do it to improve their situation. don't settle for any Mickey Mouse shit. good luck! :)
You have to speak the language.
Do up a nice presentation that includes specific examples. Have good ones, bad ones, and ones that were changed mid-stream.
Talk to the accounting interns, buy them drinks, and they will probaby give you some detailed cost figures taken at end of project.
You need more than, "we all cost x$/hr, we spent yhrs on project and we go z$ for the contract."
is to outsource your sales team.
I should have picked out the nickname Demosthenes!Tecumseh.
A percentage of the cost overruns for a given project comes back out of the commission. :)
This will be perceived as hostile by the sales team but upper management should be fine with it provided you guys keep good documentation.
The flip side is that if you do sign off on something and slip up the sales team will be all over your ass.
After a few months or a year the good sales people will have straightened themselves up and the dead wood will have left voluntarily.
Good luck!
P.S. This is generally easier to implement if you guys have some skin in the game too... Work out a per-project percentage-of-profit (or gross, profit figures are easy to manipulate) for you as well.
Here is how it works in the REAL world...
SALES drives the company, you can't change that, get over it. Execution is everything, and we (IT) wind up with our asses cashing sales' checks... thats just the way it works in this fast paced industry.
You have to find a balance and a system, if they are cutting back on people then you will have a tough time, but for developers you ABSLOUTLY MUST have 1 dedicated person for QA. I have tried and seen developers "test" their own code....we try, but we subconciously can't catch the easy stuff.
Here is how it breaks down:
Developer is hired by the company.
Developer maintains legacy code left by previous employee.
Developer gets ancy and an opportunity to perform new development.
The new project is released.
Developer has to maintain "his" project for sales while performing other duties to bring in money and gets burned out.
Developer finds another company, and the whole cycle starts over again for both parties.
I once had a salesman at my old Wells Fargo job, tell me that there was going to be a change in the way I did my processing. I told him it wasn't possible due to time restraints and the fact that I had no plan to put a cot in my vault. He said I had to. I asked why the sudden change and why the boss let him promiss. The best answer he could come up with was that it was what the customer wanted. He also hadn't told management yet. I told him he could shove his bonus up his ass the next time he decided he was going to sell me down the river. It's been four years. They still haven't done it. I've been gone for three. :P
Someone hates these cans.
First, tell them it can't be done with current technology, but start working on it immediatly.
Multiply all work estimates by a factor of 4, then tell them it's 'iffy'.
Ignore their spec, write your own as generic as possible. When they change it 1/2 way through, you bitch and moan, then write the gui that will give them what they want.
Yes, those first few conversations the sales people have with your clients are part of the design stage. What it took in our company was a discussion with upper management of past failures, with specific examples, cost, etc of where this stuff bit you guys on the ass. Take time to make your case water-tight...and don't focus on INDIVIDUALS that hurt the business process. Focus on where the business process hurt the team.
You've already got 1/2 the answer there yourself. You've got a good idea of the things that typically go wrong. Now, what can you do to make them typically go right? Of course, there are ALWAYS going to be cases where the client is just a "bad client". You may be making profit on those clients in your books...but it may be "bad profit". Consider not doing work with them again if you (collectively) have made every effort to reign them in. And *always always always* have "post-mortem" team discussions at the close of *ALL* projects to discuss successes, failures, and areas of mediocrity. Again, don't focus on the individuals that failed, if at all possible...focus on the process that failed.
And finally, you think upper management only cares about $$$'s? You're right. So put it into terms they can understand. While they probably aren't as technically adept as you would want, they're also probably not TOTALLY clueless. If you can show, on their terms, where your business process needs help, you've crossed the first hurdle. Show them specifically how much money they lost in cases where salespeople oversold, or were unable to filter unreasonable changes mid-way through the development process. Just don't start such a conversation without also having some ideas on how to fix things.
There's been a lot of good advice, but all of it assumes that the sales people will try and change which happens sometimes, but sometimes doesn't.
When things get busy where I work (2 developers) and they come in and ask for more or changes or this or that or the other thing we tell them how long it will take and point to a board with a list of all the other things they said they wanted and make them decide where to put it.
This makes them realize that this new request of theirs is going to push out someone else's request (or even one of their own).
There must be a balance of power between those who order the work and those who do it.
The best balance of power setup I've seen is part of Extreme Programming. In XP, the suits can ask for whatever they want, and they can change their mind every week. The developers get the final say on estimates, and the suits can only order as much work for the next week as was done last week. The developers deliver a new version every week, so everybody can see exactly how the project is going.
This sounds too simple, but it works really well. Every week, the businessfolk are forced to balance their desires with the reality of the development situation. With only a week between data points, nothing can get too far out of whack.
Of course, some bosses are just unwilling to face the fact that for X dollars, they can only get Y features; they will refuse to implement any system that makes that clear. But most people just want to get good software, so they will come around if you put it to them properly.
I've had a single experience like this... sales was making promises, and then coming back to engineering and saying "is this possible? Whew! Cause it has to be done by X".
The VP of sales (co-owner) and the vp of engineering (not a co-owner) almost came to blows.
Adobe eventually bought us out and said VP was gone in a remarkably short amount of time.
No one missed him much.
Thats more a war-story than advice... advice... hmmm.
Try to get the sales guys and eng in a boxing match? Heh.
Seriously though. We actually managed to get the prez (the other owner) to read Rapid Development by Steve McConnell (though there are several books that cover similar territory, I personally swear by anything McConnell writes). Half the 'bad examples' in that book should sound Very Familiar to you and yours.
The problem has been identified. RD contains numerous suggestions on how to make fixes. Then it's "just" a matter of putting those processes into place.
Heh.
Fooz Meister
That's never stopped the Software and Entertainment industries.
They've been laying off people left and right these days. It's not surprising, as their products have gone seriously downhill in the past few years, as evidenced by the multiple Slashdot articles on them recently, among real reasons. You'd think with the tough times these days they'd try to ramp up their products and make themselves look as appealing as possible, but oh well.
Don't expect to be able to do as you please instead of following guidelines from salesmen, not because it's not logic, but because that's what managers are teached in MBA courses. The salesmen should listen to the clients, the production people should listen to the salesmen, and management should provide enough resources to both.
Learn from the lawyers. In recent articles about patents, somebody said something like: "despite their aparent lack of technical knowledge about the matter, they came up with a EXTREMELY DETAILED list of QUESTIONS, so detailed they surprised us, and answering that gave us more insight about what we were doing."
It's the same about software. If you have to do medical software, for example, and don't understand some part of the process, make a EXTREMELY DETAILED list of QUESTIONS, and this way you are sure that management knows that you're listening the salesmen, and therefore, the consumers.
If after that the salesmen keep doing falses promises, it's their fault, not yours. But remember that people (AND SALESMEN!) normally don't know how computers really work, and their expectations may differ greatly from yours. (Think about so much movies with robots).
We are Turing O-Machines. The Oracle is out there.
Is common practice in 99% of companies. if you see any real change, they'll be eliminated when another company buys you out or some other factor dictates a change.
There are five things that you need to do: make each day full and productive; come to work fifteen minutes early each day; keep good metrics; email your boss detailing your current progress (at least twice per week); work over time one week each month (this means five or six ten hour days in one work week). When the project is not complete and "heads begin to roll", explain the real problem. After you explain the problem, expect to be attacked, but be ready with a log that details your important emails, hours worked, and metrics.
I think that it is obvious why you should do these things on any job, so I will not go into the whys on each item except the overtime. The problem with giving a company too much overtime each month is that it hurts your family, and managers do not respect you for your work. If you limit your overtime to one week per month, and not work more than ten hour days (specificly an hour early, and an hour late), your family will not be disrupted.
It is necessary to train the sales force as to what is actually achiveable - this can be difficult. You are helped greatly by the simple fact that if the product is not on time, or stable, the salesperson looks bad too.
The single hardest thing to do is to find out what the customer really *needs*. To define it correctly, both you and the salesperson have to meet with the customer. This can be a three step:
1) Decide with the sales person what is the information that is needed from the customer meeting. The customer will have a whole bunch of wants, but he will not articulate his needs at all well. You will have to coax it out of him. The summary of this premeeting will be a table - features -> benefits to the customer -> costs. While you are with the salesperson, ask him what he feels will be the next step in increasing his business in the account. This is an unusual question from a techie, and should score you business points which you can negotiate with, later.
2)The customer meeting, itself. Have a presentation as to what areas are do-able, and a relative idea of the costs ( especially elapsed time). If possible, try to block the project up into smaller deliverables, so that there is continued involvement with the customer. At this point you are negotiating what gets built, when. Add feedback loops and kill points so that the risky items are clearly marked out. Don't ever commit to calendar time at this point - the analysis is not done, yet. Formally, this is scoping the project, and is an important part of success in project management.
3) Post meeting: document early and often, and now let the salesperson earn his keep by keeping close to the customer. The salesperson is your interrupt mask - make sure that he is the point man for the effort. Appreciate him, preferably in front of his boss. Sales is a people job.
Most of the grief I have been witness to has been squarly the problem of poor project manangement, unstructured, unprepared meetings, and general cluelessness. You can mitigate cluelessness, and the other things are either under your control, or can be influenced by encouraging the right questions to be asked, or asking them yourself.Hope this helps. It's my personal opinion that the developers should not live in a cave, but should rub elbows with the outside world, from time to time. Large organizations have special people to act as technical bridges, but in a small company, you get to do this yourself...I like small companies for that reason.
This is progress?
whatever you do, make it without Microsoft!
I have been in the same type of position before and without the senior management stepping up to the plate and doing their damn job you are screwed. We had sales people who would overpromise anything and everything without ever so much as a simple email or phone call to someone in IT who would have readily told them that it was not going to happen, period. Complaints to management went nowhere. Even on the not so rare occasion that some dolt in sales who was incredibly unable or willing to consult a dead simple price chart quoted the client a price reflecting maybe 10% of the actual cost, we were screwed by management and told to just do it for whatever was quoted! I quit after many attempts to fix things. No one cared. To them, a happy client (who was of course happy because they were paying 10% of actual cost) was the only thing that mattered. Deals with clients suck. Do them one favor and they expect the same price forever, there is no going back on a botched deal. Good luck...but I would say my piece and get out of there if I were you unless you think management may actually resolve the problem.