I just finished first draft of a my input to a technical design document.
I would very much like to be more into agile development methods, but the place where I am working currently is using a process to control projects, which is more a waterfall model.
At the same time the model is lacking or circumventing itself in so many points, that it almost is ridiculous.
Well anyway, I have been involved in these input processes for a few projects now - and I can see severe problems in the process and these seem to be related to organization.
The online team with is located in marketing (which is a good thing), is under the Marketing/Sales division, the technical projects are run and are primarily controlled in the Technology division. So the technical specifications often totally lack the online aspect and input. The systems involved in the online part are only mentioned by URL. Sometimes with a few screen shots or very broad requirements.
It struck me at some point that this lack of focus on the online aspect has two sides.
1. The lack of specification detail, gives the online team totally free hands. then again they would have this anyway, but that is due to the holes in the model
2. The lack of specification detail, leaves the online team to not be regarded as a serious part of the technology of the system. This mean that resource problems and workload are parameters are not communicated to the rest of the organization via the formal channels
But things work anyway... due to the employees
The currently used model has holes and in the end everything ends up being very pragmatic, this introduces problems with resources and workload, but still things get done, late and at a very high cost, again due to the model.
So what I have done for now is implementing an approach I have used in my own company. I write a synopsis as input to the technical specification. This synopsis is a work document, it lives for as long at the project/work package is active and it contains requirements, issues, issue log, references, recommendations, estimate and basic component architecture.
This document can be used to outsource the assignment to other developers, but myself - for now I have only written the synopsis for assignments given to my company, which mean that we provide the necessary resources and I take on the assignment and communicate it to a hired resource.
The synopsis also serves another purpose, it gives me an understanding of what it is the client wants.
I am not much for doing a complete design of an application, since I want the developer assigned to the task to be free to implement as he/she sees fit, just adhering to the requirements and general best practice.
Which reminds me, I really, really want to write a developer handbook for the client, describing the framework in use and so on. It would save me a lot of explaining if I could just reference this document.
Okay, so some of the hackers I am working with and are hiring, tend to think that documentation like this is over-doing it.
My synopsis approach addresses several problems as I see it:
