I am a Technical Team Leader. I have some developers reporting to me. So let me say this; Regulated, Regimented development. That's what I try to use most of the time. Yes, really. It is extremely important to start a project with good specifications. First, this means that I have had several conversations with my customers about what they are expecting to get out of the project, and how they expect to interact with it before anybody starts coding.
Requirements specifications make their way to Functional specifications. This is where I admit that these are often done incorrectly, but they are still done. Let me explain that. The requirements are the high level things that management wants to accomplish. The functional specs are supposed to be the things that define how the customer will interface with the product to meet the requirements. However, more often, most of the interface decisions are stuffed into Requirements leaving the functional specification to double as a technical roadmap to how the project will be completed.
As long as all of the necessary information is there, it doesn't really bother me.
No Accounting for Expectations
One thing that all of these requirements do not get me is a customer that actually understands the full implications of what they are asking for. Further, it doesn't give me the forsight to understand that something that the customer legitimately asked for and agreed that they wanted, is actually the opposite of what they need after they see what they are about to get.
This point is why I need the documents. This part is why that top down approach is really, really important.
No, not to shove it down the user's throat, but to clearly be able to go to the project management team and say, this project is under threat. What the customer needs is NOT reflected in this documentation, and I need to go through some development iterations quickly with the customer until I can really figure out what they want. I use the documenation, plus the frustration of the customer to switch to collaborative development iterations.
1) Here's the almost finished development that does what you asked for.
2) Customer realizes that prototype needs something different.
3) Remind customer where they asked for what they got, get specific reasoning for the change. Does it save time? What goes wrong if we leave it as is?
4) Go back to project management, explain the problem and the reasons for the problem.
5) Work with the customer to fix it BEFORE it's a service issue later.
For the customer, the trade off is often that they lose features that were originally asked for if the timelines cannot be extended. As long as project management and the customer understand this up-front, then things go pretty well.
I recently led two separate projects that went through agile-collaborative cycles come to a close. The one that started with the most documentation has the happiest result. The one that started with almost no documentation is still a bit of a monster that is difficult to add new features to.
The worse of these was for an editor to help quickly add new data into a system. To start agile at the very beginning of a project in this case caused the completion date to slip by almost a year, and we lost the lead developer during (and likely because of) the project. The length of the project slip was partly due to that developer leaving, but I also know it has a lot to do with the fact that it was an agile project from it's inception. The customers lost track of the primary goals of the system, and around month two changed out it's primary goal. By it's end, a project which was supposed to help users quickly enter new data into the system was released as something that couldn't add new data, but only edit old data records. That's what the customer wanted, but the fact that the purpose did such a huge change really makes me wonder why it didn't have more documentation at it's beginning.
The one that worked much better had documentation that we kept referring back to, which actually helped keep our customer on-task as well. It could have been derailed by a long set of requests for search and reporting functionality. Request was deferred to a separate, second project, to leave the core functionality alone. Reporting got done on time as well.
Both of these projects had 6 month time-lines to start. Both of these projects finished with a great deal of customer collaboration, and iterative development cycles. One of them had good documentation at it's beginning telling us what our goals are. The other was waylaid by the changing goals of the customer, and since there were no good requirements to begin with it fell far from it's original mission.
I'll also mention that the original business sponsor has come back asking why it doesn't do what was originally intended. This ongoing conversation is not fun.