Development planning and the two calendars: a methodology that works!
Yesterday I have finally completed a part of the development process I was involved in for the last four months. The complexity of the project was quite high, and the need to operate with a multithreading windows service is harder than the creation of web pages: there are no visual warnings for the errors and the debugging is more complex.
The deadline are coming closer, but I have been able to anticipate them, granting me the time for some deep testing, debugging and documentation: all the things that too many times are skipped for the lack of time. It is a good feeling to be ready to face every possible naughty bug without the pressure of having the deadline still on your neck, and the methodology that works best is the two-calendars one.
The two calendars methodology is very simple: when you get the requirements and you prepare the Analysis and Design, you should check carefully the times you think correct to deliver every single part of the system you are building; then you rethink everything adding the debug, testing and everything else you should think about. That is you internal calendar: the development deadline. Now you can think about a certain percentage of error in the calculation. The percentage depends on you, mainly, and the smaller the release cycles are (more delivery with small improvement in the system) the easier the time analysis will be. Normally I try to keep into consideration at least a 10% difference, that can rise for high risk issues. This will be your external calendar, the one the customer will have to approve. Now, the external calendar defines the deadline for every release, while the internal one defines the development deadline. Every time you hit an internal deadline, you should adjust the other releases internal calendars accordingly (anticipating or postponing the starting time).
This methodology will allow you to have the time for some deep testing and debugging and for the creation of a good documentation or, in the worst case, the time to cover the eventual faulty timing analysis.
Tight Deadlines: I want to make a note on something that is usually mentioned in the Job Specs…
“…you should be able to cope with thight deadlines…”
In my humble opinion, this string can contain tow different meanings: 15% of the time the market the company is involved in is very obsessive and have few time for the specifications, the remaining companies have some very deep problems with time analysis and development management. Big statement, isn’t it? Yes, it is indeed, but in my experience I have seen thatif you’re aimed to create something that will satisfy your customer, you will not try to budget half the required time you will need to create a quality software and you will not underestimate the importance of a deep Analysis and Design: if you do it, it means that the company has a big flaw!
No Comments Yet