Apps

Ignored Internal IT

11 comments
Mark Miller
Mark Miller

I agree with you about estimates. It's something I've struggled with for years, and most of what I've worked on would be classified as internal IT--not customer facing. It's what I've specialized in. Fortunately the places where I've worked have basically given me the time I need to do these projects right. It hasn't been perfect, but it's been better than what I hear you describe. The best situation I've found for estimating a project is when I'm working on something that's already been started by somebody else. I can look at the code that's already there, and I can get a clearer sense of how long it would take to add to and change the existing code. If I'm just starting from scratch it's real hard. I'd really prefer to start on a project for a little bit, start working on all the different parts, see how it's going, and then give an estimate. One of the first jobs I had out of college allowed me to do this. This is how people who repair electronics do it. They start to repair what's damaged, and they look at how long it took them. From that they can estimate how long it would take them to finish the repair. The difference with them is they're usually mostly done with the repair by the time they give you the estimate. If you turn them down, they just restore it to its broken state, and give it back to you. They even charge a "bench fee" for this. I don't imagine that would work well in software development. But if you ask me this represents a good model of the ideal way to do it. Asking for an estimate before I've written a line of code, or had any existing code to review, makes no sense to me at this point in my career. I've had the opportunity to meet a couple people: a project manager, and a senior engineer who seemed to know what they were doing, who practically had project estimation down to a science. For them it was all about probabilities. One used a method of calculation that was based entirely on past experience and mistakes, but he did well with it. In other words, it took being introspective enough to find all of the "known unknowns" (to quote Donald Rumsfeld) and a good sense of how uncertain you were about how big each problem was to get it right. Another used what was called a "Monte Carlo" simulation to do it, and it seemed to not depend on past data (experience) as input. He used a piece of software called "Magic 8-Ball", or something. I looked it up and got sticker shock. It was several hundred dollars. Again, it was based on probability. I heard of the "Monte Carlo" method in college almost 17 years ago, but I couldn't reproduce it if you asked me. No place I've worked has used it. He was the first one I had met who did. What's sad about estimates in software projects is you're really the best one to be doing it. If it wasn't you, some salesperson would be establishing the estimate. I've seen that too, and believe me, you do NOT want to be in that situation. Horrors!

Justin James
Justin James

Mark - You are absolutely right about how much easier it is to give an accurate estimate once the work has started. My experience has been that the first 20% or so of the project is almost always where the "gotcha" is going to occur (the library you were counting on does not work as advertised, the data is horribly wrong or in a goofy format, the customer changes their specs fifty three times, etc.). It is a shame that all too often, we are asked to give an estimate before any work starts, instead of having a "go/no go" point, or making decisions based on how quickly milestones are acheived. And you are also sadly right in that failure to provide an estimate nearly always results in a sales person doing it for you. Gotta love the sales guys! J.Ja

Mark Miller
Mark Miller

[i]the customer changes their specs fifty three times, etc.[/i] The customer changing their mind is always to be expected, particularly on the large projects that last months, for large companies. In my last job where all I worked on were short-term projects by myself, the customers I worked with changed their minds surprisingly little. I was able to go to meetings, discuss the requirements and be able to count on that being enough. I never had an instance where I got an e-mail saying, "You know that thing I asked you to do? Forget about it." That was one constant I could count on, at least. I guess the difference was the projects were small in scale and the requirements were fairly simple. What bugged me was when customers on the larger projects (when I was working for a different company) asked for estimates that were months out, changed their minds somewhere in the middle of the development process, and then expected the software to be delivered on the schedule of the original up-front estimate. Maybe I've learned to anticipate this by now. The key is to pad the estimate generously for yourself. Don't think of estimating as an exercise in trying to get it just right. Think of how long things will take you and then double it, at least, if not more. Give yourself some breathing room, and learn to put your foot down and not settle for less. When I first started giving up-front estimates early in my career I sweated bullets, because I wanted to get it just right. I came from a modest upbringing, which was cost-conscious. I was taught to sweat the small stuff when it came to money. I was the same way with projects. And I tended to get it wrong, except for the short projects. I used to hate the idea of overcharging a client. I eventually learned to change my mindset on that, because I saw that no matter how careful I tried to be, I usually ended up with the short end of the stick. It was better to overestimate by quite a bit, risk overcharging the client, in order to have a chance of coming out ahead of the game. What I used to do (naively) was estimate the amount of time I figured it would take to modify the code, assuming everything went well. I didn't include time for administrative duties like setting up the database properly, testing, delivery, or changing requirements. Nor did I include time for meetings. That last one used to get me all the time, mostly because our team manager never told us how many we were going to have during the course of the project, nor how long each would take. It took banging my head against the wall several times (and changing companies) before I wised up some. In the last couple jobs I've had, I've taken my time (when I can) on estimates. Sometimes I spend several hours coming up with them. I make my worst estimates under time pressure. The more input you take in, yourself, during the process, the better the estimate you will make. The better companies to work for will allow you the time to make a good estimate. A job I had several years ago even had me record the amount of time I spent on making estimates. There was no pressure to make this time short.

rvasconi
rvasconi

No matter how good where your estimates (things will change) , no matter how in advance you warning your project leader about the changes in basic assumptions you consider in your estimation (things already changed. If he does not support your position, and does not be able to open up these matters and negotiate with the final client, we are doom! We need more awareness about these matters in marketing and management levels and contracts with clients that assumes this issues.

VDOPanterA
VDOPanterA

I agree, quoting a started project is definitely the way to go. However in our team, we aim to overestimate on quotes to be safe. That way even if we finished it early, it sends a good impression to the client...

Justin James
Justin James

Mark - I agree, no amount of financial incentives can make up for working 12 hours days for three weeks straight. There is a certain point where the idea of being a salaried employee just feels like being taken advantage of. I do find it rather interesting that special exceptions to overtime are made for IT workers, a group of people who are notorious for working extra hours "when the chips are down" and even as a standard part of their job (server upgrades, network infrastructure changes, deployment of new apps, etc.). Another thing that I find distressing is the idea of comp time. If you worked enough hours to build up a sizable amount of comp time, when would you take the time off, since you are obviously so busy? I have never met a sales person who did not get a bonus or a comission based on individual or group performance. There are whole books justifying this, too. IC (incentive compensation), at least in the pharmeceutical industry, is absurd. I watched one company give out bonuses (under $100, but still a bonus) to employees who scored 0 points on their review; 0 points meant that they had the worst possible ranking for every single item. So they were givinng bonuses to people who should have been fired. Meanwhile, I have had 2 bonuses in my life... once at 4.5% of the year's pay (which was pretty good for an hourly help desk worker who did a lot of OT), and the other at a mere 2% of salary, which was really bad as an IT worker. While I like the money, no bonus is less uinsulting than a minute bonus. J.Ja

Mark Miller
Mark Miller

I don't know if the salespeople at where I worked got a commission. I suspect they did. I generally agree with what you say, but in my experience it was no better when they passed on some of the bonus to the line workers. In the company I described in my previous post they eventually implemented a profit sharing plan. And so some of the windfall came to us. I tell ya it didn't make me feel any better. It's possible the reason was that they didn't adequately communicate why we were getting the windfall and giving credit where it was due. That may have helped, but that assumes that management was competent... All I remember is at one meeting I heard about the profit sharing plan, and every once in a while my manager would come up to me and give me an extra profit sharing check. I was so busy and demoralized I said a quick "thanks", stuffed it in my bag and got back to work, not giving it a second thought. Things felt so stressed and disorganized that I didn't care. I would've traded the bonuses for a more reasonable schedule in a heartbeat. What I cared about was working with a good team and satisfying the customer. As long as I got paid a fair amount for that, commensurate with what others in my group were making for the same effort, then I was fine. I got kind of wedded to the company psychologically, because when I first started there, I worked with a good team and a good manager. There were still screw ups. The difference was my manager handled them better, effectively directing our talents and complimenting our work. He was open to hearing suggestions about how to improve things, and he encouraged us to learn about new technologies and ways of doing things. I felt like I was a part of helping improve the company and making it grow, with no profit sharing at all. I measured this by how much our process was improved. My manager eventually left his position and the guy the president replaced him with was incompetent. Within months of the switch profit sharing was added. It didn't matter. It felt like everything I had worked for was being thrown away and a mess was blithly being brought in its place. It was heart-wrenching to watch. After a year of that I felt like I didn't want any part of it, and I left. I imagine in your case the non-egalitarian profit-sharing just rubs it in more.

Justin James
Justin James

"I think the best IT software companies understand their limits and don't try to push things to unreasonable levels in the hopes of pulling a rabbit out of the hat and making a profit." I think the worst companies provide incentives/bonuses to managers who meet nearly impossible targets without trickling down to the line workers. This is something that I see over and over and over again. Eventually, the line workers start asking (with good reason), "why should I bust my rear, come in nights and weekends to meet a target that I did not set and that I said I could not meet up front, just so my boss can get a bonus and he goes home on time every night?" I see this a lot, and it is frustrating. Folks talk about how they have the right to keep the fruits of their labor; I agree with this, which is why I find the who incentive system upside down. To financially reward those who oversee while not rewarding those who are overseen makes no sense, and hurt morale while building resentments, all at the same time. J.Ja

Mark Miller
Mark Miller

One of the first companies I worked for always tried to underbid the competition. This was the place where I saw the salespeople making estimates sometimes. That's part of what started making the job hell. Yes, the clients went with us because we promised them the moon, but as some of us discovered that leads to diminishing returns. There comes a point when you just can't do it for less. The project manager I was telling you about who had estimation down to a science said at a presentation I was at that he stuck to his estimates no matter what. If the client said they found someone who could do it for less, he said "fine", and let them go with the competitor. He's a smart guy. The trouble low-balling competitors run into is so many projects are fixed bid. This means they consistently don't make much profit, if not suffer losses as a result of their zeal to "get every client", because the contract always expects certain deliverables, and they have to deliver them or risk getting sued. It's always possible that a competitor is using a better development technology, and they really can do it for less, but I doubt that's the case in most situations, since most customers (in my experience anyway) are already wedded to certain technologies and platforms that limits the techology choices that competitors can make. For example, if they have a system you have to interoperate with that's written in Java, it's more than likely they'll want any company they contract with to write their piece in Java as well. It's also possible that some competitors have specialized in certain solutions, and they already have a lot of the infrastructure in place to solve the problem the customer has. In that case they can outbid companies that are "generalists" for the problem they're targeting. I think the best IT software companies understand their limits and don't try to push things to unreasonable levels in the hopes of pulling a rabbit out of the hat and making a profit.

Justin James
Justin James

... until someone (internal or client) tells you, "well, so and so bid on this too, and they said that they can do it quicker," at which point you know that they are going to go with the other vendor who then goes over the estimate. :) J.Ja

Mark Miller
Mark Miller

"You can either have it on time, or it can work" applies to commercial software as well. People complain about the ever present delays in commercial software, about companies like Microsoft and Oracle slipping their promised release dates. They and their customers are dealing with the same issue.

Editor's Picks