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:
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.
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:
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:
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:
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.
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:
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:
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:
When capturing the requirements a number of items should be carefully considered:
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:
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.