Enterprise-Wide Project Management

Published in TDAN.com January 2002

Why Project Management is Important

Project Management is important because almost all enterprises suffer from one or more of the following problems:

• Inaccurate estimates
• Conflicting priorities among projects
• Inability to deal with varying levels of work conditions, staff skills, and the like
• No intra- and inter-project reporting

Simply put, a common lament is that while there are projects everywhere, the ability to effectively manage these projects on an individual or enterprise-wide basis is nowhere.

For example, studies by have shown that many, if not most, knowledge worker projects exhibit these characteristics: over budget, under specified, delivered late, and fail to meet organizational
expectations. While not all reasons for failure can be laid at the foot of project management, too many can. Among the underlying reasons are invalid work plans, insufficient time for requirements
changes, and inexperienced or mis-allocated staff resources.

The United States Government’ General Accounting Office (GAO) has been studying IT projects for a number of years, and a review of 10 GAO studies clearly shows that the main reasons why IT
systems fail has nothing to do with IT. Again, while not all reasons are specifically related to project management, some of the reasons have to do with critical components of project management.
And again, these are invalid work plans, insufficient time for requirements changes, and inexperienced or mis-allocated staff resources.

As a consequence of market pressures and corporate mergers, two classes of project management systems remain today:

• PC based or low-end packages
• Server based or high-end packages

PC based project management systems are typified by Microsoft’s Project (www.microsoft.com) or Time Line Solution’s product, Time Line (www.tlsolutions.com). Server based project management systems are typified by Primavera (www.primavera.com) and Welcom
Software (www.welcom.com).

While the high-end packages are designed for very large, complex project’s of thousands of nodes, and while the low-end packages are well suited for scheduling a single project of relatively
simple complexity, both the high end and low end solutions do not really address the problems associated with:

• Disjoint projects
• Management of generally uncontrolled resources
• Repeatability of projects
• Incorporation of learned experience into the project estimation cycle

Many knowledge worker projects involve persons from within different organizations over whose time the project manager may not have direct control. Thus, the best the project manager can do is to
request participation and to create approximate schedules that show deliverables from these non-controlled participants.

If the knowledge worker project manager creates elaborate project schedules based on many layers of intricately crafted activity networks, then while they look magnificent the instant they are
first created, these project plans cannot withstand assaults from all the schedule conflicts. Once these assaults are underway, the project manager has to continuously adjust the layers of project
activity networks, resource estimates, parallel and serial paths, etc. Soon the project manager’s life is consumed by project management rather than project accomplishment.

The dilemma then becomes:

• Accomplish the project, or
• Plan the project’s accomplishment.

All too often, project planning is discarded because the project management system, initially thought to be the savior from chaos actually had become another source of chaos. The castle of project
management becomes the project manager’s dungeon wherein time is the dungeon master, the PERT chart is the shackles, and the schedule is the rack.

To be successful at project management, an approach must:

• Concurrently manage disjoint projects
• Manage generally uncontrolled resources
• Enable maximum re-use of past efforts
• Incorporate learned experiences
• Not require a full-time project planner
• Support what-if resource allocation scenarios
• Enable management to know about and view all projects and resources across the enterprise
• Support the presentation of projects individually, or from the perspective of a business-defined set of priorities

Enterprise-wide Project Management Environment

Enterprise-wide project management is based first and foremost on its database design. The general “life cycle” of enterprise-wide project management is:

• Employ project, deliverable, and task templates to plan projects
• Plan and estimate projects in a gross way and accommodate different work environment factors
• Staff projects and generate schedules
• Record progress towards deliverable accomplishment
• Re-plan projects as needed
• “Learn” from actual durations from accomplished deliverables

Enterprise-wide project management does not, however, support the creation of:

• Very precise parallel and serial networking of projects or tasks
• Very detailed and precise scheduling
• Gantt, PERT or CPM diagram production

These three activities are the proper activities of both low-end and high-end project management systems. In support of these systems, the enterprise-wide project management system generates output
data files that can be input into these systems. These systems can then be used to create very precise schedules, activity diagrams and the like. If accomplishing these three activities were THE
basis for successful project management then there would be no need for enterprise-wide project management. While very precise schedules, activity diagrams and the like are important, it seems
clear that these features have little or nothing to do with project management success.

In contrast, project management success is predicated on different activities, which are:

• Continuous optimization of repeatable projects,
• Accommodation of various work environments and factors within these environments,
• Adjustment of project schedules based on differing staff and skill levels, and
• Capturing actual work accomplishment metrics that support earned value analysis and reporting.

The project management database design has been implemented several times as the basis for project management over the past 10 years. Thus, the “design bugs” are worked out.
Enterprise-wide project management serves the need of the independent project manager who has to accomplish the definition, management and reporting of diverse and possibly disjoint projects with
staff of varying skill levels within mixed work environments that are generally not within direct control. This type of knowledge worker environment is the rule, not the exception.

Enterprise-wide Project Management, A Difference in Kind

A key difference between the enterprise-wide project management approach and others is that this approach concentrates on the management of “nouns” while other project management
approaches focus on the management of “verbs.” Clearly, since there is no one sacred, perfect way to produce a deliverable (i.e., the nouns), if the focus of project management is to
identify and control the “methods” (i.e., the verbs) by which deliverables are produced, then to have enterprise-wide project management and/or to have enterprise-wide metrics, the
enterprise must first carve-into-stone the processes by which work is done. Not only is this impossible, it is highly undesirable. It is impossible because it is inconceivable that there is only
one way to accomplish any product. It is undesirable because it is insulting to project staffs to presume to control their every technique, process and step. Not only can’t it be done, no one
will allow it to be done.

In contrast to managing “verbs,” enterprise-wide project management manages “nouns.” It does this by collecting the quantities of resources expended to produce deliverables.
Project estimates are therefore based on the staff hours required to produce deliverables rather than to accomplish tasks.

This technique enables different styles of project management to be employed or be set one against the other by comparing the resources expended to produce deliverables. There might be one project
template for mainframe development, another for micros, and finally a methodology for web-based systems even though all the deliverables might be essentially the same. Alternatively, there might be
multiple project templates that produce the same set of deliverables to serve the needs of different styles or techniques as might be the case for the data-driven and process driven approaches.

Additionally, the enterprise-wide project management approach enables enterprise-wide project reporting in terms of the cost and effort to produce deliverables versus the accomplishment of
activities. As work techniques improve, either through the increased skill of staff, or through the adoption of different techniques, the efforts remain comparable because it is the quantity of
resources expended to produce the deliverables that are compared rather than the activities, which are no longer able to be compared because they are now different, that produce the deliverables.

To illustrate, when you go into a grocery store and buy an apple, the cost is expressed in terms of the product you are buying, the apple. While you may wonder how much the various activities cost
that ultimately produced the apple, fundamentally, you probably do not care. When you go to five different stores and compare the cost of apples (given a standard for equating quality), again you
are only comparing the cost of the deliverable, the apple. If one store spends 10% for transportation and another spends 8%, you probably don’t care. It’s the final cost of the apple
that matters, nothing else. So also should it be with project management. The only thing that should matter is the final cost of the deliverable. Nothing more, and nothing less.

If however you are a wholesale apple buyer that deals with a co-operative and by contract, you have to pay every apple grower the maximum cost incurred by any one member of the cooperative, then
you have a real incentive to look “behind” the costs of the deliverables (the apples) to find the different underlying processes that make the costs different. Even then, the goal then
is to find the lowest-cost set of activities, and to then highly recommend that set of activities to all members of the cooperative so that your costs for the deliverable–as a
buyer–will go down. So, while there may be an interest in activity-sets, they are not the driving force. So too with enterprise-wide project management wherein the cost of deliverables rather
than the cost of methods is the driving force.

Enterprise-wide project management enables the melding project templates with selected:

• Task templates–that is, the enterprise’s techniques, methods or work breakdown structures that have been proven of the years to accomplish in work the most cost effective manner.
• Deliverable templates–that is, the enterprise’s specifications of and unit effort metrics required to accomplish the components of its Knowledge Worker products.

The resulting Project Templates are then specially tuned into “real” projects by determining the quantity deliverables, and then affecting the resulting “norm” estimates
through:

• Work environment factors–that is, the effects from varied work environments on the creation of deliverables according to certain task templates.
• Staff–that is, the effects from persons and their varying types and degrees of skills on the rate of production of deliverables according to the task templates.

Collectively, these four project management components are an exemplary use of the database fundamental, define once, use many times. This achieves the ability to have maximum reuse with minimum
original, one-off effort.

Architecture and Concept of Operations

Enterprise-wide project management is squarely founded on a database application that captures and manages the data critical to effective project management. The database’s design is depicted
in Figure 1, and consists of a number of entities. All these entities are traditional and are interconnected through one-to-many relationships except for those entities that show a one-to-many
relationship from the entity to itself. Organization (upper right) contains such a relationship. This relationship means that the entity contains subordinate organizations. For example, an
Information Technology organization contains the Information Resource Management organization, which in turn may contain the Data Administration organization, and Database Administration
organization. The eight entities that are recursively related are:

• Contract
• Deliverable
• Deliverable Template
• Organization
• Project Template Type
• Resource
• Task
• Task Template

The entities from Figure 1 are also divided into six distinct clusters, which are:

• Contracts, organizations and contract [staff] resources
• Resource and Resource Life Cycle Node
• Project, Deliverable, and Task Templates
• Project Staff
• Project Building and Estimation
• Project Work

In general, the Contracts, Organizations, and Contract [staff] Resource cluster of entities represent the environment within which projects take place.

The Resource and Resource Life Cycle Node (1) entity represents the target of the project, that is, the area of the business benefitted by the project. For example, for manufacturing, finance,
human resources, or land use planning.

The Projects, Deliverable, and Task Templates entity cluster enables the definition of the templates employed in the actual building of projects. Defined across the enterprise, these templates
enable standard project execution and accomplishment measurement.

The Project Staff entity cluster enables the inclusion of the staff as resources for a contract, and also permit the specification of the specific types and performance ratings of skills that a
person may bring to a specific project.

The Project Building and Estimation entity cluster represents the entities that support building projects. Projects and associated tasks are initially created through the use of the Project
Deliverables, and Tasks Templates. Once projects and associated tasks are created, they are modified by attaching work environment factors and specific skill-level based staff assignments. Only
then can task and project resources be computed.

Finally, as task work is accomplished, the Project Work entity is valued. As actual work is accomplished, it can be reported through any of its related entities.

Because enterprise-wide project management system is implemented as a database application, it supports the following types of reports:

• Projects and project statistics of a certain project template
• Projects and project statistics within certain [business area] resources
• Projects and project statistics by deliverable types
• Projects and project statistics by organizational units
• Projects and project statistics by specific project staff members
• Projects and project statistics by certain types of skills
• Projects and project statistics according to certain status types
• Projects and project statistics according to certain work environment factors

(1) – Resource and resource life cycle node has the exact same definition as it does within the Whitemarsh metabase and also the process of Resource Life Cycle Analysis of Ron Ross.