Defining Your EPM Scope

Making EPM a reality means developing a system aimed at transforming the organization into a more dynamic, project-driven enterprise. For that to happen, it is important to manage the organizational expectations of the EPM. An EPM solution is more than just the implementation of a project management software. It involves changing the way projects are planned, tracked, and controlled to ensure consistency throughout the organization. The EPM solution calls for the application of standards and principles at the organizational level and not only at the project level.

Managing EPM Rollout Expectations

It is important for the organization to understand the intent of deploying an EPM, which is to create an integrated structure linking functional departments with program teams.

The organization can expect that project managers, together with functional managers, portfolio managers, and executives, will identify the best practices and most suited project management methodology for the organization in the context of the EPM solution. Identification of roles and responsibilities of each party may ultimately be embedded in a governance agreement.

The governance agreement defines the organizational operational principles for project management, including the following:

  • Role of the sponsor, project manager, and functional managers

  • Budget authority allocated to the project manager

  • Scope authority allocated to the project manager

  • Change management process (describes how change will be accepted into the project)

  • Resource allocation governance (describes how resources will be allocated from functional areas)

An important part of managing the EPM rollout expectations is to make sure that EPM stakeholders, and the organization in general, understand the organization's current project management terminology and processes. These processes, structures, and terms must be mapped into the Microsoft Project 2003 system, and the team must identify, review, and map any necessary business process changes required to leverage the new technology.

It is also important for managers and executives to understand that by participating in an enterprise system, some of the ways they were doing business so far may not apply anymore because an EPM solution seeks to standardize methods, procedures, rules, and structures throughout the organization.

Stakeholders must be aware of the fact that by implementing an EPM solution they gain access to a wealth of information and data not available to them before. Also, data reporting is now more complex, and it relies on the discipline of each participant in the project management process. The beauty of an EPM solution is that it makes it easier to spot project issues, and it increases the visibility of all projects and resources, and their assignments at the organizational level.

The organization must identify in the beginning all common business practices, structures, and terms for projects and resources and also identify gaps that must be closed for users to fully leverage the EPM solution functions.

Deploying an EPM solution requires the discipline of all participants and a long-term commitment to project management practice. It cannot be emphasized enough that introducing an EPM solution requires planning and regular review of the system to make sure that it reflects the organizational reality at all times.

Defining the scope of the deployment helps the organization manage expectations of end users of the system and those of the sponsors. It helps set the appropriate criteria for project acceptance and determines how the project should be measured.

Generic Phases of EPM Deployment

Most organizations that consider deployment of an EPM solution have developed for their project activities a certain methodology that varies according to the industry they operate in.

PAGE 701.

The following example of phases of deployment is generic and is not meant to override any existing methodology. Its intent is merely to give organizations considering an EPM deployment the necessary guidance and assurance of their own methodology.

Generally speaking, a project goes through the following phases and their corresponding stages:

  • Concept phase Includes the concept proposal stage and the planning stage.

  • Prototype phase Includes the design and development stage and the testing and verification stage.

  • Pilot phase Includes the preproduction validation stage and transition to the production stage.

  • Production phase Includes the launch stage.

  • Post-launch evaluation phase Includes lessons learned and administrative closure of the project.

The following sections describe what each phase should contain from the perspective of Microsoft Project 2003 deployment.


Bear in mind that this methodology is not specific to Microsoft Project 2003 deployment; it can be applied to any EPM solution.

Concept Phase: Concept Proposal Stage

During this stage, the project is being identified, and the organization recognizes the inception of the project. Also, an evaluation team is formed, and stakeholders agree on a project team that will manage the EPM solution deployment.

The intent here is to create an integrated structure linking functional departments with the project team. Together with other project managers and functional managers, the EPM project management team will identify roles and responsibilities for each party, including the following:

  • Who is the sponsor of the project and what the role of the sponsor is. The project sponsor has the ultimate responsibility for the success of the project and usually is the primary liaison with the senior leadership team of the organization.

  • Who is the project manager and what the role of the project manager is. The project manager has the responsibility for daily management of the project, ensuring that all interested parties stay informed at all times and also ensuring that appropriate actions are taken, as planned or in response to an unplanned event.

  • Who are the team members and what their specific roles are. Team members have specific responsibilities covering the areas of software installation, networking, process and methodology, configuration, communications, and training.

Depending on the size of the organization and the size of the deployment, the number of stakeholders may vary largely from one organization to another.

At this point, the project charter is developed and agreed on. The project charter provides answers to questions such as the following:

  • What is the budget authority allocated to the project manager?

  • What is the scope authority allocated to the project manager?

  • What is the change management process (describes how change will be accepted into the project)?

  • What is the resource allocation governance model (describes how resources will be allocated from functional areas)?

In line with the roles and responsibilities assigned to each member of the project team, a responsibility assignment matrix may be developed to facilitate communication among project team members.


During the concept proposal stage, the organization formulates and describes the EPM solution concept and presents the technology requirements and availability. The resulting finding can be incorporated in a gap analysis document.

The goal of the gap analysis is to investigate and question what often passes for accepted fact and compare it with the practical reality of real-world experience in the business-technology arena within the organization.

From a technical perspective, the gap analysis presents the current status of the hardware (workstations, network, security features, and so on), their compatibility with MSP, and actions that must be taken to ensure proper and correct use of MSP.

From a business process point of view, the gap analysis identifies the functional business requirements. Although Microsoft Project 2003 is fully customizable to suit the desired project management methodology, a thorough analysis of the methodology and business operating model is required to assess the compatibility of the software with existing processes.

This stage is also marked by the development of the preliminary EPM solution targets (preliminary requirements and solution target). Understanding that it is impossible to determine accurately up front all the requirements of an EPM solution, the team will nevertheless try to gather as much information as possible from all stakeholders and develop a requirements document that constitutes the starting point for developing the EPM solution in terms of data, functionality, and access.

This stage also sees the development of the scope statement. To clearly define the scope you also need to state the assumptions made and the constraints surrounding the project. Each of these assumptions should be documented and followed up at a later date to validate the scope. If the assumption is false, it may have an impact on the scope. Constraints should also be documented and reviewed regularly to ensure the continued applicability of the existing ones and to identify potential new constraints.

Definition of the scope can be done in various ways. The most prevalent methods are to define the scope by identifying the deliverables or by defining the functionality and data.

When definition of the scope is done using the deliverables method, it is likely that project stakeholders will not be absolutely clear on all the deliverables, and you will need to make generic assumptions. For example, you might not know exactly what views will be required, but you allow for five unspecified Project Center views and three views for the Resource Center.

The other approach is to define the scope by definition of the functionality and data. The process is likely to capture what end users expect to see in an EPM system. The goal is to get the end users to formalize their requirements for information in a structured manner. This approach does not capture data that may be required to technically make the system work but does identify what the functionality is that the EPM system must provide to the end users.

The project team puts together a preliminary project plan and a business case that is submitted for the organization's approval. The plan should include the preliminary project schedule, budget, scope statement, risks and issues management, communication plan, human resource management, and a procurement plan.

Recommended documentation for approval and transition to the next stage include project charter, gap analysis, preliminary requirements and solution target, and project plan.

When approved, the project should move to the next stage: planning.

Concept Phase: Planning Stage

The planning stage is marked by refining and finalizing the requirements and solution target document and the project plan with all its components.

The project team establishes what projects and functional departments will be part of the pilot deployment and what period of time the pilot will run.

This stage focuses on technical and business aspects of the EPM solution. An important part of the business process assessment is the necessity that the project team understand the organization's current project management terminology and processes.

During this stage the organization finalizes the technical requirements and initiates purchasing and/or redeployment of the necessary hardware and software. In regard to the necessary hardware, you must consider that the project will have a pilot phase and a production phase, and that the hardware necessary for the pilot may be different from the one required for the full production deployment. You must make decisions regarding the application architecture and consider alternatives and trade-offs related to hosting, single versus multiple server implementation, federation, and process implications.

This stage is marked by finalization of the design and configuration document. This document contains the functional data and technical requirements. This document focuses on items such as hardware and software configuration, user and group roles, security settings, categories, views, server configuration, calendar settings, required views for Project and Resource Center, Portfolio Analyzer views, time capture, use of administrative projects, and so on.

During this stage, the EPM project team must establish a feedback mechanism to capture items that need to be reviewed and/or modified. These items include installation and configuration settings, procedures, guidelines and instructions, and roles and responsibilities.

The project plan also includes plan items for the organizational rollout of the system. The same methodology that governs the pilot deployment applies to the organizationwide deployment. The EPM project management team must also document the strategy for deployment. One of the most important aspects of successful deployment is having the discipline to document key elements of the project.

Recommended documentation for exiting this stage and transitioning into the next are the final configuration and design document and the updated project plan.

Prototype Phase: Design and Development

This stage is marked by the actual build of the system and the configuration of Project Server 2003. This is the time when you install the hardware and software and configure the system. It is important that when you install the system to keep a log of all the steps and actions performed (installation log and notes). This can be helpful in case the installation is not successful or in case you need to debug certain aspects. It also serves as the baseline for the system and may help you in identifying potential areas for improvement in the future.

The project team must develop at this stage a testing and verification checklist. This document contains items that need to be monitored, tested, and verified during the next phase.

At the end of the prototype phase, the deployment team should have the EPM system built according to the configuration and design document, and have an updated plan for the testing and verification stage of the prototype. Also at the end of this stage, all users who will be part of the prototype verification and testing must be properly trained in the use of the system.

Recommended documentation for transitioning to the next stage are the installation log and notes, the configuration and design document (reviewed and updated, if necessary), an updated project plan, and the testing and verification checklist.

Prototype Phase: Testing and Verification

This stage is represented by actual use of the system in real life. During this period, the project implementation team meets regularly to assess the system and its use. The checklist of items that need to be monitored, tested, and verified represents the main point of reference for the general health of the system.

Also, during this period some changes will need to be made immediately, whereas others can be addressed at the end of the pilot, as a group. The reason for addressing these changes at the end of the pilot is that by then all users and stakeholders will have gained a better understanding of the system and will be in a better position to assess various changes and their impact.

During the prototype stage, the project management team should review the organizationwide rollout plan and submit it for approval of the company leadership. This plan must start with a production pilot and continue with the full production deployment. The production pilot stage is needed to ensure a transition period where the organization is getting ready for deployment and when all the procedures and methodologies are aligned with the business goals of the company.

After the prototype period has elapsed, the EPM deployment project team should review the operation of the system from a technical perspective and from a functional one. The technical review should include aspects regarding hardware performance, networking issues, and interface with other systems. The functional review should tackle issues such as mapping of business processes in the system, security rights and privileges for different groups and users, review of categories and enterprise views, and so on.

Any procedures and methodologies developed for this phase should be aligned with the corporate standards and business processes and document best practices.

Recommended documentation at the end of this stage includes the final design and configuration document and an updated project plan.

Pilot Phase: Pilot Production

This is the last stage before the EPM solution is fully deployed to the entire organization. You have two options here: You can either deploy the system all at once to the entire project management community of your organization, or choose a phased approach where each project team or functional department is brought into the system sequentially, one by one.

There is no good or bad approach to the full production deployment. Both approaches are valid and can be used successfully. The decision for one option or the other depends on multiple factors, such as corporate strategy, training plan for all users, availability of resources and support, and so on.

The focus of this stage is to validate the hardware, network configuration, and security settings. At this point of the deployment, the system should be stable and fully configured from a business model perspective. The deployment team may consider items such as server configuration and performance characteristics to ensure a proper maintenance procedure for the SQL server, monitoring the growth of the SharePoint sites, and so on.

One critical item for this stage is the development of the corporatewide training and support program. Training for end users should be scheduled according to their role:

  • Executives Managers in the executive ranks of an organization are often much occupied, and trainers should look for strategies to accommodate executives' busy schedules and to provide training without exposing potential gaps in the use of technology.

  • Portfolio managers These people focus on how individual projects combine into a composite of projects and have a specific set of training requirements, such as portfolio modeler and analyzer.

  • Resource managers Usually, members of this group are focused on allocating individual resources to various projects. Their key concern is to understand whether resources are allocated properly, what is the future demand for their function, and what trade-offs are available to them.

  • Project managers These people are typically involved in tactical activities linked to their projects. Members of this group must be provided with quality training to ensure that all features of the system available to them are adequately used to reap the great value provided by an EPM solution.

  • Project team members This group must be trained to use the collaboration features of the system and to perform the update functions required by project managers within project schedules.

At the end of this stage the recommended documentation for the project team includes the updated design and configuration document, the training and support plan, system hardware specification, and an updated project plan.

Launch Phase: Production Deployment

This stage represents the culmination of the efforts of the project team. Usually, this is the time when the Project Office takes over the responsibility of the system maintenance. The EPM implementation team ensures that all the users are properly trained, that the project implementation documentation is properly handed over to the Project Office team, and that the system performs according to specification.

It is not unusual to have some glitches, but most of them should be easily rectified with minimum inconvenience to users.

From this point forward the Project Office regularly checks the project database (Project Server) to ensure that the following occurs:

  • All projects are properly scheduled and are updated regularly to reflect reality.

  • Projects and tasks have adequately progressed.

  • Each project task is properly resourced, understanding that any task may have one or more resources assigned. These resources may be generic or specific names.

  • Costs are properly allocated to tasks.

  • All project schedules must have a baseline and be updated periodically. Use of Work Breakdown Structure must be enforced and used consistently.

  • All projects in different portfolios are grouped in the views based on basic health checkpoints and relevant groupings, such as location, percent complete, budget and schedule indicators, and so on.

  • A change against the system configuration or a service pack or any other activity that effects a material change that directly or indirectly affects system behavior will be proposed and communicated to all Project Server implementation and maintenance teams. This includes but is not limited to systems administration, desktop deployment, SQL administration, systems security, operations, and training.

  • A proper maintenance backup plan is in place, and the backup media is usable.

  • All updates and service packs are properly applied to ensure proper functioning of the system.

At the end of the production deployment stage, recommended documentation includes the final design and configuration document, system architecture, and maintenance plan.

Post-Launch Evaluation Phase

After the system has been deployed in production to the entire project management community, the Project Office oversees the implementation of those methods and procedures that are most needed and are critical for the success of any project.

The PMO seeks out and "institutionalizes" best practices from within the organization, from consultants, and from industry symposiums and user group conferences.

Improved efficiency and accuracy in project plan development can be obtained by the development and utilization of methodologies that provide project template and estimate models for different types of projects. As projects progress, the PMO checks the "health" of the project by reviewing the details of the project plan so that deviations from project objectives can be corrected before serious impacts to the project occur.

The PMO takes responsibility for a professionally trained force of project managers. This should be accomplished through project management concept training leading to Project Management Professional (PMP) certification, EPM tool training, and training in soft skills such as leadership and team building. A close working relationship must be established with the Human Resources and Training departments.

This stage is marked by an evaluation of the project and the official handover to the Project Office of the EPM system. As an organization, you should obtain feedback from all stakeholders and document all lessons learned.

Capturing EPM Feature Requirements

Capturing the EPM feature requirements is an important step in making sure that the organization designs a good, solid system, capable of responding to the needs of the project management community.

It is important to understand that all EPM stakeholders must participate in the gathering of feature requirements so as to make sure that all relevant functions are considered.

These requirements must be captured and properly documented. The document may contain the following elements:

  • Purpose of the EPM solution

  • Problem definition

  • Business objectives

  • Initial approach

  • Assumptions and constraints

When capturing the requirements a number of items should be carefully considered:

  • Enterprise Global template settings It is important to define these and make sure that all stakeholders agree because these settings determine the look and feel of the project schedules for the entire organization.

  • Calendars and Resource Pool settings Determining enterprise settings for project and resource calendars is paramount because this affects the scheduling and leveling calculations performed by Microsoft Project.

  • Enterprise Custom Fields and Outline Codes The primary goal for developing a coding structure within the Enterprise Global is to create attributes that are helpful in searching, finding, and selecting projects and resources. When considering development of custom fields and outline codes, focus on the key attributes. It is not necessary to create an exhaustive list for each project and/or resource. It is only necessary to cite the attributes that will assist decision-making when it is time to search, group, report, and select projects and resources. Also, avoid duplicating nonessential project or resource information that can be found using other sources (telephone numbers, office cubicle locations, and so on). During the process of defining these global code requirements, the deployment team must consider which project and resource attribute codes should be mandatory. Project 2003 allows for the required entry of some types of project and resource codes. The benefit of requiring an attribute code entry is that all projects or resources will be treated uniformly and consistently.

  • Project schedule templates definition Project templates used for scheduling purposes must align well with the methodology in terms of tasks and milestones, and must have generic resources assigned to tasks. Also, the schedule template should contain linked tasks and recommended durations.

  • Time reporting processes Project 2003 could have the greatest impact on people who have not maintained detailed records of activities in the past. They will be most uncomfortable with using the system because they must be more precise in every aspect of their daily work habits. The largest change may appear in the way project schedules are structured and how people track and report the time they spend on daily working activities.

  • Versioning and baseline requirements This represents, in many organizations, a strong cultural shift because it must be synchronized with the organization's project management methodology that defines when a project should be baselined and who has the authority to change it.

  • Reporting structure and how data should be displayed Ultimately, a good implementation of an EPM solution means that all reports created are accurate and meaningful to the stakeholders. In other words, a good report helps translate the data existent in the system into useful information for the user.

It is important to understand that every organization has specific needs and requirements for deploying an EPM solution. Nevertheless, following a documented and structured approach to the definition of feature requirements is always a good and recommended practice.

Communicating the Implementation Strategy

It is unanimously accepted that communication plays a major role in the life of any organization. When an organization decides to deploy an EPM solution, it is important that the project implementation team develop a responsibility assignment matrix and a communication plan that will be reviewed periodically for accuracy. Communication is of the utmost importance in every stage of an EPM implementation. The mere acts of communicating and listening will be interpreted by employees and stakeholders as a form of respect, which alone causes a great deal of value through a shift toward more positive attitudes.

The project implementation team must understand that deployment of an EPM solution also involves a strong cultural shift toward a more disciplined organization.

After the EPM implementation project is approved, it is important to establish the project management team and to assign the roles and responsibilities for each team member. These roles must be communicated to all stakeholders together with the project plan.

Project management team members are responsible for ensuring proper communication with the other team members and to the rest of the organization, within the appropriate limits dictated by the project implementation communication plan.

Following is an example of roles and responsibilities when communicating the implementation strategy:

  • The project sponsor has the ultimate responsibility for the success of the project and fulfills the role of primary liaison with the leadership of the organization.

  • The project manager has the responsibility for daily management of the project, ensuring that all interested parties stay informed at all times, and also ensuring that appropriate actions are being taken, as planned or in response to an unplanned event.

  • Project team members are responsible for checking regularly with project managers to ensure that all tasks and issues are resolved in time.

  • A communication specialist advises the project team on methods and ways of communicating within the project team and with the rest of the organization. Usually, this role is fulfilled by a member of the Human Resources department.

Communication of the EPM implementation progress must be done regularly in a structured manner. It is important to understand that communication of the progress to the organization must be done by only one individual. This ensures that everybody receives the same coherent and coordinated message. Having two or more people communicate the progress of the project or its strategy may lead to confusion and ultimately may significantly delay the implementation schedule.

A good communication strategy is part of ensuring a successful EPM implementation and must not be overlooked when planning the deployment.

    QuantumPM - Microsoft Office Project Server 2003 Unleashed
    Microsoft Office Project Server 2003 Unleashed
    ISBN: 0672327430
    EAN: 2147483647
    Year: 2005
    Pages: 227
    Authors: QuantumPM LLC © 2008-2017.
    If you may any questions please contact us: