I have been asked to help a company review a software project that has been very very painful, putting a lot of strain on the client relationship as well as between individuals as well as teams in the company.

Both based on research I have undertaken previously as well as various blogs I've read on the topic I intend to undertake various stakeholder interviews, attend the project sunset meeting and a sprint retrospective.

I have started conducting causal analysis focussing on:

  • Specification: Quality/ambiguity, scope creep, documentation.
  • Communication: How were individual issues communicated? how well were the project teams included in the planning process? How did the distributed team (5 office locations - 12 people) affect communications.
  • Resourcing and Planning: How well was the project planned in advance, how well were estimates met? Were people available when they were meant to be on the project? Did skills of the people match requirements?
  • Causes of Rework: How well were the individual team members qualified for the tasks they had to repeat? How long did it take for completed tasks to be tested and errors to be identified?
  • Complexity: How complex were the tasks? Eg. was there a need to include an architect to help a developer plan the design?

When conducting a project review are there any additional areas that you think I should be considering? Can you share best practice for soliciting information and communicating my findings in a practical and constructive way?

  • 2
    This could be an excellent question on how to handle "lessons learned" reviews, but as it is written it is asking for somewhat vague opinions and as such is likely to be closed as "opinion polls" are off topic for this site. To avoid closure, and to morph to a great question it would be useful if you would rephrase or rewrite the question so that it is less of an opinion poll and more statement of some specific problems in the area of lessons learned. Hope that helps.
    – Marv Mills
    Nov 10, 2014 at 17:03
  • Agree with Marv. Please edit accordingly or the question risks being closed as opinion poll. Nov 12, 2014 at 0:41
  • I think this would a good question for the site. Nov 27, 2014 at 17:58

1 Answer 1


There are concrete approaches to analyze a troubled project. The best that I have witnessed, being on both sides of the analysis, is an Issue Based Method. You can easily google this method to learn the specifics, but it is essentially a great approach when 1) you do not know what the cause is and 2) you do not know what the solution will be.

The approach causes the examiner to develop a series of possible causes of project poor performance, called hypotheses, around which you would develop your testing approach / questions / areas of research. Most troubled projects are caused by the same things over and over. If you have been asked to study a troubled project, that implies you have experience in these types of projects and in the industry; you ought to be able to name the top ten causes quickly.

I tend to look for the most simplest, easiest, and basic explanations, such as inadequate resources--both human and otherwise--lack of plans, lack of documentation around processes and procedures, lack of policy guidance. Those are my initial hypotheses. Then I go test each and go from there. The basics: everyone knows to do them but they seldom get done.

Good luck.

Your Answer

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

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