Rescue the Problem Project
An excellent book. There is so much good advice in this text, I had to resist highlighting even more than I did. I think I will be using this as a reference guide for many years to come. Thank you to those on Twitter that recommended it to me.
Printed in the United States of America. This publication may not be reproduced, stored in a retrieval system, or transmitted in whole or in part, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of
A project in motion tends to remain in motion, even when it is moving in the wrong direction.
Armed with these four lessons: 1. The answers are in the team. 2. A strong team can surmount most problems. 3. Stay involved with the team. 4. Objective data is your friend, providing the key way out of any situation. I join a project and work to fix its ills.
Table I-2: Chapter Relationships
Andrew Doran
Useful
All projects are actually two projects—the customer’s and the supplier’s.
All projects are actually two projects—the customer’s and the supplier’s.
If the only option is to proceed with a scaled-down project, one that delivers late, or one that costs significantly more, the result may be worse than canceling the project.
Being red is a subjective quality of a project, an unanticipated variance from the project’s current definition based on each organization’s rules.
performing an audit or analysis of a project and then making a decision to make no changes is an action—a conscious decision to let the problems resolve themselves. This is a valid choice.
A qualified recovery manager, rather than management, needs to invest time in the project and determine what is actually wrong. When management steps in to help, the recovery effort is likely to be part time and consists of asking for reports or meetings. It does little to find root problems.
Although determining root causes up front takes more time and requires making tough decisions early, in the end it requires less management and increases the odds of a successful recovery.
A red project never has one problem causing its ills.
Figure 1-3: Extended Project Team
Andrew Doran
Useful diagram.
The project should remain running while being recovered so the problems can be seen firsthand.
The result is that the steering committee must declare the project is red. For this action to have meaning, however, it must result in the steering committee providing direction and funding for project recovery.
Without guidelines, the recovery manager is directionless.
Andrew Doran
Need to define the goals and parameters for the recovery manager.
The ideal candidate is a seasoned, objective project manager who is external to the supplier and customer, has recovery experience, and a strong technical background (for the conversations with the technical team).
The project manager should be accountable for all that has gone on, but the project’s management should have checks and balances to minimize the chances of failure.
Above all, recovery managers need to be honest brokers—objectivity is paramount. They cannot have allegiance to either side of the project.
the steering committee should create a mission statement for the recovery that defines the recovery guidelines for the engagement, the reasons a recovery manager is required, and the expected results.
The recovery manager needs to know how much authority he or she has before the engagement begins so that when boundaries are crossed the recovery manager knows how thin the ice is.
In addition, the following questions should be answered to determine the viable options for the recovery:
Andrew Doran
Useful list.
The act of interviewing the extended project team will improve communication. Other than that, do not implement any other formal processes at this stage of the recovery,
team members know the problems and their accompanying resolutions; someone just needs to ask them.
Ideally, interview people randomly, because this provides a continuous flow of alternating views on the issues.
Begin the interviews with a thin agenda.
There are, of course, more questions to ask. Follow-up questions should be open ended.
Andrew Doran
Good list here.
The recovery manager should neither agree nor disagree with the answers.
interviews should include everyone governing a project
In these interviews, determine the time line for when the interviewee became aware of the project’s problems.
Assess the subcontractor’s risks, and record any in the risk register
Experience shows that deficiencies in four processes (meeting minutes, change management processes, risk registers, and scheduling) constitute the majority of all problems.
avoid the trap of thinking the commonly mentioned problem is the actual root issue.
The auditor must add the change orders to the original scope and make sure the aggregate scope matches the work in progress.
Read the specifications to determine how well they match to the contract, charter, and requirements. If there are discrepancies, prepare a reconciliation list.
When reading contracts, charters, or inception documents, use three colors of sticky notes or highlighters—one for “What,” another for “When,” and a third for “Who.”
In other words, this simple suggestion adds significant scope to the project, which, when completed, could be unusable.
Andrew Doran
Great example, could be used to illustrate the purpose of internal scope control.
Building a maintainable system is a best practice and is assumed to be in the project scope. Extensibility, on the other hand, must be part of the requirements; it is not a best practice.
Andrew Doran
I agree with this.
Agreeing with the customer is the comfort food of projects.
remember to document the assumptions on the triple constraints.
the only way to squeeze projects reliably into a timeline is to change the methodology, remove scope, or both.
the only way to squeeze projects reliably into a timeline is to change the methodology, remove scope, or both.
One goal in the recovery’s audit phase is to find where risk can be brought forward and to get people to think about this concept before developing the corrective action.
The critical-to-quality concept ensures the project is focusing on the elements with the greatest value. A feature done perfectly is useless if it has no value to the customer.
Interviewing the team can determine the degree of familiarity with the technology and establish reasonable estimates for learning curves and rework.
organizations with a portfolio of projects need a portfolio of processes.
Implement a strict policy that all communication goes through the recovery manager.
Even if some of the decisions are less than ideal, the project will at least begin moving forward. Just be ready to act on new data and update the decision.
The fundamental processes to address are meeting minutes, change management processes, risk registers, and schedules.
The minutes serve as a historical record of the objections and rebuttals. It should reference any discussion resulting in an action item, debate prior to a conclusion, and comments leading to the next meeting’s agenda.
Andrew Doran
I'm not sure I agree with the ‘he said, she said’ style of minutes. In my experience it is better to just document the key decisions and action points – this is easier to read, provides greater clarity and is more likely to be read and challenged by those on the distribution list. Also, no meeting minute attachments – do it in email. If people have to open an attachment to read the content they are unlikely to do so.
Everyone on the team should ask for a change order before altering his or her deliverable.
business analysts rarely know the customer’s needs better than the customer, so they rarely deserve all the blame.
Leadership: the art of getting someone else to dosomething you want done because he wants to do it
The inability to replace underperforming resources will cripple the recovery.
Immediately start enforcing the contract and a change management process. This creates a fair and even playing field. Other than that, treat them as any other team members.
Uncovering the project’s true status may shock some stakeholders. They may require significant education to understand the issues and the effort required to fix them.
Although one-on-one meetings take a significant amount of time, the value is immeasurable.
At least once a week, the recovery manager should be available to team members in an unstructured environment. Walk around to the team’s work area or, for dispersed teams, telephone members at a convenient time for them.
Technology is so much fun but we can drownin our technology. The fog of informationcan drive out knowledge.
Hidden costs and overstated functionality are the most common reasons for failure. Validate that a solid due diligence was performed on the vendor and the product prior to its purchase
Schedules are unique to each project. Beyond the imperatives of design, build, test, and deploy, projects tend to have few things in common.
If necessary, the recovery manager should take the time to educate the core team on an estimation process.
In most cases, managers treat estimates as quotes and reprimand people for deviations. If a task completes early, the person is reprimanded for padding the estimate; if late, the reprimand is for missing the deadline. Thus, team members are motivated to pad heavily and never complete a task early.
To reshape the project so that it can come in on time, rank its components from the greatest to the least consequence of failure if they were to be removed. Remove items from the bottom of the list until the schedule fits. Then add smaller features from the wish list to achieve an acceptable value.
The word agile was not used to describe the process; the executive management would have never allowed an agile process.
Andrew Doran
I think this is a good approach in a lot of large organisations where the term ‘agile’ has been used for ‘cowboy’.
One key aspect often overlooked is agile’s use of quadruple constraints (scope, schedule, stability, and budget) versus the more familiar triple constraints.
Andrew Doran
My understanding is that with an agile methodology cost and time are usually fixed and the scope is the variable component. I have never heard of quadruple constraints before.
Adding stability to the list of project variables resets the team’s thinking so it focuses on showing the customer value rather than wasting time adding features and functions that will be rarely, if ever, used.
Andrew Doran
I don’t understand how ‘stability’ differs from scope here.
Agile’s Envision Phase
Andrew Doran
Isn’t agile an umbrella term for a group of methodologies?
Any implementation of a new methodology for a recovery will be like this—a partial implementation to use the best features.
Since there are an infinite number of opportunities for delay, estimates should be slightly skewed (five to ten percent) to account for common cause variation. To handle special cause risk (someone stealing the quarter, etc.), a buffer must be placed at end of the project or at the end of a sequence of tasks feeding the critical path.
After compiling the schedule, a resource leveled critical path is determined. This is the critical chain. This path drives the project. The tasks constituting the critical chain are analyzed to determine what other paths feed them. Each feeding path has a buffer of time added to the end where it merges with the critical chain and its tasks are scheduled using an as-late-as-possible (ALAP) constraint. This creates a just-in-time (JIT) schedule—with a little buffer. The buffer cushions the critical chain from the effects of unknown issues arising in the feeding path.
Buffers are initially estimated at 40 to 50 percent of the duration preceding them. The result is a 20 to 30 percent reduction in total project duration.
This simple diagram shows how multitasking is a poor concept.
Andrew Doran
This is fantastic!
If bottlenecked resources are working on tasks other than a critical chain task, it is the same as the entire project being idle.
Because critical chain allows individual project tasks to be late, track project deviation by monitoring buffer reductions throughout the project. Consuming a buffer too quickly indicates it is time to take corrective action.
I suggested that project starts be staggered to one every month and, after a year, the resources would be more naturally leveled.
Andrew Doran
Useful.
mixing critical chain into an agile project does not make sense, but the converse does.
Instead of spending $120,000 on a resource who can do the task, $80,000 is spent on a resource who will make the project four months late and cost the company an additional $800,000.
Because removal of scope creep affects the customer negatively and the supplier positively, the negotiation process may frustrate the customer by seeming to be one sided.
The supplier’s failure does not allow for renegotiation of the price.
Having a thorough comprehension of the contract, SOW, and all change orders is critical. People will try to negotiate on this, but it is the immutable baseline.
Table 14-1 shows general wish list categories by stakeholder group. In general, this matrix is ranked by importance. The people who are more important to please are near the top.
Table 14-1 shows general wish list categories by stakeholder group. In general, this matrix is ranked by importance. The people who are more important to please are near the top.
A recovery manager’s best defense in this portion of the negotiation is a thorough and in-depth knowledge of the contract, SOW, and change orders.
Only implement justifiable processes. Regardless of the organization’s policies, all processes must provide a benefit to the project. Document the reasons for excluding any organizational processes.
The recovery manager must tailor a story to show cause and effect of the failure and their relevance to the recovery steps. (Refer to Table 14-4 for a complete outline.)
One risk must always be present in the risk register—missing a root cause.
Customers, however, are keen to slip in additional bug fixes throughout the project. A good project manager handles this through the change management process until the project is so close to completion that fixing bugs adds too much risk to the project.
Treat a recovered project like a new project to ensure old habits are removed.
The team should have an opportunity to celebrate its success. Many people may feel it is hypocritical to celebrate a failed project, but the failed project was the old project.
A customer that feels it has forfeited too much during the negotiation may put extra pressure on the guilt-ridden project team to add items back into scope and perform little favors. This is the primary reason the negotiation must be perceived as fair.
project recoveries usually take from three weeks to six months to plan and significantly longer to implement.
The contract may differ significantly from the proposal. However, the proposal is widely disseminated among members of the group, while the contract, because of commercial terms, is more restricted.
Andrew Doran
This is an excellent point.
SOW
Andrew Doran
Statement of work.
State what is being provided and refrain from listing out-of-scope items, which are, in reality, infinite.
Proposal and project charters usually omit the WBS component; however, it is essential because it outlines the required work and responsible parties. It also sets expectations on the steps required, deliverables, mid-project approvals, and team relationships.
All change requests (regardless of whether they are technical) should be approved by the architect to ensure the impact has been properly assessed.
Most project managers have a poor understanding of how to quantify risk or how risk analysis can benefit the project.
Andrew Doran
I’ve found this to be true. Risk management is critical.
projects, by definition, create a unique product.
Andrew Doran
I don’t agree with this. Surely projects can execute a plan to create another copy of something that already exists. My understanding is that to fit the definition of a project the endeavour only has to be temporary and have a defined end point.
The sources of risks are wide and varied. They can be beyond the project’s control (common cause risk), or within its control (special cause risk).
An example of common cause variation is the normal variation in time required to complete a task.
If the project allows it, establish a line item contingency fund based on the estimated costs. When a risk occurs, ask for those funds. This will properly account for the contingency.
The project is on schedule until the expected completion date is greater than the most likely date plus the anticipated delay.
refuse to quantify unquantifiable risks.
Attributes of individual risk elements that are the intuitive feel of the project manager and the team are no more than guesses. If there is no way to make a traceable estimate, classify the risk as unquantifiable.
In the initial review, the project manager and project sponsor (or other change review group) will reject change requests they determine have an excessive impact on the project without presenting an offsetting and immediate benefit.
Andrew Doran
Great idea.
It's very amusing that ebooks contain content like this.