With the fiasco of the HealthCare.gov launch, this article was going to be a condemnation of the testing (or lack of) effort. However, the more I thought about it, the more it became evident that no amount of testing would have corrected the lack of project and program management (PM). Having been through several implementations of large scale projects, this had all of the characteristics of PM failure. When screens take minutes to load, where were the stats from the tests that showed average load time for each web page? When data was not displayed correctly, where were the QA testing results detailing that informaton? When information was entered and then could not be re-displayed on the screen, where were the results from the test scenarios? The list goes on…
When people think of project managers; they think of the people who create the Project Management charts detailing the tasks to be done, start and end dates, critical paths, etc. They meet with management detailing whether the project is progressing according to the time line and where the risks and issues are. However, good project management means more than that. Good / great PMs will gather information from all of the various parts of the project, assimilate that information, and then determine where the jeopardies and issues lie. While not needing to understand the logic at the component level, a PM must be able to assess whether the milestones have been “fully” met (and not “yeah we finished that piece”). Judging from the issues surrounding the Feds and other notable states website launches, the lack of this expertise is showing in the rollouts of these applications.
Who should manage these huge projects? It is plainly obvious that this function needs to reside outside of the agency that has requested the software be built. In speaking with some collegues who work with government agencies, a large focus is on the documentation of the process and functions, which can be to the detriment of getting the actual process built. Project management need to temper these tasks with their reviews against the application building and testing. With multiple vendors, there should be a PM from each vendor and then a PM outside of the vendors to provide unbiased assessment of all entities. Other factors, such as “scope creep” and “nice to haves”, need to be prioritized and managed based on necessity and criticality. Code can be re-written and/or revised to correct the issues, but bad or none existent project management can doom a project from the start.
