Project Management V Service Management Part 2

Last week I gave a talk on Project Management v Service Management at the IT Service Management Forum’s Conference here in Singapore. It wasn’t the best presentation I’ve done in recent years but the topic was a relevant one.

My most recent project, in the manufacturing sector, lasted 18 months and was not my most challenging from a project perspective. However it did highlight several areas that I come across on many projects, more vividly, than most.

The interface between Project Management and Service Management as it relates to the IT world, is broken. Yes, I know, we all know it, we’ve all known it for a long time too. In most cases Project folk like to maintain their unique role as special function and not be seen as art of a “service” organization.

Hey, I was like that too many, many years ago. It’s nice to be different from the crowd, have different responsibilities, and to be on a high profile job, like a major project. Well that’s all fine but it’s not good for the organization investing in the project and it’s a very inefficient way to operate. And here’s why:

Project Management v Service Management

Without a clear definition of the project deliverables that include the service management needs;

  1. customers requirements may not include support requirements resulting in the project delivering products and services that will not meet service and support needs.
  2. integration of change process between the two organizations is prone to problems and risks if not operated as one. This can and often does lead to clashes and delays as two organizations attempt changes relating to common infrastructure and operations.
  3. strategic business decisions that may influence the support model may not be fed into the project solution.
  4. project outcome may satisfy the initial requirements but be a nightmare for support services to manage and therefore prove a poor long term investment and not deliver to the business strategy 100%.
  5. handover of the project into an operational environment will prove more of a challenge than it needs to be.
  6. lack of “synchronization” between project management and support management will cause delays and increased costs against the project.
  7. Many process and procedures that the project organization need to use or interface with are inefficient for project work or are created specifically for the project and don’t interface or leverage the operational procedures that they need to become part of.

If you look at the ITIL model, the approach to the Service Life Cycle almost emulates the Project lifecycle at high level, in Prince 2. This is no accident. In business the strategies are discussed and presented. The design of a solution to deliver that strategy is worked out and then the solution is built. Once the new solution is in place, well, someone has t support it, don’t they?

It’s no surprise that the service management organization is key to the delivery of business strategies and in so doing encompasses a high degree of project management in the delivery f those strategies.

The link between project management and service management organizations is more like an intimate bond. So why is it missing in action in so many organizations?

I don’t have the answer here. I could speculate, based on many years of project management and service management experience. But I won’t, here, and now.

My message is this;

  1. Project scope and requirements must include the service management or support organizations requirements as well as the business needs.
  2. Management process and procedures that support a project should be aligned to operational procedures as much as possible. That means operational procedures need to be flexible and efficient in support project needs as well as operational needs. i.e. Procurement, Resource engagement, Financial reporting, Change Management etc.
  3. Project skills are not easily learned and are sufficiently different from a service management skill set that it pays to get experienced project managers on to major investment projects. However, never lose the opportunity to develop good service staff by attaching them to the project in assisting roles.

Project Management is about people, so is Service Management. Both have similar needs and common threads, both also require training and practice (experience) to become professional delivery agents.

Understanding Project Management and Its Relationship to Program and Portfolio Management

In this article we will discuss the activities involved and the relationship between portfolio management, program management, project management and organizational project management.

In addition, we will look at the role projects have in strategic planning and finally we will discuss the project management office and its importance.

Portfolios, programs and projects are all related and aligned to organizational strategy. In the same manner, portfolio management, program management and project management all contribute to the achievement of the strategic goals of the organization in different ways.

The various activities of these three areas all relate to the organizational project management (OPM). Organizational project management is the systematic management of projects, programs, and portfolios in alignment with the achievement of strategic goals. The PMI concept of organizational project management is based on the idea that there is a correlation between an organization’s capabilities in project management, program management, and portfolio management and the organization’s effectiveness in implementing strategy.

A program is a group of projects that are similar in scope, activities, and have similar subprograms. The purpose of a program is to manage the projects in a coordinated way.

Not all projects conducted within the organization will fall into the same program. however, programs will always have projects.

Program management involves providing the application of knowledge, skills, tools and techniques to the program in order for program requirements to be met.

Program management focuses on the co-operation between the projects to determine the optimal approach to managing them. Usually these projects are interdependent, for example having the same resource requirements, governance structure and similar strategic organizational direction along with this they may face similar issues and change management considerations.

Portfolio Management

The portfolio includes all programs, projects, and subprograms that meet a strategic objective of the organization. Programs and projects do not need to be related in order to be in the portfolio, the only requirement is to contribute the same overall strategic objective(s) of the organization. Portfolio management is the centralized management of one or more portfolios that will help the organization achieve its overall strategic objectives, it is concerned with all projects and programs, part of the management process is to ensure that all projects and programs have the proper resource allocation and that all programs and projects are aligned and support the overall strategic objectives of the organization.

Now we will look at projects and strategic planning

Projects should be created to directly or indirectly assist with the achievement of an organisation’s strategic objectives

Some strategic considerations which lead to projects include:

  • Market demand – Many industries are facing a time of change and great competition. It is important for organizations to recognize the needs of the market and respond appropriately. Because of the importance of responding quickly, effectively and cost efficiently projects are often initiated to address these issues or opportunities
  • Strategic opportunity or a business need – A project may be initiated to develop new product or service in order to expand the organization, increase revenue, or solve a problem that company is encountering
  • Social need – Projects are initiated to help a community or group of people solve issues the people may be facing.
  • Environmental considerations – Companies today are continually looking for new ways to improve their operations to be more “environmentally friendly”.
  • Customer request – Organizations are always looking for new ways to satisfy the needs and wants of the customers, so a project may be setup to meet a specific customer need.
  • Technology advances, technology continually changes, as a result the products, services, and operations of the organization must be continually improved to stay in line with trends, opportunities or threats caused by these developments
  • Legal requirements, organizations are required to follow and meet certain legal guidelines for their industries, project are often developed to meet these requirements.

The Project Management Office

A project management office (PMO) is a management structure that is used to standardize project processes and also allow for the sharing of resources, methodologies, tools, and techniques.

The PMO can be supportive in nature. In this role, the PMO takes on a consultative role to projects by providing templates, best practices, training, access to information and lessons learned from past projects. In the supportive role, the control level the PMO over the specific project is low

The PMO can also have a controlling role, in this role, the PMO would provide support and require compliance through various means. They include having standard project management practices and methodologies, using similar templates and tools. In the controlling role, the control level the PMO has over projects is considered moderate

Finally, the PMO can have the directive role. In this role, the PMO takes direct control of the projects in its remit. In the directive role the control level the PMO over the projects’ processes is considered high.

The PMO can provide a great benefit to the organization through sharing information, identifying and implementing common methodologies, training new project managers and coordinating across different projects.

The role of the PMO will be determined by the organization and the level of structure considered to be necessary

In general project managers are still in charge of their individual projects and PMO is concerned with establishing guidelines and providing support to all projects

How to Create a Successful Services Business Via a Project Management Office

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.

Conclusion

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.