Failed execution is a plague upon many project teams. Statistics show that "one of three decisions are not communicated," "65% of employees are not held accountable," and that "68% of managers agree firefighting inhibits focus on longer term priorities."

The conclusion drawn from this data-and a lot more-is that poor execution causes more failures than poor strategies. To many experts, execution is the key to success in the business world today."

Execution flaws that plague many projects include: Decision latency (slow response); Lack of feedback (assumptions), Unknown inter-dependencies (surprises), and Failure to deliver results (promises made, but not kept).

In an on-going survey of the challenges confronted by project teams in Silicon Valley, the top four have not changed in eight years; they are:

1. Lack of commitment.
2. Defining project scope and managing change
3. Lack of resources
4. Unrealistic schedules.

Given this backdrop, what can a project leader do to deliver predictable results?

First Step

Become a strong advocate for your project. (See No. 1 in this series, "Getting the Resources to Succeed")

Second Step

Focus on Action, Deliver Results. A project's "right actions" are contained in the schedule, but they are not what most team members might expect. Right actions are not doing what you know. Right actions are doing what needs to be done. This difference requires, for some, a profound shift in perspective in how to go about achieving project success.

Right actions are defined by the project's deliverable results (DRs), not by tasks or activities. DRs are the tangible, measurable results that drive the project. Success is measured by counting planned v. actual completed DRs.

When a team member is asked, "Are you done?" what's the correct answer? ("My DR is done.") When a project team leader is asked, "Are you done?" what is the correct answer? ("Our DRs are done.")

Identifying and assigning DRs to team members is the instrument for achieving predictable results in a project.

DRs consist of three elements: a tangible result + action + date.

Examples include: Business case approved (by date); software coding begun/compiled/tested/approved (by date); beta testing completed (by date); contract signed (by date); user manual approved (by date).

Tasks or activities describe individual efforts to produce a DR.

Examples for a user manual (or any document) include: Prepare first draft; submit artwork; review draft with supervisor; meet with (name) to gather requirements/information.

DRs provide the following benefits:

• Context for results by (a) breaking-down requirements into right actions for each team member and between team members; and (b) specifying the tangible, measurable criteria for success
• Ownership and accountability for right actions to measure commitment
• Collaboration and alignment of right actions to complete a specific DR and between interdependent DRs
• Feedback and visibility on right actions across the project
• Better decisions to prioritize right actions and allocate resources to achieve them

The project is a chain of DRs. The project end result is the last DR in the chain.

Third Step

Help others do their DRs.

Fourth Step

Acknowledge others' successful completion of DRs.

Fifth Step

Do your DRs.