The conclusion the GAO draws is that the organizational and process decisions made by CMS are still flawed and the problems remain. Ominously, they conclude “[u]nless CMS takes action to improve acquisition oversight, adhere to a structured governance process, and enhance other aspects of contract management, significant risks remain that upcoming open enrollment periods could encounter challenges going forward.” Will the next open enrollment be as disastrous as the first? We’ll know by October. The billion dollar web site you paid for. ZDnet, Aug 13, 2014.
The conclusions always seem to be the same. If we just adhered better to our established rules and regulations all would have been fine. In my 20 years in the government and at being successful at delivering software intensive projects on time and with good quality, if we had stuck to the government’s way of doing business we would not have succeeded. We know because they had not succeeded in the past when doing it their way.
OK, but as the report said, we just need more and better oversight, right? If those folks in government, who are not very good at this kind of thing, just had more information and could micromanage more of the project, then those contractors would have done everything right and everything would have worked out, yes?
No. At least not in my experience. I went through a government conversion where we went from in-house software development to contracting it all out. We did this because we were not very good at delivering projects on time (if at all) and certainly the quality was iffy at best. What happened?
The contracts, managed by the same managers who managed the in-house projects using the government process, delivered their projects late and buggy — if they delivered them at all. Do we see a pattern here? Having been one of those in-house computer programmers, technical leads and then managers, I recall the day — early on in my career — where I just stopped and thought “the problems aren’t technical — its the way we manage!”
So how did we then deliver on time with good quality?
For more details, see Its The Project Management Schedule, Stupid
The first was brutal honesty as to how long the project would take. The length of the project pretty much drove the overall cost. The notion that if we tweaked requirements (take some out, add some in) that it would somehow change the overall length of the project never really worked out that way. We even showed, using past performance data on historical projects, that as we varied requirements (up and down) the overall project duration — if we had it right in the first place — stayed the same.
For more depth, see Eliminate Your Project Management Honesty Buffers
Brutal honesty has the downside that the first reaction to our realistic project plans was “no way!” The reason was always fundamentally “that’s too long and costs too much!” This was even in the context of knowing how long it had taken in past projects and that we never ever requested more time nor more money than any of those past completed projects. Even facing this data, leadership did not want to admit that maybe their “pie in the sky wish” and their “expert management judgement” was pretty much completely wrong. This management push back leads to the 2nd reason we succeeded: I didn’t care.
Compare with Maybe We Should Ignore Our Boss
I didn’t care if what I was proposing helped or hindered my government career — my promotability. I found I had to attack the problem based upon aiming for the project to succeed, rather than worrying if I would personally succeed or fail due to this endeavor. This gave me the ability to stick to my guns, and the data, when the going got tough.
Also consider For Lasting Success Find A Higher Purpose
Now, I wasn’t always falling on my sword to get things my way. I often found I could slip in, through what I called guerrilla management, the things we needed. My best example, on getting the schedule right, was first accepting an unrealistically short schedule and then when the inevitable crisis arose slipping in the longer more accurate schedule as part of the response to the crisis to finally get the schedule in the right ballpark. In a nutshell, I used the inefficiencies of the existing organization to put in place many of the things needed. Things that if I had asked for them upfront would have been disapproved (and they often were).
Similarly, look at Don’t Kill The Golden Goose of Project Management – The Crisis
The solution to most problems is rarely more oversight. If we need more oversight than something has probably been set up wrong in the first place. Doing a good job, a data driven, unemotional job, and being honest about what we can and cannot do is the somewhat simple solution that pretty much always works. Isn’t it nice that simple things are often the project management tools that work?
What techniques have you resorted to to ensure that your projects were successful?