4

In one of the projects, we missed analyzing a few things and missed testing a few scenarios. We had separate SA, tech lead, and testing teams. These resulted in production issues.

Although I consider that project success is one of the PM's measurements, is this more of a project management failure?

  • It will be helpful to know your team size and whether you completed the Analysis phase before going into coding. – Ashok Ramachandran Dec 2 '13 at 15:59
  • The team size is 8 (including Testing team) and analysis phase is completed. The analysis is documented, reviewed and approved by all the stake holders of the project. – Sreedhar Nadadur Dec 3 '13 at 5:30
  • "We had seperate SA, tech lead and Testing teams." And there's your sign. – Andrew Clear Dec 3 '13 at 18:56
6

Our inability to be perfect does not constitute failure. There will always be defects in our testing / quality control processes in managing projects and operations. Always.

In fact, it would be a project management failure to stand up a testing capability that costs more than the benefit of the testing itself. At some point, the expected impact value of a defect costs less than the cost of finding it. At that point, you stop testing and go at risk, delivering a less than perfect product but fully prepared to fund the fixes when they're discovered.

  • 1
    "Our inability to be perfect does not constitute failure" - I'm gonna get that laminated and pinned to my desk. This should be enshrined in every PID :) – Marv Mills Dec 3 '13 at 13:25
5

As David says, defects at any and all stages of a delivery process are inevitable. What separates the great PMs from the others is how those defects are handled. I'm not just talking about how they are fixed, but also how they are communicated to the business and other stakeholders, how impacts and expectations are managed. The worst (but easiest) thing a PM can do is to bury the defects in the hope they can be managed away, which never works in the long term. Openness, transparancy, honesty and accountability are the watchwords here. Log all issues and risks, actively manage them and report on them to anyone and everyone who needs to know the situation. Be honest about the expected timescales to resolve and keep everyone informed of the progress towards delivery...

1

While the other answers are good I would just add my perspective.

First, while it is unclear why you are asking this question, if you are asking as part of a post-mortem to see what you can do better next time, then it is good and yes, something clearly went wrong. If you are doing this so that blame can be assigned to the appropriate person then you should avoid this. Blaming rarely does anyone any good. Consider it a learning opportunity for everyone on the team. Blaming introduces fear which leads to (as Marv said) PM's burying the bad stuff (which always causes bigger problems down the road).

Second, problems do happen and (as Marv said quite well) how you react to problems is really what separates the strong PM's from the weak. There is a reason that when planning you should always include contingency time and money...because surprises often happen.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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