Weekly Feature
As project management consultants to Owners, Developers, Architects and Engineering firms, Contractors, and Subcontractors, we have clearly seen the value of having these members of the project function in a true team relationship. Someone has to make this "Team" Structure come into being and provide the leadership to keep it functioning effectively. This someone should be the Developer. (Hereafter, the term Owner/Developer will be used to denote both the Owner functioning as his own Developer and the Developer with an Owner client). If the Owner/Developer fails to create and manage a team approach to the project, he is passing up his best means of having a truly successful project outcome. That is not to say that the project will not be completed or even that it won’t make a profit. But what is lost is almost certainly many times more than it would have cost to provide strong leadership in team building and team management. When discussing various elements of the Owner/Developer-led team approach with Owner/Developers, it is obvious that many of them are staking their project outcomes on misconceptions of what really happens on their projects. These misconceptions surface in comments such as the one below and others that we will focus on in the coming weeks. While no one of these positions is fatal, each is an indication of a weakness in that Owner/ Developer’s approach to project management. Most of them represent an effort to avoid exercising managerial control in the expectation that some other party will protect the Owner/Developer’s interest better than he can himself. We might as well send the rabbits to bring in the lettuce. When the following comment is heard, you can expect that project success is at risk.......
The traditional organizational tree diagram does not really work very well even in a single organization to define operational relationships. For a multi-firm organization, it is even less useful. A big step forward in improving on the structuring of the project team is the Linear Responsibility Matrix. This fairly simple device provides a row on the matrix for each repetitive function, such as Process Pay Request or Issue Revised Drawing and each activity which cuts across firm lines. Each position represented on the project team is given a column on the matrix. The cell at the intersection of a row (function) and column (position) is coded according to the involvement of that position in the carrying out of that function. Codes may be as extensive as desired, with such possibilities as: A typical Linear Responsibility Matrix will have 10 - 20 codes developed. Such a device allows the project team to document all relationships which it decides are necessary to its effective operation. Some organizations set up the LRM as completely as possible in advance and modify it as experience dictates. This is a considerable effort but one which many users feel is well worth the price. Other organizations set up the LRM with positions and codes, but fill in functions or activities and the appropriate coding only as organizational problems arise and solutions are developed. For an Owner/Developer who is interested but wishes to test the LRM first, this latter method provides an inexpensive trial run. The Owner/Developer who relies solely on contract language to define project team organization is assuring himself of paying a disorganization penalty. Regardless of the methodology adopted, time spent on detailing the relationships among the team members is highly likely to be cost effective.
Next Week's Red-Flag Comment: “It is the Architect’s Responsibility To See That The Project Is Carried Out In A Timely Manner.”
Last Week:
[ Cascad-e
| Staff | Services | Feedback
| About Davis ] |
|||||||||||||||||
Contracts are a necessary evil, necessary but not sufficient to define project team organization. Contracts are
pairwise, adversarial, somewhat negative starting points for building team relationships. What the Owner/Developer is really doing is building a one-time organization made up of diverse firms with quite different internal management policies and procedures. He is asking that this organization function as if it were a single experienced firm operating under a single, well-defined, management system. It is no wonder that so many communication and coordination problems occur in every development project.
