Introduction
What does it mean in terms of organization, business processes and technology to become truly project driven? And which roadmap should be used to transform the current practice of running projects on an ad hoc basis to a professionally run project based business operation? In today's rapid changing business environment these questions are highly relevant. For a number of years, the market has been flooded with methods, techniques and tools for supporting project-based organizations. High-end project management solutions and Professional Service Automation tools are being developed; Program management and portfolio management is hot. This article describes a useful reference model for Enterprise Project Management and paints a roadmap for improving process, organization and technology aspects in a balanced way. The concept is based on experiences with implementing Enterprise Project Management in a number of organizations, ranging from IT to public sector.
EPM Reference Model
Building a project-based organization requires a blueprint or a reference model of such organization. The model should help to understand the gap between current and future practice, and serve to develop a paved roadmap to the required configuration. Project management models are extensively defined, for example by PMI and IPMA, but what for project driven organizations? Exhibit 1 shows a summary view on such reference model, with its processes, organization and technology components. Each of these components will be briefly discussed below.
Exhibit 1: EPM Reference Model
The Process Component
The EPM reference model is process-centred, indicating that organization and technology are derived from the processes. Looking at the processes in more detail, we identify three distinct levels of Enterprise Project Management related process groups (Exhibit 2):
- EPM Governance Processes
- EPM Execution Processes
- EPM Support Processes
A brief description, without going into details on input and output of each of the processes is given in exhibit 2:
Exhibit 2: Processes in a Project Environment
The difference between a project driven organization and a traditional organization, just executing a limited number of projects is found in the additional processes, next to the (single-) project management and project lifecycle process (indicated in grey).
The Organization Component
The organization component is about people, roles and responsibilities for running a project-based business. In a mature project based organization, at least the following roles should be defined:
- A Project Portfolio Steering Committee for executing the portfolio management process and (temporarily) guiding the transition to Enterprise Project Management.
- A Project Support Office (PSO) for executing all EPM Support Processes and supporting or executing the EPM Governance Processes. Typical PSO staff would include project controllers, contract managers, project administrators, methodology specialists, and EPM tool specialists.
- Project Board or Project Sponsor roles for initiating, directing and decision making in individual projects or programs within the organization.
- Program Managers and/or Program Directors. These roles are optional and depend on the existence of programs within the organization.
- Project Managers with the right levels of authority to be able to effectively manage all projects, including cross-functional or even multi-organizational projects.
- Resource Managers, responsible for staffing the projects with qualified personnel.
- Team Leaders for managing work packages or sub-projects within a project.
- Trainers, Coaches and Facilitators for developing project management skills and for supporting the start-up process of individual projects or programs.
Defining the right roles and responsibilities is one thing, finding and educating the people to fulfil these roles often appears to be a difficult job. It includes creating and continuously promoting a project-oriented culture, defining the required competences and developing a system for recruiting, educating and motivating these people. A suitable training curriculum and coaching system should be used. The training curriculum should at least contain the following aspects:
- PM Methodology training
- General PM knowledge & skills training (both “hard skills” and “soft skills”)
- Personal Attitude Development (individual assessments, training and coaching)
- PM Tooling training
In addition to the training, a certification and career development program can be adopted to motivate PM staff to be serious about developing their competences. Finally the reward & recognition system should be in support of the project-based organization. Rewarding project managers for taking responsibility for their own professional development and for delivering successful projects is a very powerful method for improving project performance and success rate. Care should be taken however to define the correct metrics; projects run successfully to the metrics of the project manager should add real business value to the sponsoring organization.
The Technology Component
The EPM processes require specific sets of information in order to be effective. The following types of information can be distinguished:
- Project related information (goal, owner, scope, cost, schedule, quality, risk, etc.)
- Resource related information (cost, skills, availability, location, etc.)
- Portfolio related information (investment, benefits, risks, etc.)
- Task related information (specifications, documents, risks, issues, schedule, etc)
- Organization related information (breakdown structures, roles, responsibilities, authorisations, standards, methodologies, etc.)
Above information is created and/or used by the various stakeholders in the project based organization. At least the following groups of users should be identified:
- Project managers (those who manage programmes, projects or work packages)
- Resource managers (those who supply project staff)
- Team members (those who perform the work within the projects)
- Executives (those who take project decisions, including project board members and project portfolio steering committee members)
- PSO/PMO staff (those who use information for supporting individual projects or for aggregate reporting)
Other possible groups include portfolio managers, procurement staff, external contractors and financial controllers. An enterprise project management information system must be capable of providing all of the required information in a structured and timely manner. Traditional project management tools have focussed on scheduling functionality for individual projects. Modern EPM systems are much broader in functionality, with focus also on managing resources across the organization and managing multiple projects and programs. Ideally an EPM system should support all of the processes of the EPM reference model.
Technology Requirements
Besides functional system requirements there are also some key technology requirements for supporting an enterprise project management environment. These requirements are:
Usability, Including Web-Based Functionality:
Usability is probably the most critical factor for a successful implementation of an EPM system. The system should be capable of being used by geographically dispersed project staff. Furthermore, a system offering a role-based or customizable user interface has many advantages regarding acceptance by the user community.
Centralized, Open Database:
The next requirement is the use of a centralized, open database as the project management repository. The use of a centralized, open database improves data integrity and provides a means for establishing a single point of data entry, control and exchange between the project planning tool and the tracking (time sheet) tool.
Multi-Project, Multi-User Capability:
The ability to manage multiple projects and multiple users at multiple organizational levels is or course key to any EPM system. There should be no practical limits on the number of projects the system can handle. It should be recognized that there will be performance differences when running queries or reports against hundreds of projects (which should be extremely fast), versus a complex resource analysis of the same number of projects.
Customizable Fields:
Another factor to be evaluated before choosing a system is the flexibility of the identification system for projects, tasks, and resources. This is a key area where the enterprise project management system can adapt to the organization ways of doing business rather than vice-versa.
Security Functions:
There should be functionality that allows an administrator to control who has access to what data and the type of access they have. What is needed is a combination of data-level security and functional security, which can be specified for an individual user. The data-level security controls what projects and resources a user has access to (including whether or not the user even knows of the project's existence), while the functional security controls what functions (analysis, mass updating, task progressing, etc.) the user can perform on the particular project and resource.
Template Capability:
Since, in most circumstances, there will be many repetitive types of projects, it makes sense to utilize a template approach to project planning, and to implement enterprise project management software which supports the template concept. Templates offer a means to formally document, publish and standardize a set of “building blocks” for projects, including breakdown structures, codes and resource lists. While at the same time, it adds consistency and discipline to the project planning process. In turn, templates help businesses establish “organization best practices” by providing project planners with established and successful methods and models that can be edited and updated across the enterprise.
Multi-Function Reporting:
Another key requirement to be considered when implementing EPM software is a simple method of reporting project- and portfolio information to individuals with varying degrees of involvement in the project management effort. Plus, since the analysis produced by any project management system depends on the timeliness and accuracy of the progress data, it also must be easy for users to access these data. The best method for project based reporting is a flexible and customizable tool for producing both graphical (gantt, pert, histogram, etc.) and tabular (reports, lists, etc.) reports. The most successful methods available today are repository based or On-Line Analytical Processing (OLAP) based tools (tied to the centralized, open database).
Alert/Notification Capabilities:
A final requirement of enterprise project management software is a notification feature to identify updates of information that impact projects. An alert must be designed to automatically inform all project stakeholders. A notification software feature implies flexibility for keeping everyone informed of the latest developments in their projects or tasks.
Maturity Concept
Using a maturity model is a widely accepted method for guiding process improvement initiatives. Maturity models have been developed for many purposes. A well known model is the Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI) The Software CMM has become a de facto standard for assessing and improving software processes.
For project management many maturity models have been developed. A well known model is the ProjectFRAMEWORK® by ESI. This model is based on the CMM approach and is not only aimed at a single project, but is also suitable for assessing a project based organization as a whole. The processes used are based on the PMI's Guide to the Project Management Body of Knowledge®. In May of 1998, PMI chartered the Organizational Project Management Maturity Model (OPM3®) program, for the purpose of developing a global standard for organizational project management. It is “to guide the development of capabilities necessary to execute organizational strategy through successful projects”. There is certainly a potential for this maturity model to become an important standard if organization, process and technology aspects are covered in a balanced way. Most models use four to five steps to describe and to measure the competence to perform a specific process in an organization. (Exhibit 3) The scale usually used is initial, repeatable, defined, managed and optimized, according to the SEI Capability Maturity Model. All maturity models are based on the premises that an organization will have to go through all lower maturity levels first, before reaching the next higher level.
Exhibit 3: Process Maturity Levels
Using a maturity model to assess the project-based organization will help to focus on the right issues. We still often see an organization buying a sophisticated tool for supporting a non-existent process. This will lead to nothing except dissatisfaction and frustration. Also remember: “garbage in = garbage out” or the 90/10 rule: 10% invalid data ruins portfolio management information reports. Choosing the right strategy, based on organization requirements and organization capabilities is not an easy job and requires in most cases experienced consultants.
From the above it will be clear that there is no single roadmap to a mature EPM environment; however, some general steps can be identified based on our experience in different types of organizations. To understand these steps they will be explained along the lines of the main components of the EPM reference model. Before going into any detail there are two basic points to be made:
- In general it is good practice to start developing an execution process first, then follow up with a management process, and finally defining organization structure and information systems.
- Another general approach is to start with the operational processes first, and only after that moving on to tactical and strategic processes.
Component Development Steps
In this section a general modular approach is presented to developing EPM maturity. The approach presented should always be tailored to the organization and may be a subset of these or other modules, depending on the maturity level and on the EPM needs. If, based on a maturity assessment it is decided to initiate a multi-discipline EPM development plan it is in most cases advised to manage this plan as a program. This means that different kinds of projects may be chartered, with different sponsors in the organization (including for example HR and Finance) and that adequate attention is given to realizing the benefits of such program.
In the next section the program management processes are omitted, because we want to focus on the component development steps. Each step might be a separate project or as an alternative some steps might be combined in a project. Also it is assumed that a basic project management practice is already in place, including the ad-hoc processes (used in some departments), organization roles (specifically project board and project manager) and a stand-alone, single-project scheduling tool. In the real world this assumption is of course not always true.
Process Component
A typical staged plan for developing the additional EPM processes is shown in exhibit 4.
Exhibit 4: Typical Process Development Stages
As indicated, the first stage is used to create some quick wins. Quick wins are easy-to-implement changes with short payback time. Examples are the use of simple project planning & reporting templates or checklist. Also we see that at in the early stages EPM support processes are introduced in order to quickly create a common approach on how to manage projects. Ad hoc processes and methods need to be replaced with a standard project management methodology and a common language throughout the enterprise. In later stages the standard methodology can be customized to accommodate company specific requirements or to scale the methodology to projects of different complexity or size. The EPM governance processes are implemented in steps 3 and 4.
Organization Component
Typical organization development steps are shown in exhibit 5.
Exhibit 5 Typical Organization Development Stages
These steps should be based on the process steps above. A project portfolio steering committee should however be appointed in the first stage already to ensure management commitment and to guide to the complete improvement program. A project support office with limited services should be created as soon as possible. The PSO will be the focal point for the further development of the EPM environment. In later stages the PSO may become a true Project Management Office (PMO) and can be tasked with more roles and services. A PMO may even include a pool of professional project managers.
Developing a project oriented organizational culture, recruiting and training people in new roles is often the most time consuming aspect of maturing the project driven organization. Training is therefore an important aspect of any organizational development program.
Technology Component
There is a natural evolutionary path of the use of an EPM system corresponding with project management maturity. In other words, if project management practices are not yet fully mature it will be most effective to start with a limited implementation of EPM software. The basic system will then help to leverage the maturity level, for example on clear responsibilities, discipline on procedures, reporting, collaboration, etc. The system architecture should provide the flexibility to support a staged implementation.
Starting at Level 1 Project collaboration features are used, enabling basic task management, status reporting, time writing, document management, risk management and issue management. This keeps all stakeholders well informed of ongoing projects and provides the organization with an early platform for enhancing EPM maturity.
At level 2 additional project control and resource management functions are added, using more advanced features such as cross functional budgeting, earned value analysis and skill based resource assignments. This should enable consistent project tracking and reporting using company standards. Resources can be assigned over multiple projects, based on availability and skills by using a centralized resource pool.
At level 3, portfolio management can be introduced, building upon the level 2 functionality. This enables the PSO to provide senior management with adequate portfolio information in a flexible manner. Decisions on which projects to prioritize can be based on a sound evaluation of the business case in terms of expected risks, costs and benefits for the organization. Typical EPM system development steps are shown in exhibit 6
Exhibit 6 Typical Technology Development Stages
Final Remarks
Lifting organizational project management maturity requires an integrated approach, developing process, organization and technology aspects in a balanced way. A proven method for organizing such initiative is to use program management, focusing not only on managing the individual development projects, but also on managing the expected benefits. Effective metrics should be developed, for example: project cost- and schedule index figures, time to market, scope changes, resource utilization, etc. Critical success factors include: management focus and vision, aligning the program objectives with business strategy, using competent resources, adopting realistic schedules and tracking the program benefits.
This paper is not intended to give an all-the-way recipe for every organization, but to share some lessons learned from several project management improvement initiatives, carried out by the author and his colleagues. It is very important to realize that every single organization is unique and an EPM improvement initiative should always be adapted to specific needs and circumstances. Special care should be taken when introducing sophisticated tooling. Many attempts of implementing modern project management tools suffer from lack of attention paid to the business processes or organizational issues. It is the opinion of the author that the time required for successfully carrying out an EPM improvement program is mainly determined by cultural and people issues.
