A formal project management system ... how is it acquired?

Dennis Bolles, PMP

Developing a formal project management system is an arduous task and at times seems like an exasperating exercise in futility; however, once completed, the benefits received will make the endeavor well worth the effort and time consumed. Implanting MPM (Modern Project Management) methodologies and principles will forever change an organization's traditional mode of operation; it therefore requires management's unequivocal commitment to provide resources, training, and ultimately to have the perseverance that will be needed to see them become fully integrated.

Organizations can readily resolve technology issues by investing in equipment and training. But company culture issues are not so easily changed. Experience indicates that MPM principles will eventually be completely embraced and their values accepted, but not until they become fully integrated. Ideally, incorporating MPM principles would have the same level of priority within a manufacturing organization as achieving ISO 9000 certification or integrating TQM into the culture. If MPM is to function in the capacity that is intended, executives and middle-managers must comprehend that project management is not merely a process, but rather a deliberate employment of principles based on a proven body of knowledge that can help guide them through the concept, development, implementation and final termination phases of any project.

And finally, recognition of the PMP status and acceptance of project management professionals as valued members of the management team by business leaders is highly dependent upon this accomplishment.

How Does One Create a Formal Project Management System?

To ensure success, four phases must be skillfully traversed in the process of creating a formalized project management system within any manufacturing environment:

1. Introduction – top-down support

2. Acceptance – from the bottom up, the way to success

3. Implementation – defining changing roles and responsibilities: functional versus project

4. Integration – creating standardization, a function of the learning organization.

Introduction – Top-Down Support. The first step in gaining endorsement of a proposal of this magnitude is to start at the top. This is particularly true when attempting to introduce to the organization a management concept that is a different and, professed to be, better way of doing business. Such a proposition needs to be proven before being endorsed by most business leaders. Case histories, professional trade magazine articles, personal references, or other similar types of information can support the facts that improved productivity, shortened lead times to market for new products, reduced engineering and manufacturing costs, enhanced management skills, and heightened learning capabilities, are just a few of the benefits acquired when formal project management is an essential part of a business's mode of operation.

Selling upper management on the idea of putting a formal MPM system in place is not as difficult today as it was five to ten years ago. It seems that the benefits associated with project management are understood by more business leaders today. Not withstanding, it is imperative that top management get solidly behind and formally support the effort. Success in achieving acceptance of a formalized MPM system, and realizing the benefits that come with it, is vitally dependent upon this message being heard throughout the organization, and accepted as being sincere. One sure way to give credibility to the management-supports-this-effort message is to provide sufficient financial resources for additional staffing or hiring of professional consultants to develop and document the system's procedures and policies, purchase equipment, obtain training materials, and train staff at all levels. Obtaining top-down support is the first of two critical hurdles that are the primary obstacles that stand in the way of reaching the goal.

Executive management must also come to the realization that the ultimate success or failure of any project is heavily dependent upon the manner in which it has been managed. Management must first acknowledge that project management is a skilled discipline requiring dedicated resources. Successful projects require the leadership of persons trained in the skills of how to manage projects! Unfortunately, the importance of this key aspect seems to elude many companies. Typically, the role of project manager is assigned to someone from the department that controls, or has the greatest vested interest in, the project. The criteria used to select the project leader will vary, but rarely is the selection process based on an evaluation of any specific skills or attributes. More than likely, a formal selection process does not exist.

Selection of the project manager usually follows more of an arbitrary approach, where the choice may be made based on length of service, willingness to serve, positive attitude, or some other such nonqualification-oriented rationale. The job of leading a project team is typically viewed as an additional assignment to be added to the candidate's current workload. Consequently, the attention given and time allocated to the specific task of managing the project is usually proportional to the size of the aspirant's overall workload. Project management is not a part-time job to be filled by whoever is lucky or unlucky enough to be chosen to lead. Project management demands a dedication of the leader's time; it should be the primary responsibility! Project managers should be selected with the same level of care taken when filling any management position, having responsibilities commensurate with the same level of importance.

Attitude change, cultural change, and behavioral change is necessary, and there are no shortcuts to achieving this. It can typically take from three to five years to fully implement a formal MPM system. Therefore, senior managers must work hard over an extended period of time to understand their own attitudes toward implementation of a formal project management system, to change those attitudes if necessary, and (hardest of all) to change their unconscious ways of behaving so that they become effective managers themselves. In order to diffuse these changes downward, they must then spend the time and effort to notice their subordinates' attitudes and actions, and to ask for and expect the kind of attitudes and actions that support the institutionalization of a formal project management system.

Acceptance – From the Bottom Up, the Way to Success. Executive commitment includes the first point above, but goes beyond it. Without a true understanding of the meaning and implications of MPM at the top level, and a firm commitment to make MPM successful, it is difficult if not impossible for MPM to succeed. This commitment means not only assigning sufficient budget and labor to both the technical and human aspects, but also includes a willingness to demonstrate personal commitment by verbalizing their own changed attitudes and behavior, followed by continuous, visible efforts to lead colleagues and subordinates to change their mindsets and habits. These cultural changes do have significant advantages for organizational effectiveness even in a non-MPM environment. For MPM programs, they are not just advantageous, they are necessary.

Work team members and their line managers are typically the people most affected by the creation of a formal MPM system. Some significant work-style changes are introduced and most people will resist change out of hand, especially if the changes affect how they accomplish their work. Ironically, one of the strengths of MPM is in providing skills and tools that can help workers and their managers control undesirable change. Experiencing difficulties brought about by change is a normal part of everyday business. Having the ability to manage and control both planned and unplanned change is a key factor in gaining bottom-up acceptance.

“I don't have time to plan and organize, I just want to concentrate on getting the job done” is one of the most common comments made by those who typically resist MPM practices. People who characteristically do not organize their workload, but tend to fly by the seat of their pants, are usually the most vocal in their resistance to the introduction of modern project management principles. Developing a project plan at the start of a project, establishing a schedule and tracking progress of the activities are basic applications of MPM.

One of the primary reasons people resist and dislike project management is because, while not intentional by design, it tends to accent missed deadlines and highlight any lack of willingness to accept accountability for unkept commitments. No amount of executive-level support or cajoling will force acceptance of a formal MPM system at this level. Not until people are helped to understand how a formal system will benefit them and make their jobs easier is there any likelihood of it succeeding. Gaining full acceptance will take time. Sometimes the most one can hope for is a willingness to be open-minded and agreement to work with instead of against the system. Once everyone's cooperation is forthcoming, the hard part is over and, in comparison, the rest is easy. Without it there is little likelihood of succeeding until this minimum level of acceptance is obtained.

Implementation – Defining Changing Roles and Responsibilities: Functional Versus Project. Most of those who are familiar with the subject of project management know the definition of a project. For those of you who don't, a project can be defined simply as a series of non-repetitive activities occurring within a period of time with a defined start and finish. Working on a project is differentiated from the way we do our “traditional” daily tasks, which is an ongoing process that has repetitive steps and no definable start or finish. Typically, well-trained workers have a clear understanding of their job responsibilities and how their work relates to others in the organization. Typically, companies go to great lengths to provide well-defined job descriptions and work instructions for positions throughout the company. The work process is clearly defined, everyone knows where their work comes from and where it goes when it leaves them. The process and procedures for transferring information between departments is well-documented and understood by all. Everything changes when projects enter this picture. Project roles, responsibilities, processes, and procedures are typically not clearly defined, documentation is often nonexistent. Little wonder the picture starts to get fuzzy and some projects seem to take forever to be completed.

Defining the roles and responsibilities of project team members is a critical part of developing a formal MPM system. People assigned to project teams are out of their natural element, often faced with creating something that does not exist and frequently without instructions on how to start, much less complete, what follows. Creating new products, services, support programs, or whatever it is that constitutes a project, all have one thing in common: project activities follow a logical sequence and accomplishing them typically involves utilizing the specialized skills of people from multiple functional areas of the organization, which is why a project team is formed in the first place. Once people understand their new project-related roles and responsibilities they can then function properly as a team.

Integration – Creating Standardization, a Function of the Learning Organization. A formal MPM system has a foundation of basic principles, and it is upon these proven axioms that the specific instruments that form the standards and guidelines are developed to direct the organization's management of projects. Some organizations choose to develop several MPM guidelines, one for each type of project; Product Engineering, MIS Department, Manufacturing, etc. Departmental projects will typically include many of the same tasks and phases, whereas the details may differ significantly from projects in the other departments.

MPM guidelines define the critical issues; such as, what should be included in each document and its format? who provides the information? how is the information obtained? how is it recorded? who has access to it? and who controls the changes and how they are managed? Functional responsibilities are generally also consistent from one departmental project to another. Therefore, it stands to reason that many of the following MPM system elements can, and should, be standardized.

Project scope definition. Outside of a formalized MPM system a project's scope is customarily expressed in terms of a simple statement or mandate, which may or may not even define the project's goals and objectives. However, a MPM system expands the definition of a project scope by including any significant or formal documents, such as:

  • QFD (Quality Function Deployment) chart
  • Customer need statement
  • Product specification (criteria)
  • Product vocabulary
  • Volume forecast
  • Material/finish specifications
  • Engineering drawings and B.O.M.s
  • Test specification.

Work breakdown structure. Most projects, like new product development, contain many of the same steps and phases; often only a few details will change from one project to another. Therefore, a template for a typical work breakdown structure (WBS) flow diagram can be developed. The flow chart is a simple method used to identify the various project phases and associated tasks in an easy-to-follow format, typically drawn top-down (vertically), similar to an organization chart. The template, when used as a planning tool, can help a project team save a significant amount of development time by modifying this generic model versus creating a WBS for a new project from scratch each time. This is particularly true when project teams are made up of people who lack experience, and it can be a great aid in training.

Network diagram (PERT chart). PERT charts are used primarily to define the relationship between tasks and the order in which they occur during the project life cycle. They are often referred to as bubble diagrams, because project task information such as task name, length of duration, start/end dates and responsibility is enclosed by a box or circle. The boxes are connected with lines and arrows indicating the relationships between the tasks and the order in which they should occur. Most people find certain aspects of this format difficult to interpret, especially on projects with more than 50–60 activities. PERT charts do not delineate task and time relationships very well and there is no way to evaluate the level of an individual task's or project's overall completion status.

The PERT chart is an excellent tool to organize total scope of the project, define precedent/successor relationships of tasks, and determine the length of time needed to complete the total program from start to finish. The project schedule critical path (start to finish line of all connected tasks that do not have float) is also more easily identified in this format. PERT charts are created by drawing them within most PM software applications. There are no quick-and-easy ways to create or make changes in the chart; therefore, creating a template is not recommended, because any time savings gained are generally minimal. Often it is faster to just redraw the chart.

Gantt charts. Creation of a standard Gantt chart template is recommended and the WBS flow diagram template can be used as input. The Gantt chart, frequently referred to as a bar chart, provides an easy-to-understand graphical format that presents how each project task relates to calendar time. Most project schedules are printed using this format. Typically, tasks are organized in chronological order and grouped under summary headings referred to as summary tasks. This format is often used to track a project's progress, because it can display a task's percentage of completion as well as record actual start and completion dates. The “actual or updated” task bars can be placed side by side with the project baseline (original) plan task bars on the same schedule to provide a ready comparison of actual progress versus what was planned. It is important to maintain the original base plan, because the only way to determine where you are, with all the changes in the schedule that will occur, is to know where you started!

Tracking and reporting tools. WBS flow diagrams, Gantt charts and PERT charts are all different formats that use the same information. Each is an important tool that can be used first to develop a project schedule, then track its progress. Periodic (weekly or bi-monthly, in most cases) reporting of progress on all active or schedule tasks is very important. No exception should be allowed for non-compliance with this rule.

Standardization of a project management software package, development of standard formats, and creation of templates that define the way the information is displayed and printed is an important step in developing a systematic set of MPM corporate guidelines. The options and settings used to develop report formats in the PM software's application program, frequency of use, distribution, and maintenance are all issues to be documented and included in the formal MPM system guidelines. Consistency of document design and use is also important when communicating a project's status to management. Interpretation of information can become a point of concern when there is a lack of consistency from one project report to another, much less from one program to another.

Project communications protocols. Managing project communications often presents one of the greatest challenges for the project manager to overcome, while at the same time it can also provide the best means to ensure a project's success. Making sure the latest information is available to the right people at the right time is one of the project manager's most important responsibilities. If decisions are to be made in a timely fashion and be correct, they must be based on accurate up-to-date information. Project information must be readily available and controlled so that its accuracy and current status is beyond question.

Project change control procedures: Managing change is a central aspect of what organized MPM systems provide. The change process is bounded by three distinct states:

  • Beginning with the present, which represents the current status of elements influencing the organization's structure: those that affect its resources (both human and physical) that are used to produce products and services.
  • The next state is what will be in the future: the conditions that will exist at some point in time toward which desired modifications to the current status are targeted.
  • The third state is represented by the process of transition, which can require significant adjustments throughout the organization, leaving few areas untouched.

The criteria for implementation of a formal project management system are essentially the same as for most other planned organizational changes of significance. The formal MPM system will enable the organization to become the master over change rather than the victim.

Project close-out process. Projects evolve through a life cycle, therefore the skills needed to manage them require an ability to adapt as the project advances from concept to development into implementation and finally to the termination phase at project end. Each phase requires a different approach and specific managerial skills. Project managers who are successful are able to shift gears as the project progresses from one phase to the next. The project phasing starts with contemplative analytical evaluations, moves into development of plans for utilization of resources, then into the hands-on phase of tracking progress and problem solving that is part of the implementation phase, and ends in the project wrap-up phase driving the team to finalize activities and bring the project to a successful close.

All too often this final important stage of a project is overlooked or ignored. Sometimes there just isn't enough time between projects, but more often it doesn't happen because there is a lack of understanding or commitment to the importance it has in the overall learning process. Reflecting on what has worked, what does not and why, is a significant characteristic of the learning organization. Improvement comes about from a process of review, to learn from one's mistakes and build upon the successes. Development of consistent formats help clarify what works and what doesn't. Definition and documentation are the foundation of a reliable MPM system. A well planned and fully documented MPM system provides a consistency, which leads to efficiency, resulting from a proficiency of applying well-developed project management skills.


Manufacturing management must first acknowledge that project management is a skilled discipline requiring dedicated resources before a formal project management system can be fully implemented. Given sufficient time, Modern Project Management (MPM) principles can be embedded within every business process, even woven into the fabric of the company's culture. It is only then that MPM values and benefits become truly appreciated and fully accepted by all. img

1. Bing, John. 1994. Principles of Project Management. PM Network (January), pp. 38–41.

2. Boznak, Rudolph G. 1993. MUSUBI: Unlocking the Power of Project Management. PM Network (August), pp. 6–10.

3. Dinsmore, Paul C. 1993. The AMA Handbook of Project Management. AMACOM, a Division of American Management Association.

4. Freedman, George. 1988. The Pursuit of Innovation. AMACOM, a Division of American Management Association.

5. Nunn, Philip. 1995. The Transition to Project Management in Manufacturing. PM Network (January), pp. 7–10.

6. PM 101: The Project Manager – A Leader. 1993. PM Network (December), pp. 28–31.

7. Rausch, Casey. 1993. Teamwork – Is It One Word or Two?: Project Management in a 1990s Matrix team Environment. PM Network (August), pp. 27–29.

8. Skelton, Terrance M. and Hans J. Thamhain. 1994. Concurrent Project Management: A Tool for Technology Transfer, R&D-to-Market. Project Management Journal (December).

9. Thomsett, Michael C. 1990. The Little Black Book of Project Management. AMACOM, a Division of American Management Association.


Dennis Bolles, PMP, recently formed the consulting firm PM Pros after 26 years of providing project management systems development services to companies throughout Michigan. He is VP-Programming for the Western Michigan PMI Chapter.

PM Network • August 1995



Related Content