It is never possible to put together requirements that are 100% complete, correct, verifiable, testable, consistent and clear? Never say never; just because you have not seen it done does not mean it is impossible.

…so, I don’t believe you will change your mind on this; if you are truly succeeding with your methods, then power to you, but that does not mean that others cannot succeed with a different approach, if they know what they are doing.

You don’t sound like someone who has ever had to deliver real working software to a customer, so this might sound a little radical. Requirements aren’t deliverables.

Try to put yourself in the shoes of a customer and think for a minute – what is it that they want? Do they want half a rain forest in the form of beautiful documents and images? Since you work in a consultancy, its likely that you are engaged on the basis that you deliver documentation – but that is not the goal! Someone, somewhere actually wants a piece of real software to help their business make money!

It is never possible to put together requirements that are 100% complete, correct, verifiable, testable, consistent and clear. If you stay behind on a project after you have delivered your documents and start talking and listening to developers, you will quickly realize that. What you have is a snapshot in time that does its level best to achieve all the things in your list, but you’re not accounting for the fact that things always change. Besides that, the inherent complexity of most projects means that mere mortals cannot forsee every little detail, this especially applies to customers who are far more concerned with the big picture. I am guessing that NASA is probably the one organization on earth that may have come close to 100% on any of those attributes, but they have the budget, most businesses don’t.

You cannot generalize on delivery cycles. Surely the answer here is – it depends. For some businesses it may be abolutely the right thing to do, but you cannot and should not try to adopt a one-size-fits-all philosphy.

Largely I agree with your statement about ROI and definition of requirements at the start of the project, but our thinking probably differs at the detail level. The best way to determine what will really happen is use an empirical, feedback driven approach, we can go into details another time.

Finally, I never said that architecture and design were value-less, they are a critical part of any project and all good developers recognize that.

Delivery cycles? Three months is optimal. Go longer and enough change will occur to cause “thats not what I need now”. Go shorter, and you will disrupt the business too often with implementations that interrupt actual business operation. Most business works on quarterly cycles, so should IT. Use of good artifacts does not mean long delivery cycles, too big a scope at one time does that.

Return on Investment? How can you estimate costs and benefits at the start of a project without sufficient definition of Requirements? As you proceed, is a good architecture and design also value-less?

Of course, the other place to take this conversation is that 75% or more of IT projects don’t produce new systems, they are maintenance and enhancements. And lots of the remaining 25% don’t deliver new software, they implement packages or services. All of these projects still need Requirements though, so we need to be able to create a quality deliverable every time.

I think you were right the first time On a project that is releasing real business value (working software) once a month then the BA would be engaged 100% of the time. Her time would be fully utilised gaining qualitative and quantitative feedback on past releases whilst defining the requirements for the next release.

For a project large enough to warrant a BA then this is a full time job. For smaller projects then the BA role could be one of many roles adopted by a single individual (a team lead perhaps). The point though is that the person doing the work should be fully engaged.

How else will they be able to give this important role the focus it deserves?

It would be nice if you could back up your claims by going back to your customers and have them quantify the value actually delivered. You know a ROI?

This is the problem Joanna is eluding to, it is very easy to optimise the pieces whilst missing the opportunity to optimise the whole.

Lets assume that you and your organisation are very good at requirements elucidation. A paper requirements spec delivers no business value at all. Software only has value when it is deployed to production. Lets assume that the development and delivery team is exemplary too, by the time the software has been delivered the business environment may have changed from the one which was the basis of your requirements elucidation. So what is the overall value of the entire exercise end-to-end?

It is amazing how the software industries perception of itself is very different from the perception of its customers. Most Business Managers I know would rather poke their eyes out with a sharp stick rather than through good money at a software project, never to see a return.

The world in which our customers live is non-deterministic and chaotic where change is a natural part of life. Now this may not fit our deterministic processes with long delivery cycles and numerous hand-offs but it is their reality.

Fortunately some of us have hung around long enough into the release and maintenance phases of projects to realise that a determinsitic approach to new product development just doesn’t work. This realisation breeds a certain degree of humility where you take smaller steps with frequent releases (1 to 3 months), being sure to deliver real business value with each release and relying on real world feedback (like an actual ROI) as a guide.

This type of humility is totally lacking in your comments.

Paul.

I think the statement that everyone participate fully throughout the project actually means that you would have to be engaged 100% of the time, just that you acknowledge that you are responsible for closing the loop with the customer and the rest of the team. I think that anyone on a project team should feel a sense of responsibility and see themselves as part of the team that is creating value for the customer - from inception to delivery.

Agree with your point about value - it is pointless getting into a project before determining that the product will be valuable.

I am interested in your point about poor quality; which deliverables are you referring to?

“A successful product requires everyone to participate fully throughout the whole project. ” That’s a luxury the average company cannot afford. As a Business Analyst for 20 years, staying on a project during development does not keep me occupied 100%. Given that and all the next projects waiting to get underway means I will be working on a project for requirements while one to many other projects continue through the lifecycle. If any of those projects needs me, I am there immediately. Working on one project only is un-realistic, multi-tasking on multiple projects is the true reality.