There are at least two answers to the question whether functional specifications are useful or not. Agilists would say specifications value is low since software will be changing significantly during iterations. The other party doesn’t even start a project without singed detailed functional specification.
I think both sides are right. Sometimes. It depends on client you work with. If you have a good partner to employ agile approach and you value this technique, go for it. As far as you are able to find a consensus with your client you won’t need detailed specification up front. Probably some documentations at the end of the process will be enough.
On the other hand there are customers out there who will exploit lack of defined functionality range to switch into feature creep mode. There will be a lot of new critical functions created on the fly. There will be a lot of interpretations how different things should work. Your only shield is anything which was formally agreed before. Possibly functional specification signed along with the agreement.
Actually it’s neither the size nor the type of the project which plays the main role here. Not even your software development and project management methodologies. The client is important. Let’s take a typical implementation for mobile operator (things I deal with every day). Project timeframe between 6 and 12 months. With the same system, similar scale and two different customers we need two approaches.
One client sets us a list of goals and work actively with us during development. We don’t even try to create detailed description of developed features and we expect a number of changes when they see first result of our work. Since client attitude is reasonable and they don’t bring things completely out of agreed scope it works fine.
Another client brings very strict verification phase when a number of new “improvement ideas” are submitted as bugs. As far as we don’t have detailed scope of work there will be some interpretations how different features should work. And since the requirements are changing over time (which is fairly natural) no specification means feature creep. A feature creep invited on the very late stage of the project which blows the schedule up.
Since I could say which style I prefer it doesn’t really matter. What matters is which style is preferred by our beloved clients. We can adjust ourselves. But the answer to the question from the title will remain the same: it depends.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
{ 2 comments… read them below or add one }
here here!
it’s always about the client – or at least it should be.
You have to learn to work with them.
And if you do well you get a chance to build an ongong relationship.
And if that goes well, you get their trust, and then, finally, you can get them to try out ideas you have about agile and otehr innvatons that might save them money.
And that’s exactly my answer to most questions regarding different aspects of project management. Mothodology, documanentations, communication, whatever. It all depends on the customer.
OK, it all depends on the customer unless you’re a big company like Accenture or IBM which are usually expected to force their way of managing projects.