The Taroko Philosophy
Most of the popular project management tools in use on major projects are highly specialized and heavily siloed. They do not talk to one another and therefore cannot give a complete picture. For example a requirements management system that is not interconnected with the document management system will soon be out of date and therefore lack credibility. Adding to this problem is the fact that most of these tools cannot be easily customised to match the specific project processes.
So after years of frustration working with “standard” industry tools the Taroko founders decided to start making their own. These tools included document management, systems engineering, configuration control, requirements management and most importantly, the relationship between them. Over the past 20 years while working on major projects around the world, a suite of project management tools has evolved which work seamlessly together.
This set of integrated project management tools is called Sigma.
Many branches of Sigma have been implemented on major projects around the world. Each project, while starting from a Taroko baseline, has essentially its own new instance of Sigma.
The starting baseline release for most of Taroko projects is maintained by Taroko Systems International (TSI). The TSI release is known as Sigma-TSI.
Project Management Through Data Management
The Problem - A Data Mountain
A modern engineering project generates vast amounts of data. In order to manage effectively and facilitate intelligent decision making, the data must be brought under control.
Many projects fail to meet objectives because the information driving the project is not properly managed, is inaccessible, incomplete or inaccurate.
The data mountain can be quite overwhelming. For example a typical large infrastructure Project may generate:
• 10,000 contract requirements (which can change!)
• 80,000 letters & transmittals
• 100,000 document/drawings/revisions
• 250,000 derived requirements & Control measures
• 100,000 test items
• 250,000 emails
• >1million files on project servers
Everything is Connected
In addition to being an overwhelming volume of information, the data sets do not exist in isolation. A change in one can affect the state of the others.
For example,
• A SCADA alarm point is defined by a requirement
• Which lives in a document,
• Whose status is determined by transmittals
• The SCADA alarm point is also a test item
• The test item is based on other requirements
• The tested item is a particular piece of hardware
• The hardware is running a particular version of software
• The software is part of an overall system configuration
• The SCADA alarm point is also and Interface
• And so on…
Given the interconnected nature of project information a set of spreadsheets or stand alone databases cannot provide clear visibility of the state of your project.
