The impact of too much change is under-estimated. In considering system changes, retain as much as possible things that already work or that can be made to work with only minor "tweaking." Don't make massive changes for only incremental benefits. Familiarity with parts of a process goes a long way to fostering a willingness to work with the parts that are new. The changeover then can be viewed by participants simply as an integration effort rather than a replacement. It's a psychological advantage that shouldn't be under-estimated.
Systems fail to address ease of use in "production mode." Always strive to design new or revised systems to allow users to execute complex commands in simple repeatable ways. For example, if ten reports are printed every month, a user shouldn't have to waste time printing each, but should be able to click a couple of buttons to select and initiate the printing of one, or some, or all of them.
People actually doing the work don't clearly understand who is responsible for what in a given process. Confusion often arises not simply from imprecise definitions in job descriptions but from lack of forethought regarding the details of how a process works. So, clearly define roles and responsibilities in job descriptions, procedures and work practices. You also must carefully think through both the detailed methods and formats to be used in transmitting data among participants, as well as the amount of time realistically required to produce or transmit the data needed.
Procedures are way too high level and obscure in nature, contain more philosophy than content, and rely on a lot of "motherhood" in their description of the work. Mandate that procedures define who does what, in terms of actions and deliverables (such as specific forms, reports, etc.), not just functions to be performed. This includes transmittals, approval, sign-offs, etc. Procedures and work practices must offer clear direction and instructions -- and leave no question about what must be done and how to do it.
Systems and procedures incorporate weaknesses that could have been avoided by tapping the knowledge and experience of people at the working level. Don't let managers design systems on their own. Managers understand needs and strategies, but require input from subordinates who do the work to design systems that actually will work.
Systems are implemented on all projects at once. Too much change causes too much confusion, and everything can fail because of it. Pilot-test production systems or subsystems on no more than a handful of projects first. Trying to deal with masses of data involved in all your projects usually is unmanageable, especially if you find the initial rollout requires design modifications to be made. Why would you want to change the coding, say, for thousands of records on 100 projects when you could have discovered (and fixed) the problem on only one? There's nothing like working with real project data to help you identify the types of "bugs" that might occur in the theoretical design. Gain confidence first and then gear up to migrate all your data.
ACHIEVE BETTER RESULTS
The efficient production of project controls reports isn't the "do all" and "end all" of effective project management. Indeed, how project and corporate management use the data and trends in these reports can make-or-break positive outcomes. So, don't overlook this aspect in evaluating the effectiveness of how projects are managed.
However, shortfalls in the project controls organization itself can severely undermine effective project management. Some sensible strategies can go a long way toward correcting deficiencies and thus improving capital performance.
ROBERT MATHIAS is an executive associate at Pathfinder, LLC, Cherry Hill, NJ. Email him at RMathias@pathfinderinc.com.