Data Collection and Workflow


In this requirement, the client required to coordinate a number of teams spread around the world working in different time zones. The users (members of the teams) already had a number of tools they used to coordinate parts of their work. The work to be completed had a very complex schedule of processing and delivery. The users used a number of different charts and excel file to help them track the work to be

A lot of the users work involved solving units of work called issues. Issues are passed and modified between users until they are closed. Issues were categorized into issue types each of which had different properties or fields. The users changed the issue types and their properties frequently.

Requirement Overview:

  1. Single window. The application had to be a single window to the existing tools. This was to prevent the users from switching from one tool to another all the time.
  2. Schedule tracking. Track what needed to be done and when.
  3. In-dept reporting. Provide reports on the status of the work going on and forecast future loading.
  4. Handle all aspects of tracking issues.


Our solution involved two modules with a common database. The first was a desktop application which is used to extract information from the other existing tools. This tool is run by only one user to update our application with the information from the other tools. The second tool is a web application. This module is deployed on the internet to allow access to all parties. The first module ran on Microsoft .Net 2.0 and the second module ran on .Net 1.1

The application has a very complex and flexible workflow to coordinate many of the interlinked processes. The workflow used information from the other tools (which was imported by the desktop module). The workflow had a number of time keeping and reminder system to coordinate the teams across the globe. It also reminded teams what was due and when.

The workflow was also equipped with a specialized issue tracking system. Each issue type could be designed into a form. This form was configurable with the type and number of fields. The number of issue types could also be changed. Complete history and issue type access was implemented which controlled which user could view and/or edit issues. Issue types were provided with configurable escalation systems.

The user were able to search through the existing issue database with ease. This prevented duplicate issues. With all the above information now being available, we were we able to offer the managers a vast array of detailed reports. The key component to the success of this tool was the flexibility it offered each team to modify its part of the tool to its particular requirement (flexibility was offered in the issue management and in the workflow)