Fixing—or Not—Healthcare Dot Gov

Did you see Dwayne Phillips' post today, Adding People to a Late Project? Dwayne says:

Adding people to a late project only makes it later. We have known this for decades.

Especially in the article he refers to, it seems as if there might be no end to the number of people added.

Did anyone ask the people on the project if they needed more people? Maybe they needed to know which requirement is top on the list. Maybe they needed acceptance criteria for each feature. Maybe they needed each feature to stay put for more than a nanosecond. There is more than enough blame to go around for this particular project. Most of the blame has nothing to do with the developers and testers.

Now, if they had asked me what I would do, here is my plan.

  1. What is the most important thing people need to do to sign up for health care? Get a cross-functional team to work on that, get it to done, and make sure it works. Use reviews, acceptance criteria, release criteria, whatever it takes to finish the work. Timebox that work to one week. Make sure you have performance tests. Roll it out. (Oh, do not let people work overtime. Make sure they can keep to a sustainable pace.)
  2. What's the next most important thing? Do that in the second week.
  3. What's the third most important thing? Do that in the third week.
  4. Now you have a shot of understanding the architectural needs. Go fix the underlying architecture. Make sure you have unit tests, integration tests, database tests, performance tests, and oh yes, system tests. But the tests that are key are underneath the GUI. They will tell you more than any GUI-based tests. Yes, you must test the GUI too. But the under-the-GUI tests will tell you the performance.
  5. While you are fixing the architecture in week four, if you have enough people, you set a group of people to fixing the overall performance. I suspect if you fix the architecture, you fix the performance. If not, you buy enough server capacity to fix performance.

I don't know the culture of the project. I don't know how many people are on this team. Is it a program or a project? Did they have silos to start? Did they think they could use waterfall?

I empathize with the technical people on the project. They were and are the victims of poor project management decisions and poor management decisions. On the other hand, they could have coded defensively with many tests. Maybe they did. They could have tested defensively with many automated tests. Maybe they did. In that case, they are ready for this phase, the “other 90% of the project.” Because they are deep into the 90% Schedule Game.

I bet these people are smart enough to work themselves out of this, by using timeboxes. The question is this: Are the managers smart enough to let them?

9 thoughts on “Fixing—or Not—Healthcare Dot Gov”

  1. If I were a betting man, my money would be on … well, there really is no winner in this situation. We all lose and there are so many factors that have contributed to it. The developers and testers are not to blame but I can’t imagine that they’re totally blameless either. Theirs, however, is more of a guilt by association and perhaps some of what Uncle Bob says is carelessness. I hate to point out the elephant in the room but I’m sure that some level of incompetence had to have contributed to this mess as well. With 50+ contractors (I assume these are companies and not individuals), $300M+, and “oversight” from a government agency and pressure from no less than the office of the POTUS, there is really nothing surprising about the outcome. It’s just a plain and simple, good old-fashioned embarrassment of a failure on arguably the biggest and grandest scale that you could imagine. To put it more bluntly, it’s one colossal cluster f*. And the representatives of the contractors who testified in the hearings today still displayed the ever-present, reality-denying, hope-springs-eternal optimism by claiming that will be ready by January. Yeah, right. Don’t hold your breath.

  2. Wait, I take some of that back. I’d bet my money on the lawyers — they’re going to have a field day with this, laughing all the way to the bank.

    1. Junilu, I fear you are correct. The lawyers will win.

      Programs, large projects, are hard. To do them in waterfall? Madness. This is one of the reasons I recommend you have deliverables every month with a large program, and “finish” it with releases of some sort every six months. That’s not always possible. But if you aim for six months, you might make nine months in a waterfall environment.

  3. Pingback: Five Blogs – 25 October 2013 | 5blogs

  4. I agree with everything said in the article. Of course, we all know Brooks’ Law, but most people have never heard of it. Rather, they follow a practice well defined by Jerry Weinberg, “When something isn’t working, do more of it.”

    It is my understanding that the people developing the website never looked at the long running and successful Massachusetts website with similar functionality. They also never consulted with the many people building state websites, most of which are working quite well. The “not invented here” syndrome is another common problem. I will bet that the awarding of the contract to build the site was made largely by political considerations.

  5. Pingback: New PM Articles for the Week of October 21 – 27 | The Practicing IT Project ManagerThe Practicing IT Project Manager

  6. Pingback: Why Do We Estimate, Anyway?

  7. Sam Pakenham-Walsh

    Now we have the 5&-ers who bought “substandard” policies that’ll be illegal in 2014. So D.C. knows what’s best for us?
    Simple solution: legalize those “substandard” policies so that the administration can keep its promise: IF YOU LIKE YOUR PRESENT POLICY YOU CAN CONTINUE IT. Ask me another…

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: