I recently did an evaluation that made me realize a few things. 1) Project timelines are a type of logic model. After all, they identify program activities and relationships among those activities. 2) Murphy was not quite right. It’s not that anything that can go wrong will, but that some things will go wrong. 3) Things go wrong for different reasons. 4) The reasons things go wrong can provide a lot of useful information about program behavior and outcome. For instance: Did most of the delays come from labor/management conflict, failure to anticipate demands on people’s time, or the demands of a better business climate? Which of these delays were longest, or hardest to resolve? Which affected outcome, budget, or stakeholder expectations? For the important delays, what were the critical incidents that caused the delay? What constellation of small factors combined to cause the delay? I built an entire evaluation around using timelines to answer these kinds of questions.
Lessons Learned: Organizing evaluation around the reasons and consequences of schedule slips provides a lot of useful knowledge that is hard to get by other means.
Rad Resource: I have a blog post that goes into a lot more detail on what I did and how I did it.
Do you have questions, concerns, kudos, or content to extend this aea365 contribution? Please add them in the comments section for this post on the aea365 webpage so that we may enrich our community of practice. Would you like to submit an aea365 Tip? Please send a note of interest to firstname.lastname@example.org . aea365 is sponsored by the American Evaluation Association and provides a Tip-a-Day by and for evaluators.