Responsibilities of the Project Controller

The Project Controller (PC) is the third player in the project management triumvirate. The PC has no technical performance responsibilities, focusing instead on schedule, cost, personnel assignment, facilities, and contract liaison issues. Time spent on these matters is estimated as 25% schedule, 45% cost, 10% personnel, 10% facilities, and 10% contract liaison. Cost issues have to do with assuring that the PM and CSE get the cost reports that they need and also that the overall project stays within budgeted costs.

The Project Controller is likely to be the ''keeper'' of the master schedule for the project, although inputs are obviously required from engineering personnel. The PC need not be an engineer, although an understanding of what engineering does is clearly a requirement. Good PCs can anticipate problems by in-depth analyses of project cost and schedule data. By examining trends and timetables, the PC may be able to spot trouble spots before they are evident to other project personnel. This person therefore can be worth his or her weight in gold, primarily to the PM. A brief citation of some of the PC's responsibilities and duties is provided in Exhibit 1.4.

Exhibit 1.4: Ten Responsibilities and Duties of the Project Controller (PC)

1. Maintain overall project schedule

2. Assess project schedule risks

3. Assure validity and timeliness of project cost reports

4. Track special cost items (e.g., travel, subcontractors)

5. Develop project cost trends

6. Assess project cost risks

7. Maintain life-cycle cost model for system

8. Verify and maintain personnel assignments

9. Assure that necessary facilities are available

10. Maintain appropriate liaison with contracts department

1.6 ORGANIZATIONAL ENVIRONMENTS AND FACTORS

There are many who claim that the organizational environment in which a project is performed is the critical factor in the ultimate success or failure of a project [1.14]. This item was alluded to earlier under the topic of ''inferior corporate support.'' We examine this issue here in somewhat greater detail with respect to the particular corporate entities with which the Project Manager (and the Chief Systems Engineer and Project Controller) must interact. Interactions with project staff, in the main, are reserved for the discussions in Chapters 5 and 6.

1.6.1 Corporate Organizational Structures

Although to a large extent a project has a great deal of internal structural coherence, it exists within a given overall corporate organizational structure. That corporate structure, depending on its configuration and processes, can have major impacts on how well a project is able to function.

In general, it can be said that there are three generic types of corporate structures, as illustrated in Figure 1.3: (a) the functional structure, (b) the project structure, and (c) the matrix structure.

As shown in the figure, the functional structure is organized fundamentally by functional areas such as engineering, marketing, sales, manufacturing, production, and so forth. Projects, as such, either for internal or outside customers, are formed within a functional group for the duration of the project and then are dissolved. As projects come and go, the basic functional structure remains. A PM is selected from the functional group that is likely to have the most to do with the project from a functional discipline perspective. Depending upon how high up the PM is in the functional organization, as well as other factors such as the technical scope of work of the project, the PM

Figure 1.3. Corporate organizational structures.

may have to reach across functional lines to access resources for the project. This can work very well because all functional managers are in the same position of requiring resources from other groups from time to time. Projects therefore can do very well in functionally structured organizations, but only if the functional line management is supportive of project needs and requirements.

Figure 1.3 next shows the ''pure'' project structure, in which the entire organization consists of a set of projects. This structure is prevalent in service organizations, and especially in professional services contractors that do work for the federal government. In such cases, each contract tends to establish a project, and projects come and go as the contracts under which they are operating are completed without renewals or further work requirements. The PM usually starts a project with key personnel from a project that is phasing down or being completed. Such an overall corporate orientation is conducive to project autonomy and support because it is its only focus. Projects can flourish in that type of environment, but from time to time, they do not have ready access to specialized expertise that might reside in a functional group.

The third type of overall corporate structure shown in Figure 1.3 is the matrix structure. This might be viewed as a hybrid between the previous two forms, with the coexistence of functional groups together with the formal recognition of a project group. In principle, this structural corporate form can provide an ideal mix of the advantages of both project autonomy and functional expertise. However, real-world pressures and competition between project and functional groups can also yield a nonsupportive environment. Theories aside, much of the success of a matrix structure, in terms experienced by the Project Manager, depends on the quality of corporate management.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment