Most of the IT organizations we visit conduct post-implementation reviews once a project has been concluded. This is well and good, but often it does not go far enough.

Projects are learning experiences. Each time you engage in one, you have the opportunity to see what worked, what didn’t; what is superfluous to getting the tasks done and what is essential to their success; how effective your reporting and oversight is; etc. In an ideal world, you would improve steadily, as more projects took place. Sadly, for most organizations, their level of performance hasn’t changed in years in a material way.

What are some of the learning areas worthy of consideration?

1. Estimates: most of the organizations we see are poor at estimation. One IT group had, as a rule of thumb, a standard rule to multiply all estimates by 2.3. This had the advantage of producing estimates that came far closer to the actual events, but did not explain why the estimates were chronically so far off the real world situation.
   
   Learning from estimates, therefore, involves two different things. First, the making of better estimates. We regularly observe that most organizations, for instance, plan with more of the day available than actually occurs. The real work day for a project is now well under 50% of the total time: email, meetings, normal training/vacation/sick day overheads and other work consume the rest.
   
   Few of these organizations have a company-wide scheduling calendar: each project manager works in isolation in building their plan. Neither is this calendar updated daily, so that real world events that “ate time” are factored in.
   
   The other estimating issue that emerges from studying project performance is the lack of performance on the part of one or more areas. For IT people, this is typically the business: too “busy” to test expeditiously and thoroughly, or to sign off on requirements, or even to meet. No decision makers at meetings that require decisions. These, and many other lacunae, eat into project schedules; they are enterprise difficulties and should be brought forward and corrected as the governance problem they are.
   
   

2. Reuse Opportunities: Many of the organizations we visit have reuse policies — and very little reuse actually going on. At the time there are always sufficient reasons offered as to why reuse is not an option “now”. After the project is completed, however, there should be a review of what was delivered and what reuse opportunities were missed.
   
   The practice of getting good reuse — of test scripts, of documents, of designs, of code fragments — comes from learning when and how things could have been reused. If this is never formally studied, the next project manager has nothing to help guide the question of reuse. The studying also raises awareness of the assets (and their quality) at the IT organization’s fingertips.
   
   Leading toward a cultural change such as reuse involves concerted, conscious action — learning action.
   
   

3. Business Cases & Results Obtained: Most of the IT organizations we visit do extensive work to help their clients formulate business cases. Figuring out, after the fact, how closely the case was achieved is an important part of the project’s learning.
   
   For instance, if a systems integrator was used, the business case would have costed the expected billings. What were the actual billings? If they differ by more than a few percent each month, why? Is there something the enterprise needs to learn how to do, either to optimize the use of outside resources or to manage them so that you do not become an “billable hours sink”?
   
   What about slippage? Did the project actually generate a return? If it didn’t, why wasn’t this a steering committee issue? (Most of the people we talk to complain that the steering committee is uninvolved, almost disinterested in their projects. These are business people: give them business problems and their interest will pick up.)
   
   Likewise, how did the change adoption go? Are the functions that were specified being used? (If not, what does this teach you about requirements?)
   
   

The ability to IT to deliver more is grounded in what you take away from the work you’ve done. If you’re not studying your completed projects to learn how to improve, you’re missing a real opportunity to raise your game.