I work in a small web development company (3 programmers) for a while. During the last year the company had hard times (less projects) and a few co-workers were fired, including our Production Manager. Having this person out of our team mean to us that we have to deal more and more with the company bosses (owners). It's them who meet the clients and discuss about upcoming projects (custom web app for example)

We had a meeting with the boss this week about a particular project for which he wants the specs to change (add a few features). I understand that in the real world specs always change during a project (I'm in this business for almost 10 years, I already figured that). What I am having hard time with is when the boss keeps trying to minimize the complexity, the impacts of the new specs because in his mind those changes are not that hard and should not take a lot more time (especially because he already signed a contract with our client for a fixed amount of money). With one programmer co-worker we joked about that, saying that it's not by adding two wings on a car that you will make plane, it has major impact on the whole design of the vehicle, time required is not the same, so is the same with software.

Any idea how we should handle that kind of attitude from a boss? Is it possible to make him change his minding in that kind of situation ?

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – psr, Snowman, Yannis

It's called "Shit's Easy Syndrome," and every boss who's never had to actually build anything has it. The only cure that I know of is to point them to this Steve Yegge article.
–
Robert HarveyApr 17 '13 at 17:42

5 Answers
5

While all of the feedback so far is good it is all recommending methods to change your bosses approach and trust me this is a futile effort that will ultimately result in you getting more and more frustrated.

Your boss, like mine and many others has a broader view of the company than us mere developers. They are concerned with customer satisfaction, repeat business and the word of mouth and reputation that comes from delivering what the customer wants even if it is out of scope.

Now I understand that for large development houses that take on government projects worth millions of dollars it is really important to get all the scope and details nailed down from the outset to ensure the overall success of the project. I do not think you work for such a company.

You mentioned that you recently lost your production manager, buddy... it's time for you to adapt and step up to the plate here. Your company is under some financial strain obviously and at least you still have a job here. I'm sure your boss is shitting his pants on a daily basis doing everything he can to keep you going ( including taking the last resort of firing people )

So to sum up, I think you should work differently and adapt to the new situation.. adopt a more Agile development style and put the customers needs first.

There is something fun about flying by the seat of your pants. You only need to be direct with your boss and tell him what you said here. Most of all understand he is human so be a little compassionate and explain that with the loss of your PM some of the processes that were once in place have come unstuck.. But at the same time explain you understand the pressures he is under and if he can accept that the developers are going to have to wing it for a while and make mistakes then that's all you need to say - he can never come back and say you didn't warn him at the very least.

There's likely nothing you can do now for this project. However, if you have the ability to track your time against both the original features and against the changes separately, do so. Once the project is over, do a retrospective.

Did you come in early and under budget? If so, your estimations are off and your boss is right. If you came in over budget / late, see if the amount of overages equates to the time spent on the new changes.

If you start doing this for all your projects, eventually you should see a trend. Likely, that the more features that are added after the original estimate, the later the projects are.

Don't do this to prove you're right and your boss is wrong. The goal isn't to prove that somebody is wrong, the goal is to learn how work together to make better estimates. If the projects are often late and changes are often made after the initial estimation, you'll have the information you need to make some changes in how you work.

Give him detailed time estimates with exactly the tasks you have to do to make the change. Do the time estimates in excrutiating detail. Make sure you include things like communication (emails and meetings), unit testing, QA, deployment, documentation, research and design not just development (and make sure you put in lots of steps inteh devlopement part). The only way to educate him is to show him the detailed impact. In our company all spec changes are changes to the estimate and all of them are sent to the client so they know the impact of the change on the deadline and the amount of money it will cost them. Now that they understand that changes aren't free, we have far fewer changes.

I would suggest you create a time estimate template to use for the future.

If this doesn't make him start to understand the impact, then he never will and it is time to move on before you are in a series of death marches that take up all your personal time to meet his unrealistic deadlines.

They will just make a step to the ceiling if we were to provide that much detailed estimates. They are used to small to medium project with low costs. We do not have projects development lifecycle like you just explained (unit tests, docs, QA what's that ? ... irony). If we give too high estimates (as we already have), we get a speech in which they say they can't sell that expensive projects, clients will refuse and we will go out of business because we have no more projects. Very hard to handle.
–
MaxiWheatApr 17 '13 at 18:35

This happens where I work too -- the client will keep requesting little changes that end up causing us to go over schedule/budget. (I'm going to call this phenomenon "requirements creep" since it seems like it might be a cause of/related to feature creep in software).

Something we did on a recent project that I think might help combat requirements creep is that the higher-ups decided to go with a phased approach by offering a core set of functionality at the end of phase 1 then planning to meet extra requirements as part of a phase 2. Doing things this way would hopefully allow you to deliver a quality phase 1 product by the initial deadline at or under budget.

The second phase would of course have it's own deadline and payment, which your boss would probably like since it'd be more money. (Phase 3: profit!)

This might not be helpful if the phase 1 part takes longer than the initial deadline or if your boss doesn't realize there is a problem, but it's something you might suggest to him.

It's hard to work with boss who doesn’t understand our work. I had that kind of experience and It was the worst time in my live.

I think you should talk with your boss like a child(show him pros and cons of his decisions), you should explain him how it should works, maybe you can even buy him some book if he has sense of humor.

But to be honest many things depends on the agreement which your boss will sign with client. I know that sometimes complexity is minimized because company wants to win contract and after that they talk with client again and complexity is increasing and then company earn more. The second case when complexity is minimized is when company knows that client will give us more task in the future - it's like throwing bait.
And the worst explanation of that behavior is inappropriate person.