Project Management Institute

Minnesota Smith and the Temple of Unrealized Dreams

the search for automated, integrated, enterprise-wide project management

img

Harvey A. Levine

The Search for Automated, Integrated, Enterprise-wide Project Management

Writing for PM Network serves many purposes for me. It allows me to stay actively involved with this vital organization, to share my 34 years of project management learning and experience, and to address key issues concerning project management and the use of automated tools.

Best of all, it acts as a catalyst for important research on these issues. In doing my 1994 three-part series on resource scheduling (Resource Leveling and Roulette: Games of Chance), I was forced to learn and test 16 project management software programs, as well as to develop a set of resource scheduling test scripts that I use to this day. More recently, I was moved to make major discoveries about risk analysis and risk analysis software in order to complete my two-part series on risk management (Risk Management for Dummies, Oct ’95 and April ’96).

With this article, I embark on a new adventure. Like an adventurous hero—let's call him Minnesota Smith—I'm not sure where it will take me. It's quite frightening, and I'm probably in over my head. Nevertheless, here I go. The full topic heading is Automated, Integrated, Enterprise-Wide Project Management, but I'll call it EPM for short.

What is EPM? If we were to ask this question of a dozen people, we would probably get more than a dozen answers. It's sort of like asking for a definition of client/server; everyone has their own idea, and some have more than one.

To some extent, EPM is a fantasy. It is that dream of a utopian, all-inclusive system—one that would tie all project-oriented data together in one integrated process. In fact, the true utopian, all-inclusive system would even reach out to include nonproject data. The system would be robust enough to support vast numbers of users and oodles (a highly technical term) of projects. It would be open, yet secure, satisfying the Corporate Information Officer (CIO). On the other hand, it would be so user-friendly that casual, infrequent users, with limited project management and/or computer savvy, would have no difficulty. And, somehow, it would also support the needs of project managers (one hopes).

If this is the dream, what is the reality? Are we chasing after rainbows? Or is a practical EPM just around the corner?

That's what this study is all about. With your help, I intend to observe, analyze, clarify and explain the needs and trends for EPM and their impact on users and developers. The entire project management community is invited to participate in this study. I am particularly looking for input on this subject from users, consultants, and software vendors. Please send me your needs analyses, white papers and such; this will help to define EPM from both points of view: needs and solutions.

Through the PM Network Software Forum I hope to present views of what the users want, what they are now using, what is wrong with what they are now using, and what needs to be done. I also plan to showcase some of these solutions and discuss their advantages and disadvantages.

Project Management Software Trends: I Have Seen the Future and It Is Here

Earlier this year I was invited to make some presentations on “Trends in Project Management Software.” When I searched my crystal ball for advances not yet seen, I chanced to prognosticate about the probability that we would be seeing applications for project management that use hypertext formats for accessing project data.

Well, either my forecasting is getting sluggish or the future is arriving with greater speed. I have already seen such a product and it should be shipping by press time. The product is Project Scheduler 7, from Scitor Corp. With Project Scheduler 7's unique HTML conversion feature, project managers can publish status reports directly on their Intranet. As a result, project stakeholders at different locations, and independent of hardware and system, can access the most current task, resource or project information. What I especially like about this capability is that it eliminates the requirement for users to have access to the scheduling software or to be familiar with its operation. Occasional users of the project data can access it using a familiar metaphor. Look for this capability to become standard as the Web continues to permeate our lives. Project Scheduler 7 is the latest generation of Scitor's project management software, developed for 32-bit operating systems. The revised and improved user interface fully complies with Windows 95 standards.

Also this Fall, Primavera Systems will be supporting HTML with both Primavera Project Planner (P3) and SureTrak Project Manager (ST 1.5) through a Web publishing wizard. They will be putting the ST Web Wizard on their Web site for existing customers as soon as it is available (probably October). It will be slipstreamed into production of new systems in November to coincide with launch of P3 2.0.

Early Observations. Personally, I have been through the entire spectrum of computer environments for project management, beginning in 1962 with punched cards on a mainframe (a Philco 2000—and you thought they only made radios). I lived through the first direct-to-tape input systems and several minicomputer and timesharing computer configurations. All of this was endured with trepidation, as I could only be a computer user—control of the system was held by others, on the other side of a formidable barrier. After a 20-year nightmare of overnight runs, massive core dumps, and two-week turnaround times, the personal computer burst onto the scene, and with it the promise of user-friendliness, user-control, and fast processing. And this promise was delivered—in spades!

So what's the problem? One concern is that we have optimized the desktop environment but not the enterprise environment. Individual desktop machines, even when networked, do not satisfy the corporate need. Up to now, those people charged with providing an enterprise solution have mostly had to shy away from desktop systems. They are too hard to administer. The data ends up all over the place. The individual applications (as well as much of the data) are isolated.

Could we have our cake and eat it too? Could the maze of desktop computers be incorporated into a full-featured, integrated system? Could the CIO move away from expensive and cumbersome legacy systems without giving up the control, security, and connectivity that is required? I see a strong move in this direction and will be watching for the results. And what is the potential effect of emerging Internet and Intranet technologies on EPM? I have already held discussions with developers who are exploring this approach.

At the moment, there don't seem to be any strong, commercially available solutions. Based on my own observations and feedback from others, even the best single-application package cannot come close to meeting the enterprise user's specifications. Even the numerous add-ons and consolidators are falling short of meeting the needs. Multiproduct solutions are emerging, but they present problems of their own. So do custom solutions.

Defining EPM: Some Questions. As I said at the outset, I am not prepared at this time to document all of the answers about EPM. Personally, I am not even an EPM user. But I am deeply involved with EPM users, consultants, and developers, and I am beginning to collect some very interesting and diverse data about this subject. In order to organize and classify the data, I have developed the following questions:

1. What are some common complaints of “Enterprise” users?

2. What are the typical characteristics of an EPM system?

3. What issues are associated with an EPM system?

4. What are users looking for? Can we specify by type of user? i.e.:

a. CEO or executive level

b. Resource manager or functional/line manager

c. CFO or accounting/finance

d. CIO—the corporate information systems function

e. Project managers

f. Project office or project administrators

g. Simple user or end user (people working on projects)

5. What do we mean when we say:

a. Automated?

b. Integrated?

c. Enterprise-wide?

As I collect and analyze the data, I hope to build a definition of the prototypical Automated, Integrated, Enterprise-Wide Project Management System and to identify key conditions and issues surrounding this project management solution. And I intend to provide examples of working solutions from project management consultants and software developers.

Typical User Complaints. We'll start off this month with some observations that I made while working with some of my clients, and with some early feedback from Tonja Pfister, director of the Angel Group, a Dallas consulting firm. Here are some of the complaints of people using or aspiring to have an enterprise project management capability:

  • Connectivity problems. Networking system is complex and/or not understood by the people trying to implement EPM.
  • Systems not robust enough for the enterprise. Breaks down with large user base.
  • Workflow lacks cohesion and continuity. Connectivity between system segments is not seamless. Data passage is cumbersome and requires too much intervention.
  • Products break down at multiproject level. Inadequate coding at project level to support automated consolidation. Problems with consolidation and re-separation of projects.
  • Resource allocation weaknesses. Users want system to help assign resources and skills. They also want to work with both individual and group resources, simultaneously.
  • Poor resource balancing and leveling. Often shows underloads when resources are fully committed
  • Knowledge deficit. Inadequate training and support. System put in place and users left to sink or swim.
  • Inadequate buy-in. System forced upon users rather than the product of collaboration.
  • Data normalization and management. Who owns the data? Where is it? Data formats?
  • Getting the right reports for all of the diverse users.
  • Redundancy. Often, elements of the EPM are not robust enough to replace similar corporate systems (such as timesheets) or old and new system must be run in parallel until new system is fully proven.
  • Payback. Question of whether new EPM is cost effective. Is it worth the cost to develop and/or to maintain?

Defining EPM: Some Answers. In this search for Automated, Integrated, Enterprise-wide Project Management, I thought that I would try to gather interpretations of the key words making up that expression: Automated, Integrated, Enterprise-wide. Here's the response I obtained from Tonja Pfister relating to a system that Angel Group is installing at a major client site:

Automated. Plan sources are loaded to some central or locally regionalized repository. Multiple toolsets are employed to accomplish the tasks of planning, estimating, scheduling, maintaining the plans, generating turnaround documents and timesheets, capturing actuals, performing analyses, testing, preparing summarizations and statistical reports. In the process, data from multiple organizations is integrated for senior management without the mad “Steering Committee Review Preparation” dance.

Integrated. It is really transparent to whatever level of user that multiple tools are being used to accomplish the goals. Most team members only interface with the turnaround documents, timesheets and the Tracking DataBase (a special component of the Angel Group system, addressing Issues, Incidents, and Changes). Most project managers add the project management Software to that list. The collection points and databases provide the greatest reporting benefit, offering a virtual data warehouse of project data for analysis. Users of the high-end client software packages are few and therefore it is very economical. Users of the low-end client software are many. The client's most common denominator database and file transfer protocols/tools are used to reduce vendor software costs.

Enterprise-wide. This is easier said than done, and is rarely accomplished across the entire enterprise. Most of these solutions never get beyond a senior vice president or a business unit president in the truly large firm—although that in itself may encompass 3,000 resources and millions of budget dollars. The differences are so many in the data types and reporting requirements between the groups, and no one wants to spend budget on an infrastructure improvement like a Project Management System. Yet, this is actually what we are doing—building a permanent solution for the project management problems of data capture, integrity, integration, relation, analysis and reporting. So we call it a Project Office instead, find a large project to pay for it—and make it work.

EPM Reservations. Wow! Doesn't the previous paragraph pack a wallop? Here we have a very competent system integrator delivering a full-featured EPM to a sophisticated and successful client, and she says, in essence, “don't try to sell or implement the system on too grand a scale.” Sort of fits with my “fantasy” scenario in the introduction. If there's a message here, it's to move toward an automated, integrated, enterprise-wide project management system while being still practical and aware of physical, budgetary, political and cultural constraints.

The Project Office. A second caveat: Don't try to implement an automated, integrated, enterprise-wide project management capability without setting up a project office (see my Commentary on this subject in the September PM Network, pp. 12–13). The operation of the EPM must be centered in and supported by dedicated project management specialists. They will aid in its development and implementation. They will provide training and support. And they will assure discipline and compliance. The lack of a project office (centralized project management function) will lead to disuse and misuse of the EPM system, with chaos replacing control. For additional justification for the project office, see B. Conway's Research Note ADM: SPA-650-1158 (May 3, 1995) published by Gartner Group. Directing his report to the Applications Development arena, Conway sees the Project Office as a source of: (1) project management services, (2) methods, processes and metrics, (3) best-practice brokerage, and (4) reuse of data and knowledge.

Call for Comments. Okay! We're off and running with this feature on automated, integrated, enterprise-wide project management. It is now up to you, whether system user, consultant or developer, to help me to complete this study. Is there really something called Automated, Integrated, Enterprise-wide Project Management? Is it achievable? At what price? Are there practical limits for an EPM? What do users want? What are systems integrators and software developers providing? Is anything working as intended?

This is an interactive cliffhanger, so don't leave “Minnesota Smith” dangling over this abyss of unanswered questions. Please send me your input so that I can feed it to PM Network readers. Responses from users will help to guide system providers to meet the need. Also, where there are practical solutions, we want people to know. The next column in this series will be published in the January issue, and will be based on input received and evaluated through October 31. If you have e-mail, reach me via CompuServe 76153, 1552 or you may mail information to 21 Pine Ridge, Saratoga Springs, NY 12866 USA. img

Harvey A. Levine, principal, The Project Knowledge Group, Saratoga Springs, New York, provides training and consulting services to users and developers of project management software. He is also a past chairman of PMI.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network • October 1996

Advertisement

Advertisement

Related Content

Advertisement