There are Top 10 Laws of Project Management I find entertaining and wise. They are kind of professional folklore but contain practical observations that otherwise theoretical books convey in way too many words.
Project Management is not exact science as it deals with people. Hence its “laws” are not absolute. Also, approach to a project very much depend on its specifics. For instance innovative software development projects often call for very different methods than, say, construction projects.
I happen to have experience in software development both as a developer and manager and I am tempted to interpret the Top 10 Project Management Laws from this perspective. Here is how I see the “soft” versions of the Top 10 Project Management Laws:
1. Augustine’s Law: A bad idea executed to perfection is still a bad idea.
In software a bad idea, even poorly executed, may turn out to be a brilliant one.
2. Lakein’s Law: Failing to plan is planning to fail.
Planning in software development is the best way to fool yourself.
3. Saint Exupéry’s Law: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Perfection of software remains equally distant no matter whether you are adding or taking out things.
4. Fitzgerald’s Law: There are two states to any large project – too early to tell and too late to stop.
The two stages in software development projects are: too early to stop and too late to tell.
5. Parkinson’s Law: Work expands to fill the time available.
Relativity effects are observed in software development: not only the work expands but also time shrinks and this process is not constrained by any project management estimates.
6. Constantine’s Law: A fool with a tool is still a fool.
In software development a fool without a tool is a bigger fool.
7. Graham’s Law: If they know nothing of what you are doing, they suspect you are doing nothing.
If they know what you are doing writing code, they suspect you are crazy.
8. Murphy’s Law: If anything can go wrong, it will.
If something went well in software development this was rarely planned.
9. O’Brochta’s Law: Project management is about applying common sense with uncommon discipline.
Imposing discipline when developing software is the surest way to kill the project, the team and yourself as a project manager. (Corollary: No matter they write programmes, developers themselves are not programmable.)
10. Kinser’s Law: About the time you finish doing something, you know enough to start.
In software development about the time you finish doing something everything has changed: customer expectations, budget, technology, the team and the project manager (if any).
I hope the laws I suggest above are self-explanatory. In further posts I am going to elaborate on those laws and their corollaries in more depth.