Dealing with bad/incomplete/unclear specifications? [duplicate]

Question

I'm working on a project where our dev team gets the specifications from the business part of the company. Both the business management and the IT management require estimates and deadline projections, as they should.

The good thing is that estimates are mostly made by the actual developers who get to do the required features. The bad thing is that the specifications are usually either too simple (it turns out you're left with a lot of question marks over your head because a lot of information seems to be missing) or too complex(up to the point that you can't even visualize where everything would "fit" in the app). More often than not, the business part of the specs are either incomplete or unaware of what can and can't be done (given the previously implemented business logic).

Dev team is given about a day per new spec to give an estimate and we do try to clear uncertainties, usually by meeting up with whoever did the spec. Most of the times it turns out that spec writers haven't really thought everything through, and it's usually only when we start designing and developing that we end up in trouble, as a lot of the spec seems to have holes.

How do you deal with this? Are you generous on estimates in advance?

Answer 1

If you're finding problems during the design stage, do you really have a problem?

Make sure those creating the specs don't feel like they have to do everything up front. They can't think of everything and neither can we. They also need to know that they can't just do an all-nighter on some spec document and then be done with the project. This practice also leads to them adding every little thing they can possibly think of because they 'may' need it and if they don't ask now, they'll ever get it. They have to be available to review, test and approve their requirements over and over again.

Don't try to design or build the whole app at once. Any project/app can be broken down into some sort of phases, parts, modules or whatever they want to call it. You don't have to be agile if that's not your thing. Start with the User Security piece and go from there.

Make time to sit down with these people and find out what they really want. I would love to have someone hand me specs that allowed me to create the entire project all at once, but what would I do for the next year and a half?

Answer 2

I use the Cone of Uncertainty ^{Say in a loud booming voice}

Basically you do the best estimate you can give the information you have.
But you also point out that given the vagueness in the specifications that there is a high uncertainty on these estimates (Point management at the site so they can read up on the principle).

As you progress towards the target and tighten the specifications you can update your estimate and tighten the uncertainty.

Answer 3

Yes, I'm generous on estimates. Don't forget Hofstadter's law

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. From Gödel, Escher, Bach: An Eternal Golden Braid.

Answer 4

The process you are describing is actually quite normal. The problem is that business types tend to think of things in terms of "the requirements phase", then "the design phase", etc. When a team is creating a product, you really need an iterative approach. A couple of ideas that I found work are:

• Define the major goals for the proposed changes/new app. These are business related goals like "reduce the cost of processing claims by 10%" or "share market research from our satellite offices so products better mach our client's needs". It helps to bring focus to open ended requirements on what the real needs are.
• Do your initial SWAG (Seriously Wild-A** Guess) for the bad requirements as they are written, but document what you assumed the implementation will be. This is feedback the business folks (and your client) need to improve and think about these things. They are relying on you for them.
• If you have a choice between a really long estimate and a really short one, always go long. It will likely shock whoever is asking you to do work, which is a good thing. It will force you two to discuss what they are really after.

Remember your first estimate can't be accurate. Base your estimates on reasonable interpretations of the requirements you get, and document your assumptions/interpretations. There will be more derived requirements because of the holes you discovered. This is normal.

Answer 5

Being generous on estimates may sound nice, but what problem does it solve? It won't make the spec better, it won't make the planning any easier. It is saying 'it can't be much worse then X', as opposed to saying 'it might be Y'. The truth is you don't know. Find out what you can.

If the business analysts need to involve developers sooner, tell them. A written report is not really the best method of communicating. If you can have a developer help with the initial requirements gathering, and a business analyst helping with the development and testing, your results will be better.

I've just read the Cone of Uncertainty; it's good stuff, but it's easy to get it wrong. Management may look at the first picture and say: 'ok, we have the business requirements, so your estimate should be with 50% accurate according to your cone. Tell me'. That won't help.

Car analogy: someone asks you how much a car costs, and gives you a paper with his requirements. The paper says it should weigh around 1200kg, have four wheels and at least two doors, but maybe four, should seat four people, and good headlights are real important. Color should be grey (but is black possible too?).

You can say $25K, and if it turns out later he wants a brand new Range Rover you are screwed. That does not make it any more correct, or any more useful to say it costs $100K. He may just need a used (sorry, pre-owned) Prius. If you don't get the time to find out which, you will never know.

Answer 6

Most of the times it turns out that spec writers haven't really thought everything through, and it's usually only when we start designing and developing that we end up in trouble, as a lot of the spec seems to have holes.

The use of most is incorrect.

It is not possible for spec writers to think everything through. Period. If they thought everything through, they'd know how many lines of code to write and which lines of code were correct.

Since the spec must be incorrect, there's not much you can do about that.

The end up in trouble is the problem.

Both the business management and the IT management require estimates and deadline projections, as they should.

Perhaps not. Overall estimates and deadlines aren't the most useful things.

Hence the development of Agile methods.

The point is this. All estimates based on specifications must have errors. They're only correct by luck. Half the time, the estimate is way under and half the time the estimate is way over. This is a logical consequence of attempting to predict the future with incomplete information.

Since it has to happen, you shouldn't end up in trouble when you're wrong. You have to be wrong. And you have to be consistently and randomly wrong. Otherwise you're fudging the numbers.

Answer 7

You should explain the management that with vague specifications there is low degree of confidence in the estimate. i.e. You estimate may vary by 30% or 40% or 50% or whatever you think. So if something is estimated to be 2 days that is actually a range from 2-3 days.
Then create a projects issue register (can be on a wiki or Jira etc). Create all your questions as issues and get the business to answer your question. As long as an issue remains unresolved the estimation remains uncertain. If possible get a business analyst to be conduit to facilitate this and make better requirements. Get your test team to review the specs as they have to create test cases against the specs. Often their involvement can lead to writing better specs. Report daily/weekly to management how many unresolved issues you have. The more that gets resolved the better your estimates will be. Always present metrics to management as figures make them think objectively and puts you on strong ground as well.
Also depending on the size of the project put 1-4 weeks for solution design phase where you thrash out the major issues (both requirements and technical). Have many workshops with business SMEs and try to understand them and in turn explain your views to come to conclusion. Only after the major use cases have been understood and your estimates reach about 80% confidence should you proceed to build stage.

Answer 8

Remember, every time the spec is changed to add new functionality or to clear up questions, then it is time to revisit the estimate. It's not so much that our orginal estimate is bad given what we were told but that we don't push back and say no we need this when more detail is made available. If I were a contractor building a house and I estimated the cost based on using a lamiante countertop and a month later the client wants a granite one, you can bet I'd be revisiting the cost estimate with him. We let our clients get away with shoddy requirements and then don't push back when it turns out there are many more things to do than originally envisioned.

Answer 9

Why would you accept a requirements specification that is incomplete, contains conflicting requirements, or is infeasible? I would recommend that your process include a way for you to evaluate the spec and send it back for corrections before you accept it and give any estimates.

Answer 10

Convince the management/customer that it is worth investing in better specifications. Try to get people with domain knowledge more involved. In the end everyone will profit from it.

Answer 11

Eliminate the specs.

Convince business to try out Agile (or at least an Agile-ish process) for a project.

Instead writing out specs

• meet with the business people to identify features
• work with them to identify the minimal set of features/functions that would be useful (even if only for an internal release)
• card up the work
• set a date for the work (the fewer features/work the easier it should be to accurately estimate a date).
• work with business to prioritize the work, make sure they have the ability to change their minds about the card order, tell them how it affects the date
• with every completed feature have working system to show them, and have them sign off on each piece of work as it is done
• release
• rinse
• repeat

Showing features as they get done. Release early and often. Be transparent and responsive. I have found this will lead to the elimination of pointless deadlines.

Edit for architecture

Whomever is the lead should have a kick off meeting to communicate to the devs what the architecture should be. The lead is also really the person that should due dilligence to make sure all the needs are being met.

If you need additional steps in your process than add them in. A process is there to facilitate the team ability to get work done. If something about isn't working change it. Add to it, remove from it, change it to meet your needs. If you need to be especially concerned about security add in steps for it.

Answer 12

Communication usually helps, at least in a healthy organisation.

This is no silver bullet, but what I tried to do (and it worked at our company) is convince business people to explain the problem, rather than suggest a solution straight away. So our feature requests start with a description of the problem or the goal they want to achieve.

Then a developer with some domain knowledge tries to flesh out a solution, while consulting with someone on the business side of things. Usually this process yields several alternative solutions, complete with estimates.

It's up to business at this point to choose one based on the cost and how complete a solution is. This is also how you might be able to sell this method to them, that here they have options, not just a number of mandays, take it or leave it. Of course, it also needs more resources on their side but if you are having problems with estimates and specifications, it's an investment well worth it.