When a project has an end date we try to build a fortress instead of a software. We fear the after-project. As a result, we risk missing the deadline.
It is good to start a countdown… only when we arealmost eady to launch. We should not start the countdown at the beginning of a project: I am convinced that it won’t help the product if we build it under time presure. This will not stimulate creativity and adaptability.
If we follow a road and are focused on our destination, we are not able to grasp opportunities. The same applies to software projects. Sometimes it is very nice to follow our instinct. And instinct cannot be anticipated.
We should never forget that a software is like an helium balloon: it can be shaped and reshaped, it can explode with a single needle, and if we let it go, we loose control! We should never “end” a project, because a software will always have to be adapted and to be protected against failure.
Without trust, honnesty and transparency, communication is nothing. And true communication is the number one key factor for a successful project.
Developers are by nature part of the management of the project. They are managing the project developement, because they are doing it.
Initial estimate of the time and cost to build a usable prototype can be a possible alternative to estimating the time and cost to build the full product. It adds flexibility and leads to less criticality.
The best discipline that you can impose is your own self-discipline.
A conflict withothers reveals in most cases a conflict within yourself.
In true teams everybody is a servant of others. Because everybody needs others.