A project management office is often associated with just the management of projects, but in this article the case will be made to broaden the scope of a Project Management Office to encapsulate the entire services business and will explain the reasons such a structure is necessary.
How a Project Management Office is commonly Defined
Historically, the purpose of a Project Management Office (PMO) is to deliver a project on-time and on-budget through the use of project management best practices. A PMO manages all aspects of a project including budget and resources. Organizations that don’t use PMOs will often find variability in how projects are managed and a lack of consistency in the delivery of quality projects. Often PMOs come into existence through organizational frustration with current project success.
Why a PMO needs a different organizational structure
When organizations are looking to implement a PMO a common question is: Should we establish the PMO and place various technical resources in that PMO and thus creating a new services organization? Or should technical resources stay within their current functional organization and only have the project managers housed in the PMO? In other words just set up a project department.
Project work, such as in the IT services business, especially projects for outside customers, is much different from standard IT work. First, internal projects often have a definitive delivery schedule but often the deadline is flexible, depending on when resources are available and unlike external projects, there are no contractual obligations for an on-time project completion. Second, internal projects, if using internal resources, will be of a size and scope that internal resources can handle. External projects, on the other hand, can be quite large in size and may require many resources
In order for a PMO to work effectively management at the executive level has to make a decision to shift power and authority from functional management and create a service organization with decision making authority given to project leaders. To place a PMO within the current management structure can and will cause conflicts. The resources need to be available to do work on a project as the PM sees fit and not negotiate with the functional manager every time the resource is needed. By using a functional management, bottlenecks can often occur (e.g. having the same engineer work on multiple projects), versus an engineer that is assigned to a project in a PMO and only that project. The financial penalties and the assigning and managing of resources variable size projects dictate a project structure is enacted.
How to Design a PMO
The creation of a PMO starts with a holistic approach to the services business covering all aspects from sales to project delivery to operation. There needs to be a high-level person in charge of putting together the entire process and aligning personnel (responsibility/accountability) to the project structure. Someone of a lower stature would be ignored.
The first step is to set objectives that transcend individual functional areas. Joint ownership in project success is required whether the participant is from sales, the delivery organization or operations. Everyone has to have a vested interest in the project being sold, delivered and managed profitably.
Let’s talk about the organizational structure and use the example of a company is in the services business of designing and deploying voice/data networks. It will need engineers with Cisco, Avaya and Microsoft certifications and expertise and these engineers will be categorized into broad pay scale bands based on their expertise and accreditations. These engineers are placed in a pool and are assigned to a project as needed by the project manager. Assigning means they are attached to the project and are not available to be used on other projects, unless the PM agrees. The project manager directs all the activities that need to be done by the engineer for the project.
However, administrative issues (vacation, reviews, and sick days), will still need to be addressed. In order to not take time away from the PM (and thereby take away time from the project) an administrative manager is used. Often this administrative manager (also called a resource manager) will support a group as large as 100-150 engineers. This resource manager will track vacations, sick days, time entry, etc. In addition, there are three main areas besides administrative the resource manager addresses and this where they really add value to the organization. 1) Is determining when additional resources need to be added to the team and 2) when skills of existing resources need to be upgraded and 3) when new skills need to be added (e.g. social media consultants/engineers) to the current set of resources. The resource manager forecasts resource requirements based on current project load and sales that are in progress to determine when additional people are needed. The second area is addressed when the resource manager solicits feedback from the project managers and sales teams to determine if the skills set of the current engineers are adequate for the current projects and expected future projects. This feedback is used collectively to analysis the skills set of a particular type of engineer and is not used to evaluate individuals. Skill set evaluations will identify those set of engineers that need additional training classes to keep their skills current (or required certifications current). If skill sets need to be upgraded for that type of engineer, then the resource manager will work with the internal training department or a training organization, to craft education to fill this void. In addition the resource manager will determine, based on discussion with the sales and delivery teams, if new skills need to be acquired for the team to meet new project requirements or to have the talent available for new projects (i.e. new service offerings that require skills not in the current talent base).
How to Avoid Unprofitable Projects
The project management office determines the entire process for selling and managing of projects. Before a single project is sold, the services organization creates a business case for the service, defines the scope of the service, the type of skills needed to deliver the service and the activities contained within the service. In addition, the deliverables of the service are created and responsibility for the individual deliverables is determined (i.e. engineering, project manager, operations, etc.). Templates are created for each of the deliverables.
The sales and delivery process for a service organization would be established as follows: The sales team identifies an opportunity and as the deal is qualified, brings in a person that has delivery responsibility for that type of project. This person would be responsible for signing the contract along with revenue responsibility and project Profit and Loss (P&L). They are responsible for the entire project. Often in organizations this person is known as a Practice Manager or a Principal. But the sales team doesn’t just hand off the opportunity to a Practice Manager. Jointly sales and delivery make the sale. The sales team has be integrated with the delivery team with clear lines of the responsibility so the SOW gets created in a timely manner and all the necessary areas are addressed. Every resource needs to be aligned to and have ownership in success of a project.
Compensation for all involved parties has to be tied to successful completion/operation of a project, which means the project is profitable. The compensation package for sales cannot be based strictly commission on the sale of a service. A large part of the compensation has to be successful delivery of the service, whether the project is a 3 month deployment or a 3 year outsourcing deal. By paying compensation over the duration of the project, the sales person will try very hard to sign a profitable deal. The sales team may balk as such a type of incentive package with the argument “I’m not responsible for the delivery team and have no control over their success or failure.” A valid argument, however, sales needs to see it from the other side. How does the delivery team know that there have been sufficient hours written into the statement of work for all the delivery areas? How can the delivery team ensure that all the requirements have been gathered from the customer? Delivery can provide detailed input to the Statement of Work (SOW) and make sure the assumptions and project requirements are in sufficient detail for a well-defined scope, which can help mitigate risk. Without successful project completion incentives, there is no incentive for sales to close deals that can be profitably delivered. There are many valid reasons the delivery team needs to have joint responsibility in the creation of the SOW.
In creating a services business it is important to take a project approach in building and compensating the organization. By designing the service prior to selling it and thereby determining the deliverables and the associated costs, an organization has a much better chance of selling and delivering profitable projects.