Project Planning Is A Must As Healthcare Website Shows

By Author: Seth Weedin
Total Articles: 2
Comment this article

We have all watched as the details of the massive failure that HealthCare.gov became emerged. The details provided some good lessons on how not to do things. First of all, there was no plan was in place from the beginning. Code was being rewritten over and over to meet last-minute changes from the government and other contractors. Testing was carried out by the government and not private consultants with more expertise. The list starts there and then just goes on and on.

Developers on the project knew weeks ahead of time that the website was not going to be ready. The website was extremely complex, having to connect to several other systems to have information verified. Many developers said the warning signs were very apparent early on of not making the deadline.

One of the best things we can do when looking at projects like this is study and learn from them. In this case, it’s apparent that a lackluster plan was in place.

No matter what the scenario is when building software, project planning has to take place to provide a roadmap. If your team is entirely in-house working side-by-side or collaborating ...
... online from different locations, it needs some direction. While there is no way to know for sure, it appears HealthCare.gov didn’t have that.

There are a few initial steps in the project planning process that can be performed to get your team started down the right path. There are many other things to consider, especially in a project the size of this, but performing Requirements analysis is a good starting point.

Requirements Analysis

Requirements analysis to a software development project is like blue prints to a house. In the project planning stage, they form the framework for the ‘what’, ‘when’, and ‘who’ of your development project. Requirements analysis gets everyone on the same page and marching in the same direction.

The requirements start out with wire-frames and use-cases. These outline ‘what’ will be developed in both a graphical and textual manner.

- Wire-frames – A wire-frame is a visual representation of every screen and control in your application. It depicts all controls on each and every screen, and indicates the flow your users take through the application.

The purpose of the wire-frame is two-fold for project planning. First, it is very useful for the product owner to create wire-frames to truly understand what he must build to address his business goals. Often during the wire-framing process, valuable discoveries about the business model are uncovered. Every product owner must take the time to wire-frame his application to gain insight in what he wants, and doesn’t want, to build.

The second purpose of the wire-frame is to get everyone on the same page as to what is being developed. Even if every stake holder (project managers, architects, developers, designers, etc.) think they know what’s to be built, a visual depiction immediately clears-up any vagueness. As the saying goes, “A picture is worth a thousand words.”

- Use Cases – Wire-frames are the graphical representation of your application, and if “a picture is worth a thousand words”, then use-cases are the thousand words. A use-case describes the wire-frame. The purpose of a use-case is to make crystal clear the purpose of each and every control on a screen.

During project planning, wire-frames and use-cases go together like a hand and glove. They are synergistic in nature, and complement each other. The combination of the two definitively drives home what needs to be built to your customers and stakeholders alike.

Obviously performing requirements analysis is only a part of the project planning process. With the health care website being an estimated $70 million (a conservative number) project, the requirements analysis go much further beyond what you read here. But for a starting point in most software development project, it’s a good practice to make a habit.

Project planning for software development is not meant to be a document that has to be followed precisely. It’s simply provides a roadmap to start the project team on the right path, which then can be deviated from as requirements change. An Agile approach to development still works wonderfully with this type of planning approach.

What planning procedures do you put in place when preparing for a new software project? Hopefully not the same approach as HealthCare.gov.

Article Source: Spotlight Software