• The project manager must understand "how things work" within the company. It's not impossible for competent project managers to lose their jobs or become pariahs within a company, for doing what they thought was right.
• Project requirements must be laid out -- they must also be measurable and understandable to all.
• All departments must define their scope of work.
• Each department must indicate what information it needs from all other departments, and what impacts will result from delays.
• The project manager must produce an information model that shows how everything fits together, and how everyone on the team will find out what they need to know.

Outsourcing design functions is a means many companies use to distance themselves from the responsibility for this level of organization. The design shop needs documentation of what's been agreed to in order to be paid for the work.

The project manager shows everyone on the team what is to be done, who is to do it, and what resources are available to work with. This is not the project manager trying to get people to do something. Most often everyone will do what needs to be done if given the opportunity, authority and resources. Instead the project manager provides an infrastructure.

Tools for the information model can include

• Gantt charts (report project status and milestones)
• PERT charts (report project critical path, e.g. via Microsoft Project)
• schedules
• lists
• meeting minutes
• drawings and sketches
• Quality Function Deployment (QFD) matrices (and the "House of Quality")

The last tool above can very likely benefit team members (more so than the others), because of its graphic nature and comparison of options. Whatever tools are used must be accurate, comprehensive, informative and accessible; it must also allow for contributions from all disciplines. Many project teams use Web sites for this purpose.

A dynamic information model that includes all of the above ingredients, and which allows team members to contribute what they have when they have it, will serve as an improvement over a "traditional model" of project reporting, which includes written reports at regular intervals.

There are people who are good in the early phases of a project, and there are others who are better toward the end. (Two different personalities.) Can you identify which is which and plan accordingly?

• The front-end person can recognize which specs are important, and which can be ignored, but can become less motivated when the problems are solved.
• The back-end person has no patience with the organization of the work, but can sweat details once the work is organized.

Your staff may lose focus after a couple of months on a given project. You can make it easier on them by planning for milestones at intervals of a week or two.

Team members will become discouraged if

• responsibilities are not clearly laid out
• information they need isn't available
• they are expected to make up for schedule delays for which they weren't responsible
• last-minute problems, even if they don't have to solve the problems
• they feel they won't be recognized (and rewarded) for outstanding performance, especially when in the light of some of the above issues
• they feel others who work less hard and/or impede progress ARE rewarded

When the schedule slips, that ground must be made up before the next milestone. Your records may help you get what you need to make that happen. If, for instance, you have ISO 900X certification, that can empower designers to "lock in" a design from changes.

Design changes may be due to cutting corners in the early design phase. Everyone on the team, and all liaisons with other organizations, must be aware of the cost of a change once the project moves beyond early design. In the case of repeat offenders, inform them with a "bill" showing the monetary cost of a modification.

Commitment to a final design must first come from the highest levels in the organization. Only senior management can compel sales, marketing, legal, etc. to allow for a lock-in. When you have this commitment in place, then all department heads must agree to any proposed change, otherwise the set project schedule will stand.

When the design is locked in,

• Any proposed changes must go through the project manager.
• No change may be adopted without the concurrence of the project manager and senior management. (Even if the project manager wants the change, those in authority must still approve implementation.)
• No new work can begin without full availability of information.
• The costs of changes must be assigned to the requesting organization.

You have to be aware of budget constraints, as you can guess, but you also have to recognize typical overcompensation for budget constraints:

• "It's better to have it and not need it than to need it and not have it." This philosophy causes managers to buy expensive items they might need -- instead of planning for real needs.
• "The early bird catches ALL." This philosophy is based on project managers learning the ways that line managers commit their budgets. Once a project manager has failed to get funding by waiting on a request, the next request will be earlier. And probably larger.
• "Windfalls are for immediate use." Any unexpected budget money must be committed to something on the project before it disappears.

Implementing QA programs, hiring consultants, etc. is ineffective in improving project flow and funding unless those at the top are committed to implementation or any proposed fix.

ISO 900X certification means that your core processes are documented, and that you have corrective methods in place if anyone fails to follow the documented procedures. This fails if

• the documented procedures aren't the ones actually followed (and the ones followed are worse)
• the documented procedures are never streamlined to provide a corporate advantage (those documents are the most important ingredient for process improvement!)
• improved processes are never documented, showing everyone on the team the "best way" to get the job done

References

a simple introduction to Gantt charts
a simple introduction to QFD
Kerzner, H. Project Management: a System Approach to Planning, Scheduling and Controlling.. John Wiley & Sons, 2000. ISBN 0-47139-342-8