To Do 2.0

I never really used Outlook’s To Do list. I tried a couple of times, but it became overwhelming and there was not enough functionality to assign deadlines, add notes and stratify tasks. So, I managed my To Do list in my Inbox and in my mind.Remember The Milk Logo

After a number of positive comments rememberthemilk.com (or rmilk.com for short) I decided t try managing my life online. So far so good. This web 2.0 application is proving to be have enough boost of functionality to make it worthwhile. I am almost always wired, so I use it in my browser. There is a BlackBerry sync, but I have not tried that.

I will let you know if I stick with it.

CPOE Update

Leapfrog has released a CPOE test. This does not appear to be the tool that Leapfrog promised in 2001. The tool was supposed to be developed by FCG. There is no mention of FCG (or their new owner, CSC) in the press release.

In 2008 Leapfrog won’t be releasing the results. However, the hospitals will need to pass the test in order to claim that they have fully implemented the CPOE leap. I am predicting this will be delayed. But, I am a skeptic. Perhaps I should not be. There has been a lot of positive progress at the Leapfrog Group in the short time since Leah Binder took office in March 2008. We are finally moving the CPOE leap from an honor system. That is to be applauded.

It will be interesting to see the impact on the total number of hospitals making the leap. If the test is added to the 2009 CPOE leap requirement I suspect we will see a decline of hospitals meeting that standard.

In January 2006 I counted 63 hospitals claiming to have made the CPOE leap and another 58 claiming to be within 12 months of that goal. This month I count 144 hospitals claiming CPOE implementations that meet Leapfrog definition. I will let you decide if that is good progress or not. Anecdotally, the three in my area that said they were 12 months away at the start of 2006 are still not claiming the leap. One is still 12 months away and the other two are now claiming to be in the planning stages. I guess that is the nature of an honor reporting system that has no real incentives.

I wish Leapfrog were doing more to publish an analysis of their surveys. I had to add up 50 different separate queries to do this math. There are still a lot of questions. What percent of hospitals submit a survey? What percent of those are claiming full implementation of CPOE and other leaps? Which software vendors are supporting CPOE? When I have spare time I will do some more investigation.

The Value of the Pre-Wire

When I was with APM I learned the phrase “pre-wire.”  A pre-wire is simply the meeting before the meeting.  As consultants it was important to share the meeting agenda with the customer and be aware of any concerns that they may have.  As a manager I still find pre-wires important.  For example, we always review the IT Steering Committee agenda with the chairperson a few days in advance of the meeting.  The better prepared I am for the pre-wire the better the Steering Committee meeting will go.

Whenever you are trying to get approval for an important decision it is always a good idea to have pre-wire meetings with all of the major decision-makers.  Often, just taking the time to meet with meeting attendees in advance is enough to make them sympathetic to your position.  A good manager will know the outcome before the meeting ever starts.

Killing Projects – Embrace The Concept

My recent post on project failure was one of my all-time favorites. While I wrote about failure from the top of my head, the reader comments were really well considered. Between my thoughts and the reader observations I think we have a great summary of the main reasons IT projects fail. I plan to turn that into a presentation.

Taken by tstadler and shared via FlickrOf course you do not want projects to fail. The preferred alternative is success. But there is a 3rd option, if a project is clearly not meeting your expectations you should kill it. Wayward projects are those suffering from cost and schedule overruns; are clearly going to require more resources than planned; and/or are not going to meet the original expected benefits.

Our organization has learned to embrace killing projects. And I think it is very healthy. In the recent Baseline Magazine, there is an excellent article on Project Lust. The story quotes Michael Krigsman, CEO of Asuret, a project-management consultancy: “It’s very common to see both IT and the line-of-business folks become enamored with a project and continue, blinded by the risks, when a third-party objective participant would say that there is failure coming down the line out there”

I believe project lust is common in most corporate cultures. The result is throwing good money after bad. At Ministry our IT Steering Committee congratulates business leaders that have the insight to see when something will not meet the planned expectations and having the courage to kill the project.

Every year we refine our project to discipline to better ensure success. But we are still a long way from perfect. Bad IT projects are still a fact of life. Killing them preserves your resources for the good stuff. I would encourage IT and organizational leaders to let embrace the idea of killing projects as something much better than failure.

The starting point for all of this is having the discipline to determine the success (or failure) of each project. If everything completed is considered a success, then there is no reason to stop.

If you are not killing a project or two each year you are going to suffer more failures.

Thanks to tstadler for making the picture available via flickr us Creative Commons Licensing.