As I mulled over the history of the project I realized that the process we went through was not specific to building SQL*LIMS templates. The process is applicable to the building of any system with multiple resources concurrently working on individual deliverables that make up the entire project. The following five items made up our process:

Generic Procedure
A procedure was developed that generically described the building process. This procedure gave each member of the team the exact steps that should be performed. Each team member always knew the next step to be completed and therefore could mange their own time and schedule accordingly. A clear path to project completion was outlined so that following the completion of a deliverable each resource knew the next deliverable they were responsible for. For this project we did not assign specific deliverables, but classes of deliverables and allowed each resource to chose their own deliverable from the class they had been assigned.

Alignment to a Standard
A standard was created prior to the project kickoff. This standard was explained during the team training so that each member completely understood how the inputs were used in the final product. Even though each deliverable would be unique, they had to align to the generic standard that was created. This standard could be used by each team member as a sanity check for initial questions about their assignments.

Collaboration Tool
A collaboration tool is essential. This tool allows each team member to remain connected to the development progress of the system and visualize how their deliverables are contributing to the end system. A collaboration tool is also pivotal in remaining agile through the course of development. Through the use of consistent communication techniques and a single repository for all project related materials, each team member can be responsible for remaining connected to the project and standards during the creation of their deliverables. The collaboration tool of choice at J & R is Groove. We used Groove on this project to track the development of the deliverables, which allowed for every member of the team to receive in real-time the progress of the project.

Peer Review
As each deliverable was developed we required a peer review by another member of the team that was performing the same tasks. This process helped the project on many dimensions. First, it allowed us to catch mistakes very early in the process. Second, it naturally created alignment to the standard because any differences were discussed between the developers. Third, it created a community of peer reliance; members of the team would ask questions of each other before involving management. For this project we only required a single person to perform the review due to the type of deliverable. However, for more complicated deliverables or for reviews of written code, this peer review should be expanded to the "team". The scope of this team may vary, but it should consist of as many developers as possible and at least one representative from management.

Elevation Protocols
When peer reviews produced questions without a clear answer provided in the standard or when a unique situation was required by a certain deliverable, the development team would raise the concern to management. These questions were created in the collaboration tool so that other members of the team or management could post responses that were visible to the entire team. This created an additional place for developers to look for answers and allowed for the question to only be answered once.

Through the implementation and fine-tuning of these processes, we were able to create many deliverables that aligned to the customer’s expected quality of the deliverables. As we move on to future projects we will continue to modify each of the procedures to gain the highest efficiency; but, the goal of each processes will remain the same.