First Data reported a common theme in interviews with project staff “was that both Rocky King and Carolyn Lawson were perceived as supremely confident. The interviews also confirmed that the overly optimistic schedule/scope projections were based on continued trust in Oracle and the HIX-IT leadership (Rocky King, Carolyn Lawson, and Bruce Goldberg), despite repeatedly missed deadlines.” Only very late in the process, in August and September, did any of these leaders acknowledge that the initial launch of the website on Oct. 1 would be incomplete, serving only insurance agents and other intermediaries. Even then, they characterized it as a “staged rollout” of a project that was essentially still on track. Oregon Health Insurance Exchange Failure: Blame Runs Deep, March 21, 2014, InformationWeek HealthCare.
Yes, the product manager said, the last phase of the project was incrementally rolling out updates to our new product on this new product line. Yes, this is how we planned it. Yes, everyone should be doing it this way.
The product manager sent me a link to his project manager’s Microsoft Project Plan. I was told that I should use this plan to structure my own plan to do the same thing with our product. What the product owner didn’t realize is that his project manager had archived all the changes to the project plan. Yes, I could see the latest plan and how it showed they were only taking about 12 months to roll out a new product where the rest of us took about 18 months.
However, the archived plans were more interesting. I went back to the earlier plans and made some discoveries. The original plan was for 12 months, but that was about 18 months ago now. With each update of the plan, the milestones were pushed out as they were not being met. Pretty soon there was nothing but unspecified functionality deliveries every few weeks aligned with test resources. The “front end” of the updated plans were changed to look like the functionality that was only now being completed was completed earlier and they were just in a final debugging phase. In fact they were often finally finishing up software that was needed earlier but was still incomplete. Their plan was not a plan. It was just a document that looked like it could be their plan and filled in as a cover for the chaos that was going on behind the curtains.
See also Chaos report.
We too often see assertions of things going well, even as we clearly see evidence that they are not going well at all. We don’t want to believe that we have a failure in the making, so we are more than happy to hear someone else claim that all is well. Once we blow past the final completion date we often hear optimistically how it will just be “just one more week.” Of course since completion is still months away then every individual issue that exists is the “reason” we are not done and we can always find someone or some team that owns that issue and point to them as the problem. See, they say, it is not my fault. My plan was perfect. It is just all those people doing the work that keep making mistakes!
See Its the Project Schedule Stupid
Often those folks “happy talking” are our senior staff. They clearly know what they are doing because, well, they got promoted or hired to their positions. They have to be competent and have to know what is really going on, don’t they? No, unfortunately. As I use to say in the Air Force, if something has gone wrong, and we only put our “best and brightest in command” then clearly the problem will be with one of our best and brightest. That statement always startled people because everyone just knew that it is the individual workers who make all the mistakes, not management!
To see why, Successful Managers without Successful projects.
If we are not achieving our plan, and we need to constantly update it, then the odds are we’ve either over-detailed the plan or else we are simply not going to make it. I recall when a corporate VP, when we reported that we would be late and needed to officially slip the schedule, just told us to “keep going, we’ll see what happens.” We of course delivered late (we always delivered late).
We, and senior managers, must have the data and evidence to demonstrate that we are on track. Just listening to the talk and the excuses doesn’t constitute a plan or valid status. The only successful senior managers I’ve seen doing this “happy talk” are the ones that jump ship and move to another job on the strength of their claimed great but incomplete project that ultimately fails.
Is your status based upon objective evidence or laced with happy talk to cover the growing crisis?