Building effective enterprise project management (EPM)
Robin Hornby, Director, Tempest Management Inc.
This paper is about building a framework that enables project management to thrive and deliver reliably, resulting in bottom-line improvements in the Delivery Organization (DO). The system, which we define as Enterprise Project Management (EPM), is based on 20 years’ management experience and observation of the essentials—what works and what doesn't. The secret ingredient, missing from many treatises on project management, is to institutionalize connections between the general management of an organization and their project managers, creating an environment in which they can be successful. From this perspective, the paper describes the “magnificent seven”—the seven key elements of practical and profitable EPM.
Benefits of EPM include:
• Higher quality arising from more consistent project management (PM)
• Reduced impact of skills shortage, by leveraging the skills of an experienced manager to support novice or intermediate project managers
• Reduced project risks and increased reliability of delivery
• Enhanced integration within a decentralized or regionalized DO
• Improved productivity.
Our experience is that the improvements available through EPM can significantly exceed those from Total Quality Management (TQM), Business Process Re-Engineering, or Self-Empowered Teams. If you manage a DO or are influential in one, you will find value in this paper and the conference presentation.
EPM has entered the vocabulary of acronyms though it does not yet possess an agreed-upon or consistent definition. It has been used when referencing a number of initiatives aimed at improving management effectiveness beyond a single project and the strict domain of an individual PM. These include consolidation of multiple projects using advanced PM software, elevation of a Project Office (PO) to departmental level, and PM competency improvement using organizational “stages of growth” models. These can all be part of what EPM encompasses.
Software vendors have also seized on the acronym and present EPM as a more pervasive implementation of their newer database-driven architectures. They use the term as a product attribute or feature. However, EPM is more than the installation of project management software throughout the DO, just as TQM is more than the charting of error statistics.
EPM is significant because its objective is to nurture PM in the organization. The emphasis is on the Enterprise in “EPM” (or that part of it we are calling the DO). EPM is a working environment for project managers, including rules and processes designed to uplift the effectiveness of the DO as a whole. This is not just a more skillful application of PM, or another rung up the PM maturity model, but is something new.
Before examining the proposed framework and elements of EPM, some impacts to the DO should be noted:
• First, a new role is to be introduced, called the Delivery Manager (DM). This role is becoming commonplace in consulting or outsourced organizations, but is rarely found in-house except as a secondary role to the resource, budget, prioritization, user-liaison and administrative load of a typical Development Manager. A slight realignment of the general management team might be required.
• The DM owns the processes that comprise EPM, and participates in most, if not all of them.
• EPM affects the Project Office and the Quality Management Group, should they exist, and boundaries of responsibility and authority have to be negotiated.
• Project managers are affected by the proposed EPM innovation and require training.
This paper explores the impact of EPM specifically within the Information Technology (IT) DO. However, there is nothing intrinsic in the proposed framework that ties its application to IT DOs and the benefits may be universal.
A Framework for EPM
Both the methodology and organizational views can be used to describe a framework.
From a methodology viewpoint, the classic “commit / start / execute / close” lifecycle can be adapted as a “delivery management” external lifecycle to define universal control and approval points for the entire portfolio of projects. This is held consistent for ALL projects—though of course each project possesses its own more detailed and specific internal methodology based on the type of project and other needs. This view places EPM “on top of” the enterprise's project management functions. These functions may be sophisticated and well developed, or rudimentary and ad hoc. As the project rolls along, various types of project reviews act as formal touch points with the DO and remind PMs that they are operating within an environment that both makes demands and provides support.
Turning to the organizational view, Exhibit 1 shows both the DM and the PM perspectives. We will focus on this view as the basis for more detailed discussion of the seven chosen EPM elements.
The DO sees the PM as autonomous within the project; planning, organizing, controlling as dictated by the demands of the day. The DM holds a separate and superior set of accountabilities for this and every project, namely: ensuring DO commitment, reviewing and coaching, and facilitating issue identification and resolution. The glue that holds this together is the information system that feeds all parties. Without information, all other management activity is inefficient and possibly misguided. In fact, EPM cannot work. An information system is a “must” and will usually yield an immediate benefit, though mastery of all seven elements is needed to optimize and sustain EPM benefits.
The Seven Elements of EPM
By now, the idea of EPM as a framework that straddles the classic activities of a PM should be established. Populating the framework with just seven elements is a judgment based on our experience. Seven elements are necessary and sufficient, though they can be supplemented ad infinitum. When setting procedures that operate at the general management level, keeping things as simple as possible should be the watchword. Here are the elements that define EPM.
1. Risk Analysis
2. Structured Estimating
3. Project Reviews
4. PM Coaching
5. Escalated Issue Management
6. Time Accounting
7. Information System
These elements, when integrated, are the EPM systems. Naturally, there is some borrowing from classic PM methods, but note the important difference—these are environmental processes run primarily by the Enterprise, not by the project manager.
Risk analysis techniques are finally becoming prevalent. The method described in PMBOK® Guide, albeit with terminology variations, is virtually a standard in most DOs that claim to perform such analysis. The difficulties arise with keeping the risk assessment straightforward and pragmatic so it can be used for management decision-making (starting with project commitment). Somehow, risk analyses get completed with a sigh of relief and filed out of sight, to be rediscovered during the first schedule or cost over-run inquisition. Perhaps this is because actively using risk analysis to mitigate risks, to allocate contingency, and to report and interpret changes in risk, can be a tough job. This difficulty is resolved by applying EPM standards that call for:
• A manager (the DM) accountable for risk management and continually holding PMs to account for their mitigation plans
• An estimating structure that provides a rational basis for mitigating risk using contingency
• A reporting metric for the portfolio of active projects that assesses the intrinsic risk accepted when the project was committed, the current risk based on project health indicators, and planned and remaining contingency amounts.
We have found it quite beneficial to tailor a risk questionnaire specific to the DO. Such a questionnaire can usually be built from a list of standard risk factors, available at the presentation. The questionnaire is taken into a risk brainstorming workshop where the facilitator uses it to trigger thinking on specific project risks, probability, severity, and mitigation, following a standard analysis format.
One of the tremendous benefits of building risk analysis into the EPM is that management needs to understand project risk, and requires education on the shades of gray implicit in risk-based thinking. They have a desperate need to “manage” (control) risk, though this is naturally not possible given the random world we inhabit. A well-constructed risk methodology does give them control over decisions on how much risk they wish to accept, set against the rewards promised by the project. This in itself is a quantum leap forward in the quality of project evaluation practiced in many DOs.
It is alarming how much estimating is still done on the back of envelopes! We know this because of the project audit work we have done and how frequently the estimate for the project is missing. Simply ensuring that a written estimate is done, based on a rational development methodology, might be sufficient to ensure another benefit for EPM. However, there is another side to this that EPM needs to address. How familiar is this scenario? A new project manager joins the DO, starts the first project assignment and discovers:
• There is no standard lifecycle or methodology for project delivery
• There is no standard list of deliverables or process to help select those actually required
• There are no published “rules of thumb” endorsed by management (or anyone else!)
• There is no published estimating guide or procedure
• There is no repository of completed projects from which they can learn
• When estimates are complete, PMs must then defend them in confrontations with management for whom they work, even before they have to face the client.
Is it any wonder that project management can be a lonely and stressful job? EPM specifies that the DO provides an environment for structured estimating that is safe and supportive for PMs. This means providing training in Methodical Methods (WBS, standard estimating grids by deliverable, function points, etc.), and access to Expert Methods (someone who's “been there, done that,” analogous projects, Delphi groups).
Regardless of the sophistication of the estimating environment, a structured estimate is a prerequisite for approval. This is the only way to learn and to improve. This estimate is templated to include standard items that must be dealt with in the setting of the specific DO. Three-point estimates that include the optimistic, likely, and pessimistic view also provide the most rigorous base for contingency estimation.
There are two levels of commitment and every organization has them: the sponsor (or client), either internal or external, and the DO. The project manager requires the support and approval of the DO in order to proceed with the sponsor. Although evidence of other documents and activities may be useful for the DM to support the project, the risk analysis and structured estimate are usually sufficient. They are integrated through the risk “S” curve modeled in Exhibit 2. The management process determines the affordable level of contingency or management reserve to be allocated, and the associated risk level to be accepted.
Exhibit 2 tells us that if the budget is set at 450 hours, the PM only has a 50/50 chance of success. A coin toss is not a good way to build (or keep) a career, but adopting the pessimistic view is not affordable. If the three-point estimate is not abnormally skewed and approximates a normal distribution, statistics tells us that an estimate halfway between the median and the pessimistic is a good approximation to a 70/30 chance of success. This is usually affordable and close to the point on the curve of diminishing returns. In our example, the PM would be granted a budget of 500 hours, but still set the target of 450 hours, the difference being the allocated contingency. This is a much better career bet.
With the risk mitigation plan and contingency requirements based on the S curve, management have data they can use to make an informed decision whether to support the project, or not, and to set the level of management reserve.
This becomes the basis of a “contract” between the PM and the DM, and may then become the basis of a real contract between the DO and the sponsor.
The DM is the arm of management responsible for ongoing assessment of project progress and risk. The EPM specifies four types of reviews—commitment, startup, progress, and close-out. Reviews must be periodic, formal, and respected by the PM and DM. The intent is to provide management attention through checks on standards, probes of status and issues, and updates of the risk mitigation plan. A complementary intent is to support the PM and to provide a value-add consultation. It may, if appropriate, link to a PM coaching activity.
The progress review will rely heavily upon reports from the Information System, so we have not made PM status reports an essential element of EPM though they will be a part of most PMs’ internal processes. Considerable coaching from the DM is usually required to develop universal, consistent and useful status reports.
The review must be documented. At the very least, a Health Indicator report with one line per project will provide excellent communication value. An example will be included in the presentation. Red/yellow/green ratings are applied to four areas of project concern: delivery (including schedule), client, team, and budget. The DM assigns overall ratings, and red projects are prioritized within the DO to ensure the maximum level of management support. Red projects are a management meeting agenda item.
Project management is learned by “doing it” and by attendance at formal PM training. This can take a long time, involve a few risks along the way, and sometimes sap the confidence of potentially capable PMs. Project management can be a lonely job. The EPM system therefore includes a coaching element to accelerate PM learning, reduce the dropout rate of capable novices, build PM competence and raise the quality of PM decision making. The role of the coach is to:
• Develop a confidential and trusting relationship with the PM
• Act as a mentor
• Be available to the PM during crucial periods such as initial planning, establishing project disciplines, dealing with crises, and making high-risk decisions
• Help the PM understand the need for skill growth and build their personal development plan.
Who should coach? The DM is an obvious candidate in the smaller organization. Coaching can be integrated into the project review process. The success of this is highly dependent upon personality because it is sometimes conflicting to operate as both coach and manager. In larger organizations the Project Office can be an excellent source of coaching. All DOs might consider maintaining a small cadre of part-time mature external PM practitioners who will welcome the opportunity to share their experience and insights with those less battle-scarred.
Escalated Issue Management
Many projects fail, or consume more time and effort than necessary, because of an inability to recognize and resolve issues. Issues tend to emerge from unmitigated risks, thus the DM‘s risk review agenda will help the PM maintain vigilance and keep ahead of the game. Issue management administration is usually a checklist item during process reviews. The spin that EPM puts on issue management is to integrate across projects, develop common rules and process for escalation, and to ensure an escalated issue “sponsor” (the DM) is active round the management table. Here are the ingredients for success with an issue system:
• Make sure PMs know what an issue is (a real and present obstacle to project progress that can be removed by taking defined actions)
• Care must be taken to frame an issue in terms that are amenable to the definition and assignment of actions
• Make sure the rules for escalation are clear
• Remind PMs that even after escalation, ownership of the issue remains theirs. Others, including senior managers, will own actions to resolve the issue, but the PM must continue to track, report, and expedite issue resolution.
At managers’ meetings, the DM ensures a review of open escalated issues is on the agenda. Issues from different projects with common root causes can be analyzed and results used to prioritize departmental quality initiatives, system or organizational changes, or facility acquisitions.
One topic that consistently causes a groan is time reporting, but without it the DO cannot analyze where time goes. The old adage that says, “If you're not measuring, you can't manage” is quite right.
Most reasons for the disparagement of time accounting is that it is done poorly. Systems are redundant, slow, and manually intensive. They require too much detail, not enough detail, or leave engineers wondering where to log their time rather than helping them log their time.
Outsourcers have learned the value of time accounting, as it is typically one of the first innovations. Inevitably it results in:
• Reduction of non-productive time
• Redirection of productive time to desired activities.
By far, the most vital and long-term benefit from time accounting is integration with the structured estimate. Now, we can start to build organizational memory independent from the PM heroes who estimate based on what they learned at UHK (University of Hard Knocks). This link will be encouraged by the provision of project templates already populated with standard tasks and deliverables against which time must be reported. A progressive DO will formalize its learning in an estimating guideline to be used by the PM but conditioned by DM review and approval (no successful estimate is done with rulebooks alone).
This brings us to the final element, the Information System, that should also be tightly integrated with time accounting.
The information system is the glue that holds EPM together, though by itself it is not EPM. The market place is full of vendors who will feature EPM capabilities—AMS, Scitor, Artemis, Digital Tools, System Corp, Primavera, Open Plan, PlanView, to mention a few. Our experiences have been with custom-built products and with ABT Project Workbench. Exhibit 3 shows a typical configuration.
The capabilities to look for include:
• An integrated timesheet system
• A central project repository
• A central resource repository
• A repository database architecture based on industry accepted technical standards (SQL)
• Strong multiproject features
• Template support
• Flexible reporting
• Ease of report writing (no need for professional IT intervention).
Reports will depend upon the nature of the DO and specific management requirements, but typically fall into four areas.
1. Resource Utilization: showing where the time went by category; used for estimating/forecasting and variance management.
2. Resource Usage: showing time allocation by person, actuals and planned (six month horizon); used for resource management and planning.
3. Project Progress: showing cost vs. budget, earned value or percent complete, milestone achievement; used for overall status reporting and budget management.
4. Project Activity: showing time logged by project/task by period and totals to date; used for analysis of progress issues.
All reports should be selectable by project or by groups of projects and be responsive to the stated needs of the PMs, the DM, and other management.
Implementing EPM has taught us some useful lessons about how the challenge should be approached, what the preconditions for success might be, how much it costs and how long it takes. The presentation will include examples of techniques and plans. In summary, we believe the following points are the critical ones:
• The head of the DO must want and support EPM. This type of initiative won't happen bottom-up.
• Make sure you have at least one clear, acknowledged problem to be solved (e.g., persistent over-runs, poor record keeping or reporting, inconsistent PM performance, communication problems, etc.). This will be a reference point to encourage adoption and sustain implementation.
• An accountable DM must be appointed. This person must have mature project management experience and be capable of articulating the EPM vision.
• Processes for all seven elements of EPM must be designed, written down, and implemented. Make sure the DM and PM responsibilities are effectively linked through the project commitment, project review, coaching, and issue escalation processes.
• The information system is central and is an implementation project in its own right. Use a pilot, and don't forget data conversion for ongoing projects.
• Aim to get EPM up and working in four to eight months. Even small DOs need four months to design and assimilate this. Eight months is the maximum without losing momentum. Implementation should be paced and urgent. Expect issues over business rules (automation and process definition force formalization where looseness previously existed).
• Provide JIT (“Just in Time”) training to all PMs (covering the entire EPM) and staff (covering time reporting and overview material only).
• This will involve a significant culture change in most DOs. Be patient, firm, and repetitive. Coaching at all levels will be required.
If you don't have the time and expertise in-house to do a good job of your EPM implementation project, bring someone in who knows how to do it, and has done it before.
Just as an enterprise would not consider hiring accountants without a chart of accounts and a set of books to manage, nor engineers without material specifications and job costing standards, neither should the supportive DO hire PMs without an EPM. This paper has encapsulated our experience in developing EPM environments that we hope will contribute to further formalization.
One area of great interest and potential future development is software that integrates the seven EPM elements into multiproject PM packages. Functionality requirements include:
• Support of risk analysis, contingency allowances and multipoint estimates
• Ability to add user-defined flags and text, project review data, health and risk indicators, or easily import from spreadsheets for inclusion in summary project reporting
• Interface with an estimate repository
• PM skills inventory and developmental data
• Issue management subsystem
• Integrated timesheet and information system capabilities already discussed.
Naturally, our wish list could continue into other areas (e.g., change request management) that are still handled externally and not generally integrated with PM software, but let's remember our own advice and stick to scope. Implementing the above shopping list will be a tremendous boost and move the DO to a new plane where project management can thrive and progress—Enterprise Project Management!
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA