Words of Wisdom

The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.

Mark Twain

The essence of an estimate is expectation. When you give an estimate, you express your expectations about what will happen. Built into each estimate is an element of uncertainty. If you weren't uncertain, you would use a word other than 'estimate.'

The essence of a commitment is promise. A commitment is a pledge or promise. When you make a commitment, you declare your intention to create some result, and you invite someone (usually another person, but sometimes yourself) to rely on your intention.

Experiment: To determine whether your team members see their estimates as commitments, try this test. The next ten times you ask for estimates, ask also for commitments. How close are the estimates to the commitments?

Experiment: If you think I'm all wet, and you're sure that when your team members' give estimates they really are making commitments, try this test. Stop asking for estimates, and from now on ask only for commitments. If you balk at that, perhaps you see estimates and commitments as not quite the same.

Experiment: If you ask Fred, "When will you be done?" have you asked for an estimate or a commitment? What does Fred think you asked for? If Fred says, "Two weeks from today, " has he given an estimate or a commitment? What might happen if you want a commitment and Fred thinks you want an estimate? What might happen if you want an estimate and Fred thinks you want a commitment? How could you make it crystal clear whether you're asking for an estimate or for a commitment? How could you make it crystal clear whether Fred is giving an estimate or a commitment?

Dale H. Emery, Estimates Are Not Commitments - August 11, 2003

So you've got all your numbers together, a plan written, schedule laid out and it's time to begin the project. Before you start, you need to make sure you can answer 10 questions:

1. How will you know you are done?
2. What activities and deliverables are NOT included?
3. What assumptions are you making about the project team?
4. What assumptions are you making about the actions of others?
5. How did you derive the total effort?
6. How did you derive the total schedule?
7. How did you determine the correct allocation of effort and time between tasks?
8. What would be the cost impact of accelerating the schedule by 25%?
9. What are the risk factors that would cause the schedule to slip or the costs to overrun?
10. What metrics will we use to quantify and track progress?

Make sure you can answer all the questions before starting implementation. Successful projects are not successful because they did not run into problems, but because they anticipated the problems and overcame them

INQUIRER, Two thirds of CIOs see their jobs at risk - January 14, 2005

Intelligent control appears as uncontrol or freedom.
And for that reason it is genuinely intelligent control.

Unintelligent control appears as external domination.
And for that reason it is really unintelligent control.

Intelligent control exerts influence without appearing to do so.
Unintelligent control tries to influence by making a show of force.

Lao Tzu, Book of Ethics

We rightly consider keeping many balls in the air a circus stunt. Yet even the juggler does it only for ten minutes or so. If he were to try doing it longer, he would soon drop all the balls.

Peter Drucker, The Effective Executive - 1966

According to the Standish Group's Extreme Chaos Report:

1. Two thirds of all projects studied were either failures or what they call "challenged"
2. Only half of the desired features made it into the finished product
3. Cost overruns happened on nearly half of all projects, although the good news here is that cost containment has been substantially reduced over the 189 percent reported in the 1994 study
4. Time overruns occurred 82 percent of the time, or on nearly every single project. Equally disturbing is that the trend has been worsening, since time overruns occurred only 63 percent of the time in the 2000 study.

Make sure you can answer all the questions before starting implementation. Successful projects are not successful because they did not run into problems, but because they anticipated the problems and overcame them

Elizabeth and Richard Larson, Analyze This Project - June 16, 2005

The 10th edition of the annual CHAOS report from The Standish Group, which researches the reasons for IT project failure in the United States, indicates that project success rates have increased to 34 percent of all projects. That's more than a 100-percent improvement from the success rate found in the first study in 1994.

Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, "The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward."

The Standish Group has studied over 40,000 projects in 10 years to reach the findings.

Software Magazine, Standish: Project Success Rates Improved Over 10 Years - January 15, 2004

1. I Am In The Middle Of Several Projects
2. I Am Not Comfortable With That
3. I Am Not Taking On Any New Responsibilities
4. I Am Not The Most Qualified Person For The Job
5. I Do Not Enjoy That Kind Of Work
6. I Do Not Have Any More Room In My Calendar
7. I Hate To Split My Attention Among Projects
8. I Have Another Commitment
9. I Have No Experience With That
10. I Know You Will Do A Wonderful Job Yourself
11. I Need To Focus More On My Personal Life
12. I Need To Focus On My Career Right Now
13. I Need To Leave Some Free Time For Myself
14. I Would Rather Decline Than Do A Mediocre Job
15. I Would Rather Help Out With Another Task
16. Let Me Hook You Up With Someone Who Can Do It
17. No
18. Not Right Now, But I Can Do It Later
19. Some Things Have Come Up That Need My Attention
20. This Really Is Not My Strong Suit

Ramona Creel, 20 Ways To Say No

Pack them in. Almost every project at Google is a team project, and teams have to communicate. The best way to make communication easy is to put team members within a few feet of each other. The result is that virtually everyone at Google shares an office. This way, when a programmer needs to confer with a colleague, there is immediate access: no telephone tag, no e-mail delay, no waiting for a reply. Of course, there are many conference rooms that people can use for detailed discussion so that they don't disturb their office mates. Even the CEO shared an office at Google for several months after he arrived. Sitting next to a knowledgeable employee was an incredibly effective educational experience.

Eric Schmidt and Hal Varian - Newsweek, Google: Ten Golden Rules - December 2, 2005