project management proverbs

Below are twenty project management proverbs that show you what can go wrong:

 

You cannot produce a baby in one month by impregnating nine women. 

 

The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times. 

 

The most valuable and least used word in a project manager's vocabulary is "NO." 

 

You can con a sucker into committing to an unreasonable deadline, but you can't bully him into meeting it. 

 

The more ridiculous the deadline, the more it costs to try to meet it. 

 

The more desperate the situation, the more optimistic the situatee. 

 

Too few people on a project can't solve the problems—too many create more problems than they solve. 

 

You can freeze the user's specs but he won't stop expecting. 

 

Frozen specs and the abominable snowman are alike: They are both myths, and they both melt when sufficient heat is applied. 

 

The conditions attached to a promise are forgotten, and the promise is remembered. 

 

What you don't know hurts you. 

 

A user will tell you anything you ask about—nothing more. 

 

Of several possible interpretations of a communication, the least convenient one is the only correct one. 

 

What is not on paper has not been said. 

 

No major project is ever installed on time, within budget, with the same staff that started it. 

 

Projects progress quickly until they become 90 percent complete; then they remain at 90 percent complete forever. 

 

If project content is allowed to change freely, the rate of change will exceed the rate of progress. 

 

No major system is ever completely debugged; attempts to debug a system inevitably introduce new bugs that are even harder to find. 

 

Project teams detest progress reporting because it vividly demonstrates their lack of progress. 

 

Parkinson and Murphy are alive and well—in your project

Is the document really Reqd?

To determine whether it makes sense to create a document, and if so how far to go with it, consider the following questions:

• Who is going to use this document?
• How are they going to use it?
• What do they expect to see appear in this document?  In what format?
• Who is going to pay for this document?
• What really needs to be said?
• What is the most concise way of saying it?
• What is going to happen if the reader needs more clarification?
• Does an existing document exist that we could fully or partially reference?

 

Time mgmt of your staff

This is from TechRupublic:

Susan Ward, writing in the newsletter Small Business: Canada, identified five personality types that can sabotage time management. They are:

The Fireman — Always handling the latest emergency; has no time to plan.

The Over-Committer — The one who can't say no. Seems like a great person to have around until you realize he or she never completes any of the accepted responsibilities.

The Aquarian — The laid-back persona. Ward warns that there is such as thing as being too "laid-back," "especially when it starts interfering with your ability to finish tasks or bother to return phone calls."

The Chatty Kathy — Usually involved in drawn out conversations with someone (that way they don't have to face some task that awaits them)

The Perfectionist — Is so exacting that projects never seem to get completed

It's one thing to recognize yourself in one of these types and try to take steps to remedy it. But it's quite another to try to manage these personality types if they belong to your staff members. In IT, you're going to run into a lot of "firemen." But that's the nature of the game with a line of work that forces one to be reactive much of the time.

The over-committer can be difficult even if he manages to complete all the tasks he takes on. Once word gets out that he's willing to do anything, people will start lining up to take advantage, believe me. This can throw a wrench into your own task management. You should insist that everyone clear these "favors" through you first. You can say no for the Over-Committer.

The Aquarian is a manager's nightmare because you will have to bear the brunt of the complaints about this person when phone calls go unreturned. Although you can't speed up his metabolism, you can insist on some parameters (give him specific timelines for completion of tasks, etc.) It's best to make the timelines shorter because you don't want to get too far along in a project and realize that little has been done. Also, remember that you don't want to discount the benefits of having such a person on staff — he's probably the one who remains calm when things go haywire.

I've written about the Chatty Kathy type before. I don't believe, as Ward says, that this is a trait that's developed as a way of putting off tasks. I think long-windedness is almost a compulsion with some people. But if it's the former, then you would do well to assign shorter-term (even daily) work deadlines with her. And then make it a point to see that they're met.

The Perfectionist is a hard one to manage. On one side, having someone produce work that's perfect is a great thing. But if the work never really gets completed, then you have a problem. You'll have to check in frequently with this person on his progress. If he's hung up on some detail, he can explain it to you. If the detail is not worth agonizing over, you can insist he move on in the progress.

Purpose of Metrics

To enable effective project management through numbers, we need to capture the right information, which will assist in taking effective decisions. 

The Metrics need to serve the following purposes:

1. early indications of problems,
2. the quality of the products,
3. the effectiveness of the processes,
4. the conformance to the process, and
5. the provision of a basis for future estimation of cost, quality, and schedule

Recommended Reading for a Software professional

Here's something to read along the Career path

As a fresher out of college, as and when you step into the world of software development, I suggest you pick up a programming language book related to VB / C# / java based on your nature of work and technology, language used. 

After a couple of years of coding its time to reflect on your performance and make necessary corrections Code Complete (2nd Edition) by Steve Mc Connell is an excellent book which will help you in this task

2 more years down the lane you just don’t do coding only, you also involve in Requirements analysis, Design etc. Its time to understand Architecture styles, patterns, unit operations, qualities, etc. there are n no. of books in the market. I suggest you can pick up books by Yourdon, Booch, Martin Flower, Luke Hoffmann, Karl Weigers, Paul Clements etc. check out architecture section of  www.sei.cmu.edu

(I will probably write a separate article on R & D I mean Reqmnts & Design)

By this time you would have followed one or more processes during the development life cycle, its time to uderstand the importance of the various process steps, terminologies etc, SDLC, Waterfall, Spiral, Agile, Lean  etc. for anything on the traditional process, I suggest you check out www.sei.cmu.edu Process Management section. For Agile check out http://www.agilealliance.org/  and for anything on Lean  which laso happens to be my favourite check out books by Poppendieck, Lean software development & implementing Lean

Around this time you would have slowly transitioned to a supervisory role and have probably started making decisions on behalf of the team. You would have taken a few right decisions & made a lot of mistakes too. You have reached a transition point where you need to get things done from others. At this point you should read Rapid Development by Steve Mc Connell, It will help you not only reflect on your mistakes, but also learn from others mistakes and how to handle various real life scenarios. You should also read books from Gerald Weinberg most of them are classics

Couple of years down the line you are ready for Project Management resposibility, Its time to make plans, estimates, Monitor progress and Control execution. I recommend two books at this stage, Project Management - A managerial Approach by Jack Meredith and
Project Management: A Systems Approach to Planning, Scheduling, and Controlling by Harold Kerzner. These two books cover almost everything you need to know, to be a successful PM.

Iam sure I have missed out a lot of good books in this list, people will have different opinions, tastes and habits.
 
There are a lot of other books of general interest that I have read, and found very useful. I have restriced this list to Software development processes only, Hope it is useful

Rules for sound documentation

Documentation should be written from the point of view of the reader, not the writer.
Documentation should be organized for ease of reference, not just ease of reading.

Avoid repetition. Each kind of information should be recorded in exactly one place. This makes documentation easier to use and much easier to change as it evolves. It also avoids confusion, because information that is repeated is often repeated in a slightly different form, and now the reader must wonder: Was the difference intentional? If so, what is the meaning of the difference? What information was the author trying to convey to me that I am not picking up?

Avoid unintentional ambiguity
One of the greatest sources of ambiguity in architecture documentation are those ubiquitous box-and-line diagrams that people often draw on whiteboards or backs of napkins. While not a bad starting point, these diagrams are certainly not architectures. For one thing, the behavior of the components is not defined, and this (as we shall see) is a crucial part of the architecture. But beyond that, most of these diagrams suffer from ambiguity with respect to the component and connector types. Are the boxes supposed to be modules, objects, classes, processes, functions, procedures, processors, or something else? Do the arrows mean submodule, inheritance, synchronization, exclusion, calls, uses, data flow, processor migration, or something else?

Use a standard organization. Each document should conform to a standard, planned organization scheme, and this scheme should be made known to the reader. A standard organization offers many benefits. It helps the reader navigate the document and find specific information quickly (and so this is also related to the write-for-the-reader rule). But it also helps the writer of the document. It helps plan and organize the contents,

Record rationale. If you are documenting the results of decisions, record the decisions you eschewed and say why. Next year (or next month) when those decisions come under scrutiny or pressure to change, you will find yourself revisiting the same arguments and wondering why you didn’t take some other path. Recording rationale will save you enormous time in the long run, although it requires discipline to record in the heat of the moment.

Keep it current. Documentation that is incomplete, out of date, does not reflect truth, and does not obey its own rules for form and internal consistency will not be used. Documentation that is kept current and accurate will be used. The reason is that, backed up by high-quality documentation, questions about the software can be most easily and most efficiently answered by referring the questioner to the appropriate document.

Review documentation for fitness of purpose.

(Source: I don’t recollect where I got this from, as and when I find out I wll update this)

Principles of Objectivism

The basic principles of Objectivism can be summarized as follows:
 
Metaphysics
"Reality, the external world, exists independent of man's consciousness, independent of any observer's knowledge, beliefs, feelings, desires or fears. This means that A is A, that facts are facts, that things are what they are—and that the task of man's consciousness is to perceive reality, not to create or invent it." Thus Objectivism rejects any belief in the supernatural—and any claim that individuals or groups create their own reality.

 
Epistemology
"Man's reason is fully competent to know the facts of reality. Reason, the conceptual faculty, is the faculty that identifies and integrates the material provided by man's senses. Reason is man's only means of acquiring knowledge." Thus Objectivism rejects mysticism (any acceptance of faith or feeling as a means of knowledge), and it rejects skepticism (the claim that certainty or knowledge is impossible).

 
Human Nature
Man is a rational being. Reason, as man's only means of knowledge, is his basic means of survival. But the exercise of reason depends on each individual's choice. "Man is a being of volitional consciousness." "That which you call your soul or spirit is your consciousness, and that which you call 'free will' is your mind's freedom to think or not, the only will you have, your only freedom. This is the choice that controls all the choices you make and determines your life and character." Thus Objectivism rejects any form of determinism, the belief that man is a victim of forces beyond his control (such as God, fate, upbringing, genes, or economic conditions).

 
Ethics
"Reason is man's only proper judge of values and his only proper guide to action. The proper standard of ethics is: man's survival qua man—i.e., that which is required by man's nature for his survival as a rational being (not his momentary physical survival as a mindless brute). Rationality is man's basic virtue, and his three fundamental values are: reason, purpose, self-esteem. Man—every man—is an end in himself, not a means to the ends of others; he must live for his own sake, neither sacrificing himself to others nor sacrificing others to himself; he must work for his rational self-interest, with the achievement of his own happiness as the highest moral purpose of his life." Thus Objectivism rejects any form of altruism—the claim that morality consists in living for others or for society.

 
Politics
"The basic social principle of the Objectivist ethics is that no man has the right to seek values from others by means of physical force—i.e., no man or group has the right to initiate the use of physical force against others. Men have the right to use force only in self-defense and only against those who initiate its use. Men must deal with one another as traders, giving value for value, by free, mutual consent to mutual benefit. The only social system that bars physical force from human relationships is laissez-faire capitalism. Capitalism is a system based on the recognition of individual rights, including property rights, in which the only function of the government is to protect individual rights, i.e., to protect men from those who initiate the use of physical force." Thus Objectivism rejects any form of collectivism, such as fascism or socialism. It also rejects the current "mixed economy" notion that the government should regulate the economy and redistribute wealth.

 
Esthetics
"Art is a selective re-creation of reality according to an artist's metaphysical value-judgments." The purpose of art is to concretize the artist's fundamental view of existence. Ayn Rand described her own approach to art as "Romantic Realism": "I am a Romantic in the sense that I present men as they ought to be. I am Realistic in the sense that I place them here and now and on this earth." The goal of Ayn Rand's novels is not didactic but artistic: the projection of an ideal man: "My purpose, first cause and prime mover is the portrayal of Howard Roark or John Galt or Hank Rearden or Francisco d'Anconia as an end in himself—not as a means to any further end."

Excerpts from www.aynrand.org