IT Projects technically are not complete until decommissioning; however, a main milestone is the initial delivery of the system. So for the purpose of this blog, I will refer to the delivery of the system as the final piece of the project. In order to go from Soup to Nuts during a project, one typically follows a system’s life cycle. Within a system there may exist a number of subsystems that also follow a life cycle. One example of a project within a project, that is near and dear to my heart, is the development of Reports within a LIMS project.

I have been involved in a number of report development projects and unfortunately, I see a lot of mistakes repeated throughout each project. We typically start out defining ALL of the reports for the project, as well as the process that we are going to follow in order to deliver a set number of reports (i.e. 20 reports) with the system. The process then goes something like this:

1) Define Requirements for 20 reports
2) Design all 20 reports
3) Develop all 20 reports
4) Write Test Scripts to test all 20 reports
5) Code review all 20 reports
6) Execute test scripts for all 20 reports
7) Deliver 20 reports to users

If only it were that easy. Typically, there are a number of iterations and changes that come up along the way. These issues also have a tendency to occur at a new process point. For example, when development starts on the 1st report a flaw in the design process is uncovered. This results in moving all 20 reports back to the drawing board. Then when test execution begins, guess what: an issue that was not thought of during the creation of the test scripts is uncovered. And the result, back to the drawing board for all 20 reports. Again.

One thought that I have been trying to perfect is the idea of taking individual reports from Soup to Nuts. Rather than work on 20 reports simultaneously, waiting until the 20th is complete to move to the next stage, why not start off by taking 1 report all the way through the process and verifying an entire report lifecycle. This does not prevent work from commencing on other reports, but it does require the Project Manager to be flexible. The PM has to be able to adjust and reassign resources on the fly in order to complete each report cycle when a report is ready to be moved to the next stage in the process.

The thought of switching resources around on the fly, and not having exact timelines, can be a problem for those who live and die by a Microsoft Project schedule and deadlines. In this world of LIMS reports though, I believe the flexibility will provide a much greater chance of success in the end.