The Trade off Prism and Cue Factor – Impact of Concurrent Object Oriented Engineering

The trade off prism
An automation project as is the case with any other project is about schedule, budget and functionality, i.e. the trade off prism. As you increase the features in the application, timeline and money suffer, reduce the timeline, and money and features suffer, decrease the budget and both timeline and features would suffer.

Mythical Man Months
Closely related with the tradeoff prism is the concept of Mythical Man Months. Just like the trade off prism, the concept of mythical man months applies to any project as well.
The relationship between the total number of person hours needed to complete a job, and the total number of resources that have been actually deployed on the project is not a linear one. As you increase the resources deployed, their cumulative efficiency decreases with the cue factor coming into place. The cue factor is an empirical relationship that takes into account inefficiencies that a team of individuals working together are bound to have.
Th = Tp x Wh x (1+α)

Where:
Th = total time taken to complete the project in man hours
Tp = Total resources employed on the project
Wh = The total number of work hours available per resource -assuming time given by each resource is constant
α = Cue Factor, an empirical relationship calculated by the diversity in the group (D), no. of people in the group (N), no. of years they have known each other (B) and independence of one team member’s work to the rest of the team (µ).

α = N x B x D / µ

Project managers world over are faced with the challenge of fighting with α. As team dynamics become more coherent, α comes closer to 0, newer and bigger teams with increased social diversity tend to have α as high as 20. Evidently, as you increase µ, α is bound to decrease in value.

µ is measured as follows:

µ = ∑ µ i

where i is the total number of team indiviuals

As µ approaches ∞, α approaches 1 and the concept of Mythical Man Months converts to 100% team efficiency.

Concurrent Engineering and µ
The task at hand for any project manager now is to bring µ to as high a value as possible. There are two ways to increase, each having a profound impact on the value of µ independently and jointly.

- The total number of engineers that are working on the project
- The dependence that each engineer’s work has on the rest of the project

Effectively, if the project tasks are broken down into basic building blocks, such that each engineer works in his own area, having little or no impact on the work of the rest of the team, µ approaches ∞ and α approaches 1. What this also means is that the size of the team can be increased to theoretical limits as well i.e. ∞. Of course there are budgetary and other constraints that affect the size of the team that can be deployed at a project any given time.

But the question is, how do you divide a project into granular segments, and then rejoin it into separate projects to ensure that no one engineer has any impact on the work any other member of the team. The answer simply lies in concurrent engineering.

You breakup the entire project into its basic brick size, and then put together separate work areas for every engineer, each resource has his or her own access area into the project environment, where they enter, do their engineering, and leave, not even considering what the others are doing.

The catch then would be accumulating the entire broken up project! well, not unless, the breakup process was a purely virtual one, and in effect, the entire project resided on a central location, and only access areas were demarcating the engineers. With the application residing on a central server, and the engineers accessing it through their thin clients, working within their own secure engineering areas, the project was actually never broken into pieces at all!

Concurrent Remote Engineering in a Flat World
In a flat world, businesses bring in the most efficient resources at a central virtual work location, and they carry out their business. Whether it be outsourcing tax returns calculation to Bangalore, or selling credit cards from Hanoi. The same applies to automation project engineering. Imagine if you had the best of the engineers working together on the same server, sitting any where in the world.

With concurrent remote engineering, project managers the world over have experienced a 25% decrease in their overall effective engineering time, that’s α brought to exactly zero.

This is what the project managers and engineers working on the OGDCL Uch Gas field experienced first hand. Upgrading a legacy automation software system to SENSYS’ IntelliMAX (http://www.sensys.com/) they made complete use of an object oriented concurrent remote engineering environment.

Multiple engineers were working, based out of different locations, on the same project, and were able to engineer and commission a complete plant in less than two weeks. Almost half the time that the initial project management team had envisioned
The engineering team was comprised of eight engineers working concurrently on the project from Houston, Uch and Lahore.

The initial project specifications did not include configuring the advanced historian DataMAX in the application, however, when the Project Manager, H Tariq observed the team being ahead of plan, and under budget, he decided to include this facet of the project in the delivered application.

With the job completed 30% under budget, and with features over those originally agreed with the customer, the impact of concurrent remote engineering on the trade off prism and the cue factor was deeply felt in saved time and money.