4

Consider the following scenario, which is straight out of a PMP exam prep book:

The project manager of a large software implementation project just finished a project status meeting. In the meeting, he learned that a crucial piece of the software his team was creating is faulty. The news will cause the project to be late by at least one month and will likely cost additional fees for the developers' time. What is the next step the project manager should take?

  1. Fire the project team member responsible for the mistake.
  2. Create a change request for the immediate correction to the software.
  3. Complete a root-cause analysis to determine why the problem occurred.
  4. Present the news to management and the customer with a solution to resolve the problem.

My first instinct is that the "next step" should be #3, preform a root-cause analysis. However, the exam prep book states the following:

Number 4 is correct. The project manager needs to share the news with management and the customers with a solution to fix the problem. The project manager should never go to management with a problem without a solution.

Number 3 is incorrect. Root-cause analysis can be helpful, but it should be completed after informing both management and the customer.

I'm having trouble understanding their line of reasoning, and my question is two-fold:

  1. In a real-world life environment (not the PMP exam), would it really be appropriate to come up with a solution before doing root-cause analysis? And if so, how are you supposed to determine a solution, if you haven't even figured out the root-cause of the problem?
  2. Even on the PMP exam, is what the book is presenting accurate? How can the PMP exam authors consider you able to present a solution if you haven't done a root-cause analysis?
Improve this question

4 Answers 4

Reset to default
3

It's a PMP test question. The answers are not always logical nor based in reality. With this question, #3 and #4 are likely happening simultaneously. In fact, a solution may not be present without the RCA being completed; however, the solution provided to management may include an RCA being conducted and completed. So what PMI is looking for here is early communication to the people who need to be informed.

But you need to remember it's PMI's view of the world. Even the statement that a PM should never go to management without a solution is bogus. Because the alternative to that is to keep things hidden while you are hunting for a solution and that itself could create a disaster.

Improve this answer
1
  • +1. Nailed it. Extrapolating real world behaviours from arbitrary test questions will not provide the answers to real world issues. The world does not behave as the methodologies and idealized responses would have us believe. And that statement about always having a solution is very very bad news indeed, in the real world.
    – Marv Mills
    Dec 21, 2015 at 9:45
4

The root-cause analysis is not the only problem solving method, and the solution process may include root-cause analysis or other methods. So, a solution idea can be found using any method. That's why accepting the problem and starting to solve the problem, and coming with a solution idea to the stakeholders is the accepted answer.

Root-cause analysis is utilized in order to find direct and indirect (obvious and not so obvious) causes for the fault-error. Many times, you find an underlying problem to be fixed which is not related to the technical problem directly. For example a person working under pressure for a too long time, a personal problem that inhibits two teams agree on the validity of an assumption (that fails in the end), a personnel change that causes the next guy to misinterpret a specification or requirement. Root cause analysis may show non-product related matters like these. And these matters need to be solved, however the project schedule is more interested in solving the technical software problem, not the organizational ones. Therefore, the project manager must first get the technical solution process going, and in parallel or right after getting the teams to the job, he could start an investigation via a root cause analysis.

Improve this answer
2

In a real-world life environment (not the PMP exam), would it really be appropriate to come up with a solution before doing root-cause analysis?

Yes. Because the customer is interested in a solution, while you are interested in a root cause analysis.

And if so, how are you supposed to determine a solution, if you haven't even figured out the root-cause of the problem?

The solution is pretty direct. Lets say you have an architectural problem with your software and feature 09 of 12 cannot be built that way. To repair the structural deficits and implement feature 09 your developers estimate 2 months of unplanned work. That is your solution. The two months of unplanned work.

The root cause, why there was an architectural problem with the software, has little to do with the solution. Maybe there weren't enough reviews. Or the requirements changed. Or the architect was not as good as you thought. But finding out why it came to the problem is in your best interest, so it does not happen again. The customer, waiting for feature 09, could really do without this. The customer only needs the solution.

Even on the PMP exam, is what the book is presenting accurate? How can the PMP exam authors consider you able to present a solution if you haven't done a root-cause analysis?

Absolutely. The solution is not based on the root cause analysis. Think of a broken tool. The obvious solution is to buy a new one. It does not matter how it broke. Now for the tool owner, to not buy a new one daily, a root cause analysis is important. But the solution to buy a new tool stays the same, no matter what the root cause was.

Improve this answer
1

It seems that an initial problem evaluation took place already. Otherwise one could not say something about the dealy.

Due to the fact that a crutial part of the software is affected, the stakeholder will probably have a high interest in the topic.

Fore sure, you habe to assure that a similar problem will not occur anymore (at least reduce the likelihood).

So, reasonable steps are:

  1. Notice the problem (done)
  2. Evaluate the impact (qualitativ, done)
  3. If obvious, identify a problem solving strategy (done)
  4. Depending on the identified impact: Inform stakeholders. "We habe a problem and try to figure out cause and solution. First analysis came up with... delay, ..."
  5. Analyse & work on the problem, incl. CR, root cause analysis, work arounds
  6. Keep stakeholders updated
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.