In my experience, the best way to cement these essentially preventative practices, all of which are quite sound, is to insist that Lessons Learned sessions be held on the heels of any project, successful or not. (Some call these post-mortems, but I prefer to accentuate the positive). Then, it is up to (especially) the CIO and his/her management chain to create appropriate processes, practices, and initiatives that will foster continuous improvement.

I just searched, and to my amazement I’ve never written a blog entry on the importance of “lessons learned” sessions. It’s now on the (long) list of posts to write at http://www.peterkretzman.com. So thanks for that nudge!

In my experience, the best way to cement these essentially preventative practices, all of which are quite sound, is to insist that Lessons Learned sessions be held on the heels of any project, successful or not. (Some call these post-mortems, but I prefer to accentuate the positive). Then, it is up to (especially) the CIO and his/her management chain to create appropriate processes, practices, and initiatives that will foster continuous improvement.

I just searched, and to my amazement I’ve never written a blog entry on the importance of “lessons learned” sessions. It’s now on the (long) list of posts to write at http://www.peterkretzman.com. So thanks for that nudge!

Nice comparison if IT project failure to mountaineering. This did get me to thinking – most CIOs realize the importance of proper planning and governance for IT projects, but may not have the resources to effectively govern these projects. An answer would be to curtail the number of projects, but business needs don’t allow for this. So the next step would be to add resources, but firms likely can’t afford this option. It then becomes a matter of risk management – determining those projects that need more attention than others. To properly do this, becomes a matter of communication with the business owners, and engaging the business in the management of the projects.

Of course, this then creates the discussion of who owns and should thus manage the project, IT or the “business” (I discuss this here: http://itbusinessalignment.wordpress.com/2009/01/20/it-project-or-business-project/ )

When it is truly “life or death” situation, resources and their cost don’t get questions, but when it’s not (as in most IT projects), many will cut corners, taking the chance the project will be successful – in mountaineering, they might say “you got lucky.”

Glenn Whitfield

Nice comparison if IT project failure to mountaineering. This did get me to thinking – most CIOs realize the importance of proper planning and governance for IT projects, but may not have the resources to effectively govern these projects. An answer would be to curtail the number of projects, but business needs don’t allow for this. So the next step would be to add resources, but firms likely can’t afford this option. It then becomes a matter of risk management – determining those projects that need more attention than others. To properly do this, becomes a matter of communication with the business owners, and engaging the business in the management of the projects.

Of course, this then creates the discussion of who owns and should thus manage the project, IT or the “business” (I discuss this here: http://itbusinessalignment.wordpress.com/2009/01/20/it-project-or-business-project/ )

When it is truly “life or death” situation, resources and their cost don’t get questions, but when it’s not (as in most IT projects), many will cut corners, taking the chance the project will be successful – in mountaineering, they might say “you got lucky.”

Glenn Whitfield