What is the difference between manufacturing IT and manufacturing automobiles (or any other product for that matter)?



Purpose of this paper and the associated presentation for the PMI Global Congress, 2003-Europe, is to illustrate that there are many places to find successful approaches to managing IT in non-IT related industries. In the attempt to manage an Enterprise IT environment for a global client, there are many PMI approaches that have been applied incorrectly, resulting in excessive costs and less control. On the other hand, when they are applied correctly, it produces significant accuracies and efficiencies.

This presentation will focus on three areas, the lessons learned from the car manufacturing industry, how strict application of the PMI structure produces a too “project centric” environment and how the right blend of PMI structures produce a “configuration management centric” environment.

The first part of the presentation addresses the maturity level of Information Technology within organizations today. This analogy compares a manufacturing industry to a technical industry (usually considered a service industry). In reality - both scenarios have a product – car or technology. Enterprise IT management is relatively young compared to other corporate functions such as security, finance, manufacturing, marketing and therefore has not matured to the same level. The lack of organizational maturity for managing IT environments creates security, reliability and configuration problems within corporations. These problems lead to productivity and efficiency issues, including project overruns, project cancellations, unmanageable risk, and tremendous waste.


This presentation is intended for IT professionals who recognize their existing symptoms and problems but are in need of an approach to eliminate them. The presentation is non-technical and very down to earth and easy to understand. It will explain in day-to-day examples and terms the key issues in global IT project management. The ideal audience would be executive project steering committee members, project sponsors, project managers, and everyone that has ever been involved with a large project (i.e. multi year, multi lingual, multi country). People should attend this session to obtain insights and ideas for overall better Enterprise IT Management. The authors of this paper and presentation have 70+ years of hands-on IT experience with small, medium and global corporations. Our goal for this presentation is for you to be able to:

  • See the value of converting from a project centric approach to a configuration management approach in managing your IT environment.
  • Experience how manufacturing best practices can be applied to the management of IT.
  • Obtain an understanding of the components required to manage an enterprise effectively and understand its complexity.
  • Obtain an understanding of how to properly apply the PMI Practices and PMBOK® elements.
  • See how a configuration management approach can be used to migrate from a functional organizational model to a balanced matrix model as described in PMBOK®.

How did we get here?

Historically, many organizations designed, implemented, and managed their own office computing environment. Originally, these environments were small, addressed departmental or local needs, and deployed no mission-critical systems. Most organizations focused on making their local platform work reliably, and individuals often provided support services to their departments in addition to their other responsibilities. Management of the environment was generally performed at a local or departmental level. (Sometimes there was no management at all.) The environment grew over time, resulting in a proliferation of equipment and leading to escalating costs and unplanned pockets of non-productive technology.

Today's Enterprise IT environment includes multi-vendor platforms that are far more complex than traditional mainframe platforms. Different hardware vendors supply workstations and servers. For each hardware component, different vendors supply different add-on equipment (e.g., smartcards, I/O boards, memory chips, hard drives, CD-ROM drives, tape backup devices, etc.). Likewise, other vendors supply workstation and server operating systems. Within the realm of these operating systems, separate third-party vendors may supply software such as tape backup systems, server management software, drivers, and so forth. Finally, yet other vendors may provide application software packages for word processing, spreadsheets, database, fax, presentations, and mail functions. Indeed, this situation is complex and costly.

Further complicating these issues is that fact that businesses have been demanding more value from their IT services while flattening organizations and asking employees to accept more responsibility. Some business managers believe that IT computing brings value by providing a level of user functionality and ease of use not found in legacy mainframe systems. The issues that concern these managers revolve around which enterprise business processes can be implemented in an Enterprise IT environment, and when. Supporting this trend, many IT providers are moving mission-critical systems from traditional mainframe and mid-range platforms to networked microcomputer environments.

However, viewed from an enterprise perspective, the target microcomputer environments are in disarray. As the desktop environment evolved, there was no single point of responsibility for planning or operating the environment, and no assurance of stability or consistency. Many organizations have no enterprise-wide mechanism for setting business direction and justifying costs. Rarely does business planning set and communicate a firm direction for IT providers. More typically, IT service providers, each with their own agenda, heavily influence the business direction of their client organizations. The result is confusion and contradictory objectives and implementations. In this situation, no one knows or understands the total IT cost for a networked microcomputer environment. More specifically, without business planning and direction, IT providers consistently find themselves responding to the current “hot” problem. There is no plan or consistent direction. Overall expenditure frustrates business management because there is little or no perceived value returned. As a result, the environment is out of control, with many IT providers in continuous reaction mode. The lack of a uniform environment coupled with little or no enterprise-wide business direction and cost justification makes successful deployment of enterprise-wide applications problematic.

A Systems Life Cycle Example: The Automotive Industry

Organizing the tasks to design, manufacture, and assemble the more than 10,000 parts that make up a motor vehicle is probably the greatest challenge in manufacturing an automobile. Yet this process is the one least understood and appreciated by the outside world. In addition to designing and building the vehicle, automobile manufacturers must address delivery, servicing, managing supplier relations, and responding to the needs of vehicle owners. A brief review of the history of motor vehicle manufacturing provides insight into the principles of managing Enterprise IT environments.

The first principle addresses the evolution of automobile production classes of environment. This evolution started initially with tinkers and inventors, who struggled to move from innovative ideas to concrete products. Those products did not always work as planned, but eventually controlled internal combustion became reality.

A stable craft production system rapidly emerged to produce the automobile. A small team of craftsmen hand-crafted each vehicle one at a time based on the requirements of the buyer. Although some vehicles looked similar, closer inspection showed that each vehicle was unique. The combination of technology and the craftsman production process severely limited the number and repeatability of vehicles produced.

More consistent production began when Henry Ford overcame the problems inherent in craft production. Ford recognized that the key to faster production was standard, interchangeable parts. Assembly of those parts in a simple fashion by unskilled workers at a speed controlled by an assembly line offered great production potential. Alfred Sloan continued the evolution within General Motors. To run a multi-divisional company, he created decentralized divisions, each with specific products targeted at different markets and managed by financial performance. Sloan also secured a stable source of funding. The manufacturing innovations of Ford and Sloan led to mass production of large numbers of identical vehicles in a short period of time. Mass production is now evolving into the optimizing class of lean production, which includes organizing, planning, integrating, and communicating across all manufacturing aspects, from design to courting owner loyalty.

The second principle, matrix management, addresses all aspects of vehicle production, selling, and servicing. As vehicle manufacturers move toward lean production, they understand the need for focused leadership, communication, and teamwork. Providing dynamic work teams with specialized skills on the plant floor is vital. Empowering teams and organizations with responsibility for finding manufacturing improvements, lowering costs, and fixing problems contributes as well. Directive leadership, communicating throughout the organization, establishes unity of purpose. Together these elements address the critical essence of successful vehicle manufacturing.

A third principle, infrastructure, segments the world of automobile manufacturing into manageable portions. One segment focuses on the technology, or parts, of a vehicle. Those 10,000 or so parts often combine into subassemblies that must quickly and easily fit together on the assembly line. The many subassemblies forming the underlying systems of the vehicle often require complex servicing and repair. Developing and providing the servicing equipment, procedures, and personnel with the corresponding training is a complex process. (e.g. to replace sparkplug number 2 in the 1961 Pontiac Bonneville you had to jack up the car and squeeze through the wheel well). Therefore, a second segment centers on supporting, or servicing, the vehicle to keep it operating within design specifications. A third infrastructure segment addresses vehicle pricing, purchasing, financing, warranties, and meeting owner needs. Detailed planning and execution create and maintain the processes supporting this third set of elements. Combining all of these infrastructure segments for a specific model year means “freezing” their values (e.g., a particular vehicle for a given model year has a specific engine displacement, there is a documented and repeatable process for servicing the transmission, and there are specific financing programs in place to support owner purchasing).

The fourth principle, stages of production, underlies the processes for designing, developing, building, distributing, selling, and servicing vehicles. This principle has four phases: planning, integration, deployment, and operations. During the planning phase, major stakeholders discuss and decide the strategic targets for the vehicle. Integration involves agreeing upon the specific designs for all of the categories that meet the strategic targets for stakeholder areas. Design includes building and testing the initial concept and prototypes, along with creating the plans and procedures for manufacturing, servicing, delivering, promoting, and selling the vehicle. Deployment concentrates on the preparation of facilities and supply chains to begin the manufacturing process. This includes all activities from final assembly to dealing with all of the providers throughout the supplier network. Finally, operations focuses on manufacturing, delivering, selling, and servicing the vehicle. For the established life of this vehicle, these stages are repeated for each model year.

The cyclical nature of establishing strategic targets for a vehicle by model year requires discipline. To produce quality products at competitive prices, automobile manufacturers have adopted a philosophy of release management, which allows for the production of new, more appealing vehicles and fixing problems that arise in existing models. Release management is the fifth principle that brings stages of production, infrastructure, matrix management, and the lean production class of environment together for continued automobile manufacturing success.

This brief overview presented the framework upon which automobile manufacturing orchestrates its processes. It enables the control and coordination of hundreds of engineers, purchasers, suppliers, assemblers, dealers, and financial analysts to plan, produce, deliver, sell, and service motor vehicles. All of these principles also apply to Enterprise IT computing.

Application of PMI principles to Enterprise IT Management

This section will address each of the three principles from the automobile discussion, (in reverse order: stages of production, infrastructure, matrix management) and apply them to the IT environment.

Stages of Production. When managing any type of change to an IT environment, there are general phases or stages that are utilized by most corporations, this is also referred to as Release Management. These 4 phases are usually 1) Planning, 2) Design/Test, 3) Deployment and 4) Operations / Production Support. PMBOK® demonstrated that projects can be organized into five groups consisting of: Initiating, Planning, Executing, Controlling and Closing. The challenge for a project manager, implementing an IT project, is to synchronize these two suggested phased approaches. Since a project has a definitive start and end, many project managers map the PMBOK® processes directly across the entire four stages of the release.


In completing such a mapping, the project Work Breakdown Structure will list all of the project management related activities, but all of the other IT related release activities such as Proof of Concept, Model Office, Deployment strategies, Integration Testing, Network Engineering, and Procurement will be difficult to map. Instead of mapping PMBOK® processes in a single layer, each stage of the release should be viewed as separate projects. In doing this mapping, each phase of the release will contain the project management essentials, and will manage all of the other IT related activities.


By breaking the project management process into the stages, the project manager can also include the specific IT activities into each stage and this will allow for Roll Wave Planning. As we will discuss in the next section, when managing a change to the Enterprise IT environment, that contains thousands of individual components, not all of the impacts of that change will be understood or initially planned. Each stage of the release has the potential to uncover more impacts as they are discovered during designing the components, testing the components and deploying the components. When impacts to new components are realized, that may have a significant impact to the scope of the project.

Infrastructure. When we mention that a company takes a “project centric” approach to project management, they usually follow a project management approach for planning, designing, and deploying all required modifications, on a project-by-project bases. Large companies have sometimes over 400 IT related projects going on at one time. To keep any of these projects coordinated is a task by itself, let alone trying to manage integration points between them. Project Offices, Program Offices and Enterprise Program Offices have been established to help define, track and oversee all of these hundreds of projects. While incremental value is being realized, the efficiencies of the Project Management approach and Program office are not being demonstrated. When referring to the automobile, all of the components to the car are known and managed. Each system (i.e. fuel system) and each component of the system (i.e. fuel pump relay) are tracked and under strict version control (even during the development cycle). If the organization managing the enterprise IT environment does not have the same understanding of the components that need to be managed, there is no mechanism to complete a significant number of functions, such as:

  • Version control over each component
  • Assigned ownership and stewardship of each component
  • Impact analysis of a change to existing, defined versions of each component
  • Means to track what level of component design is installed at each site
  • Generation of a forecast of releases based on vendor activity (i.e. planned hardware obsolescence)

With a large number of projects, the lowest common denominator (what they all have in common) is the make-up of the IT infrastructure. Also stated in the auto analogy, this infrastructure is not only the technology (hardware, applications, routers, servers) but also the business components (service level agreements, contracts, IT direction, financials) and the support components (change management, problem management, configuration management).

A company that takes a “configuration management” centric approach to IT management is one that understands all of the components, and manages the releases of those components. With the components managed, projects simply turn into a focus of altering the IT infrastructure, not re-inventing it. Projects are basically updated versions of each of the components, re-designed to meet a specific business need. As the impacts to the projects are understood, all of the impacted components are bundled together into a single release, which means that they are designed, tested and deployed as a group and not individually. The benefits to the organization to manage five major bundles of releases or 400 individual projects are quite significant. Understand the cost of doing something five or 400 times, such as testing, deploying client approvals. The users are better managed since a schedule of releases can be defined by quarter, or month and the users will know when to expect the updates instead of having to react to the latest individual project.

Matrix Management. With the “project centric” view each project incorporates a project team of individuals to design, test and deploy. These teams usually come out of a functional organizational model, where the engineers are grouped, process development teams, human resource capabilities, etc. As stated in the PMBOK®, there is limited value in executing such a structure. The goal is to assist the organization in transitioning from the functional to a matrixed (i.e. weak, balanced, strong) organizational structure. One approach for this transformation is to map the capabilities to both the infrastructure breakdown along with mapping the capabilities to the release management phases (activities). This ensures that your governance model is integrated with what is being managed (infrastructure) and how you are managing releases (release management). Having a single release management own the “project management” responsibly from planning though deployment and mapping the team by the WBS of release management and the ownership of the components will result in a balance matrix model. This can also be achieved without undergoing a reorganization, but by applying the teams into a different framework.


Studies indicate that nearly 70 percent of major IT projects fail to meet significant user expectations, are late, or are over budget. Up-front reconciliation of objectives, scope, deadlines, expectations, budgets and responsibilities emerge as significant issues. A primary mistake made by project managers is to charge ahead with a new technology without reconciling these key issues.

Managing Enterprise IT environments correctly allows an organization to harvest years of practical experience and proven performance into focus. This type of framework helps organizations visualize patterns, recognize trends, and influence the direction of technology, allowing customers and IT providers to see how all the pieces fit together. It becomes the basis for establishing plans, strategies, responsibilities, and authority. For IT service providers and integrators, it is a vehicle to provide seamless enterprise IT solutions to global customers.


Gartner Group, Inc (1995). Client/Server vs. Mainframe/Terminal Cost: The Analysis. Dec, May 04,.

Ingram, T. (1995). How is a Client/Server Project like heart disease?, PM Network. May

Massachusetts Institute of Technology's International Motor Vehicle Program. (1991). The Machine that Changed the World. New York: Harper Perennial. p. 138.

About the Authors

Cor Knijnenburg is the President and CEO of Core Consulting LLC, based in Plano, Texas, USA. He currently provides leadership and expertise to companies and government entities on Enterprise IT Management, Strategic IT Planning and Enterprise IT Architectures. He has run large and complex projects like the creation of the Operations Support Strategy for New York City and other cultural diverse global projects for clients like General Motors, Xerox, Heineken, Philips, and Levi Strauss. His multi-cultural experience and background, allowed him to co-author a Release Management Methodology that has been used to build several large data centers around the world. He has spoken for Microsoft, and is on the SMU COX School of Business MBA Associate Board. He also serves as the Assistant VP of Marketing for the Fort Worth PMI Chapter. Cor earned his Bachelor of Science in Electrical Engineering with a minor in Computer Science in The Hague, The Netherlands. ([email protected])

Mike Minor is the VP of Consulting Services for Clinecta LLC, based in Sterling Heights, MI, USA. He is currently leading the development of an innovative approach to eLearning and collaborative communications. Mike is a certified FAST Session Leader and has an ITIL Foundation Certificate in IT Service Management. He earned Bachelor of Science and Master of Science degrees in Electrical Engineering from the University of New Hampshire. ([email protected])

Doug Bolzman is an Enterprise IT Management Consultant in Troy, Michigan, USA. As a Consultant Architect, Doug focuses on managing all aspects of IT environments. He improves IT productivity by advising clients and developing strategies that merge IT to business needs, creating deployment methods and establishing operational environment. Doug has a Bachelor of Science degree in Electronic Engineering Technology from DeVry Institute of Technology, earned the Project Management Professional (PMP) certification and attained ITIL Foundations certification. ([email protected])



Related Content

  • Project Management Journal

    Mixed-Methods Research for Project Management Journal® member content locked

    By Jiang, James | Klein, Gary | Müller, Ralf We continue our series of editorials providing guidance for future submissions to Project Management Journal® (PMJ).

  • Project Management Journal

    Using Social Media in Project Management member content locked

    By Ram, Jiwat | Titarenko This article offers some significant insights on the challenges of using social media in project management, using survey responses from 167 managerial and senior-level staff to an open-ended…

  • Project Management Journal

    Explaining Reverse Outcome Tight Control member content locked

    By Chen, Wenxin | Huang Chua, Cecil eng | Young, Raymond | Xu, Xudong Using the lens of mindfulness, our case study of a construction project reveals why mindless enactment of controls leads to reverse outcome tight control—controllers replace project feedback with…

  • Project Management Journal

    Servant Leadership and Project Success member content locked

    By Nauman, Shazia | Musawir, Ata Ul | Malik, Sania Zahra | Munir, Hina Employing self-determination and social identification theories, we examined how servant leadership, which focuses on employees’ needs, influences project success.

  • Project Management Journal

    Seven Decades of Project Portfolio Management Research (1950–2019) and Perspectives for the Future member content locked

    By Hansen, Lars Kristian | Svejvig, Per We evaluate what has already happened in the field of project portfolio management (PPM) and what will most likely shape the future.