Todd's first book delivers twenty-five years of project rescue experience. Unlike other books on the subject, Rescue the Problem Project focuses on the process to rescue the project. This is the critical few weeks that transform a failing project to a successful project. Other processes blindly layer processes on top of a project without finding the cause of the failure. Rescue the Problem Project focuses on root cause analysis to determine the source of problems and solve them once and for all.

The book starts by discussing the biggest hurdle in rescuing a project—realization that there is a problem—and proceeds through detailed discussion of the four-step process to recover them—audit, analysis, negotiate, and execute. In addition, it includes a complete discussion of four key processes to prevent failure.

Executives define vision, strategy, and goals to advance the business. Projects enable companies to meet those goals. Between strategy and projects, there is a lot of work to be done—work that lays the foundation for project and operational success. Through experience and research, six common gaps exist in organizations that inhibit project success—an absence of common understanding, disengaged executive sponsors, misalignment with goals, poor change management, ineffective governance, and lackluster leadership.

Executives build PMOs to ensure people follow a process. Companies require project management certification. Project managers have religious battles over agile and waterfall. Mistakes occur and managers implement more processes to prevent their reoccurrence.  Yet there is another philosophy that says this is the wrong direction completely. This ideology feels that people need more independence and less bureaucracy. The people who follow this think that people need more leadership training. People or Process, as the name implies, looks directly at these arguments and the role of people versus process in a project's or an organization’s success or failure. 

Negotiation is at the heart of every recovery. Once the problems are determined, you must get everyone to concur on the solution. Achieving agreement, however, is inextricably bound to culture—from Asia's polite bows and constant "yeses," to the fist pounding demands of the Middle East. The distinction hit me in back-to-back projects. Culture shock abound. Little did I know, I would find solace and guidance in a favorite Monty Python flick.

Whether you are a project or a functional manager, estimates are a daily part of your life. Team members need to make estimates for a variety of reasons, these include:

• The amount of time for a task.
• The cost for resources.
• The cost of software, hardware and other materials.
• The time required to finish a task.

Projects build in technical debt and maintenance groups remove it—if your organization has a maintenance group. Technical debt accrues in any product, whether or not it has a technical component. It is the result of taking shortcuts when building the product. Sometimes it is the result of not having enough time, on other occasions it is due to not having the right tools. Anything from the implementation of the software component to light fixture can have technical debt. Promises are made to correct it later, but later never comes.

Daily, we are involved in two acts—developing and following process and generating estimate. We cannot escape them; they are part of the human experience. Processes are required to maintain consistency, accuracy, and abide by regulations. Estimates are required in every task we do.  Add people—people with personality, prejudice, and protest—and estimating becomes quite demanding.

People routinely ask me the question, "What do you do when you find yourself on a project that is a hopeless failure?" It was raised again a few weeks ago in a Focus.com roundtable and then last week in an interview with Andy Kaufman. It only matters if the executives above the project are ignorant to how dire the situation is. It is tricky, trying to convince someone that they have a problem when they refuse to acknowledge the obvious—a tough and politically dangerous sell. The general consensus is "dust of the résumé." However, there is a logical approach to the problem—be logical.

Daily, we are involved in two acts—developing and following process and negotiating with stakeholders. We cannot escape them; they are part of the project management experience. Processes are required to maintain consistency, accuracy, and abide by regulations. Negotiation is required to create a valuable solution that meets the triple constraints.

To deal with the reality of business, you need a toolbox of techniques that can address the needs of the people who supply and consume information and the competing interests of stakeholders.

"Why is it that when you get hired you are no longer the expert?" A chuckle rippled through the audience; however, the woman asking the question was serious. I turned the question back to the audience of director level managers, "Why is this the case?" There was silence. Finally, I proffered that it was management's lack of understanding the skills of the people working for them. "Who in your organization can you implicitly trust?" More silence. It is sad that organizations know so little about the people that they hired—the people on which they stake their company's future.