What to do if boss always postpones major decisions about requirements and overall design?

Question

When starting a new project, my boss always avoids to make fixed decisions. He is usually saying: ok, just start to write something and be as generic as possible. When you're finished we look how we continue. His argument is basically that you never know and "agile development".

To keep the question as generic as possible: what do you do if your boss doesn't like to make decisions?

Just stick to it and write code that might undergo heavy refactoring and partial rewriting a few weeks later? Or keep on discussing until the boss does at least a few decisions? This is more or less my current strategy. Because it's like a law of physics, at some point something needs to be delivered. Either because the boss' boss wants to see results or because stuff is becoming ridiculous at some point.

I also observe that my boss is criticizing nearly everything. Even suggestions that are based on his own...

Answer 1

Build prototypes

Just start drawing screens that don't do anything at first (presumably you have enough to do that?)

You should be able to make it partially functional slowly, and eventually refactor some of the bad code when it becomes more clear what you are trying to do.

It's a common problem that they don't know what they want until they see something and realize that's not what they want. I've found that when someone wants you to just start building 'a framework' or something 'generic' like what he is telling you, you are just going to get in trouble if you try. The frameworks are already written, you don't need to do that.

Answer 2

There are several issues that I have gathered from your message: 0-It is not your job to manage the project and it is not your job to gather end-user requirements. 1-The boss does not know the exact requirements 2-The boss does not to talk to end-users about the requirements 3-The boss is throwing terminology he does not really understand agile 4-You are working out some solution that gets re-written several times and you are not happy about it

As for 1,2 and 3 there is little can be done about this if you are not a senior person. However, the following can be done:

A - Ask him to share with you the project plan. He may have one or will build one showing the tasks and deadlines. One of these should be about analysis and requirements gathering. If not suggest it.

B - Prepare some references on the importance of requirements to the success of software project

C - Prepare him a 1 page of what Agile is and is not.

D - Prepare him a list of typical inputs to the design stage and convince him of the value of each.

E - Suggest the addition of a business analyst and/or data modeler to the team. Such roles will have to sit with the end-user and will get you the information required or at least good part of it.

F - See how other developers cooped with this guy.

As for #4, you can suggest to him to use a prototyping approach or a code generator that would help him, you and the user to make their mind about the functional aspects of the application. Most tools don't generate perfect GUI, but at least you could capture the functionality required.

In all cases, make sure that you document each of the iterations clearly and send him an email about what input you have received, what you did (in some detail) and what the outcome is. Make sure you attribute the outcomes to the proper cause such as (lack of requirements, etc.).

Unfortunately some people don't accept advice. So be careful how you communicate with him.

This is not going well!

Good luck.

Answer 3

I used to have a boss like that - in fact I would joke that his motto was "indecision is the key to flexibility".

Whatever development work you do, you're probably in a better position to solve the client's problem than your boss. If you don't know what the problem is the client is trying to solve (which is not the same thing as a spec), then someone is not doing their requirements gathering properly.

Sketch some page layouts, or build a non/semi-functional prototype. But do something. It's not clear from your post whether you're building full-client software or web-apps, but the beauty of the latter is you can release-early, release-often. Start with the bare-bones and work it up from there. A false start does no harm if it gets some dialogue flowing and some decisions made.

We have a saying around $WORK (internal web-apps) for our clients: "I'll give you something so you can tell me what you want." Be prepared to throw the first draft away, but you might be surprised how rarely you actually have to.

Answer 4

Point out to him that the Agile books suggest postponing decisions as long as you can but no more than that. Every decision has a point where it has to be made, and maybe you're there right now.

On the other hand, also question yourself. Do you really need to decide what persistence layer you're going to use for this app? Or can you start off writing it to a CSV and keep it abstracted enough to make that decision later?

Answer 5

Write your own spec document and hold a review where you explain it and he signs off on it. Then you will become boss, and your boss will move into more interpersonal management issues rather than technical issues.

Answer 6

Engage in 'upward management' talk to your boss and clients, figure out some solutions, pick the best one for your team to implement, find flaws in the other ones, and 'manage' your manager into making the 'right' decision.

And of course make sure he thinks it was all his/her idea. (especially when it all goes wrong!)

Answer 7

You need to design and implement something. Since your boss won't make decisions then make them yourself. Take a little extra time to document your decisions and assumptions before you implement them. Send it to whoever it may concern including your boss. Hopefully, that list includes more than your boss as it will put a little pressure on him to make some decisions since he knows that others are aware that you are ready to proceed. You will be surprised at how quickly you get feedback when you put decisions in writing, especially if you make decisions that other people disagree with. In the meantime, I would proceed with the decisions you made until told otherwise.

If you ended wasting time implementing what your boss didn't want, then it is on him and not you since he was aware of the path you were going to take.

Also, some people have a difficult time getting started, but once they see something tangible then their mind kicks in. Maybe your boss is like that and your telling him what you plan on doing in writing will get his mind going.

Answer 8

Make decisions yourself and start coding. Of course, developing in a flexible way will help (read Robert C Martin's Agile Patterns, Principles and Practices if you haven't already) but all the flexibility in the world won't help if no decisions are ever made. You may find you have to just develop what you think is needed, and then modifying it as required. Often clients/bosses don't know what they want until they see it, or until they see something they don't want. This will probably take you outside the scope of being a developer, but that's life. I often find that I and my colleagues are effectively making business descisions. Sometimes these aren't questioned, and decisions I've made start driving the business, purely because no one else would make the decsision. Be sure to list ALL of you assumptions and decisions (no exceptions) and present these to your boss.