Skip to content
PM Certification
Search
Generic filters
Exact matches only

Project Management vs. Services using ITSM Tools

Abstract: This article identifies some risks in the project management for software development projects in which, some tasks, must be executed by people who work  under an Itil service that is based on a ITSM tool.

Context

The main difference between project execution and service execution relates to the target definitions of these activities.

For PMI a Project is defined like:

  • “A Project is a temporary endeavor undertaken to create a unique product, service or result”.

For ITIL a service is defined like:

  • “A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”

Above the rest of the differences between both concepts, we are going to keep our eyes on the “unique” word that describes the project target but no the services.

The fact that the result of a project is unique causes a set of risks related to target viability and uncertainty, his costs, quality and execution time, that are incompatiblewith the service definition, where risks and costs are left out.  In other words since the project seeks a unique result, never made before, it could turn out that it could not be carried out in the terms, scope, costs, quality and execution time initially arranged. Services, however, in most cases based their execution on the repetition of tasks, normally, already known looking for both costs and risks are bounded.  This and other differences between services and projects in turn make the difference that exists in the way of work of the people dedicated to execute services and the people dedicated to execute projects.

It is common that the dedication of people to projects are 100% from the day they join the project until the day they leave; in this way it is achieved:

That the person focuses his attention on the specific tasks that the project planning assigns him, avoiding distracting his attention among other projects.

Planning to contract and reduce time to obtain the result.For services, however, it is common for people to dedicate themselves to one or several services provided for one or several clients, in this way it is achieved:

  • Optimize costs.
  • Take advantage of knowledge and experiences among Clients.
  • Minimize the risks of providing services.

In the world of IT consulting companies, not dedicated to product manufacturing, when we compare software development and IT systems we find an inverse distribution of the efforts dedicated to services and projects. Without having contrasted data, but based on my experience, software development consultancy companies dedicate over 75% of their efforts to new software production projects as opposed to 25% or less to the provision of services, typically, of maintenance or corrective. However, companies dedicated to systems have in their DNA the management of IT services, where the execution of projects serves to build or implement the systems on which the subsequent service is usually provided, reversing the percentage, and dedicating over a period of time. 75% to service and below 25% to projects.

These proportions are due to the way in which, in general, both branches share the IT problem:

On the one hand, the software development focuses on the construction of new and unique functionalities that engage with the execution of projects; and on the other hand, these new functionalities, once developed, have to be put into production, to serve as if it were a utility, according to an SLA (8×5, 24×7, etc …) guaranteeing performance, backup, access, etc …, through compliance with service level agreements to be provided by an IT services company.

As a conclusion of the above, we clearly identified a service approach of IT systems companies versus a project approach of software development companies.

How does link project execution, when any resources are provided by an organized team as IT services provider?

Risks that we find: “Create a ticket”

My experience in software development as a PM in this regard, usually, and after identifying a need related to IT Systems, have started with the following sentence: “Create a ticket”.

The scenario to which I want to limit this article is the following:
Execution of a software development project that requires specific IT Systems services, both to execute certain small blocking requests and to resolve incidents.

The following sections highlight situations that, based on my experience, are repeated in the proposed work scenario:

Divergence with Client expectations

The most serious situation that the PM should identify in the first moment is that the way of execution of the defined project, according to the needs of the client, does not link with the way in which the IT Systems service is provided. This generic divergence can occur in various areas such as:

  • Difference of criteria between the SLAs of the service and the definition of the project.
  • Impossibility of face-to-face assistance to the client’s facilities.
  • Documentation provided by the IT team compared to those needed for the project.

In all these cases, and in many others, the PM must identify these differences and manage the Client’s expectations or achieve particular changes for the execution of the service, so that both parties are aligned.

Communication problem of the issues

It is essential to evaluate if it will be enough with the use of the ITSM to communicate the need (request or incident) that we want to transmit.

A priori these tools provide traceability, information integrity and other advantages over other usual mechanisms of written communication. However, the written communication with a group of people in charge of a service, instead of directed to specific people, to whom each PM usually Knowing how to treat, depending on their specific qualities, can cause information to be lost, due to factors as diverse as, training, specialization, character, work shift, etc.

As an alternative to communication, it has always been useful for me to launch face-to-face or virtual meetings, which allow us to highlight the most important aspects of the information to be transmitted in the nuances of spoken language.

Border problem between development SW and IT: responsibilities

Many times I have found problems, incidences, technical definitions that dance on the edge of the border between Software and IT Systems and whose solution in many cases requires cross profiles of both parties that come to overlap and cover the required technical scope and is not exactly Sw Not exactly IT.

As a PM, one must be able to identify this type of situation in order to seat key people from both sides of the border so that they can agree on the way to face the technical solution.

It is worth mentioning that the organizations according to the Lean IT model must conform more T-type profiles to the detriment of type I specialist profiles to solve these increasingly common border problems. 

Transfer between groups of action problem

Another common situation that links in part with border problems is that, depending on the company and the ITSM implementation, there is sometimes a ping-ping of requests between departments or service provision groups. The ticket travels from one area of the company or another without being resolved.

It will be the function of the PM to identify this type of situation and to talk with the parties to define which side the ticket should fall on identifying the responsibility of each department, or if on the contrary it is a frontier problem of responsibilities such as the one mentioned above. 

Two bosses Problem

The definition of the scenario, that is the subject of this article implies, at least, that there will be a group of technicians under the control of a service, and therefore, under a services manager who will work on time for a project, with its corresponding project manager. To this initial approach can be added, depending on the type of work and organization of the company, other dependencies, for example, by technology, geographic locations…

It will be the job of the PM to coordinate with the different responsible parties the interests of the project and the service, anticipating conflicts derived from the dedication, the technicians’ involvement in other tasks other than the project. The most desirable situation would be that during the development of the work the technicians become dependent on the project manager. 

Lack of IT impact knowledge Problem on the real needs of the client

When the business and functional knowledge of the Client’s needs does not reach the technical areas involved in different tasks, two easily translatable problems can be presented in economic terms that affect the value chain:

  • Waste of resources on tasks of less importance for the Client: for example, attention of alarms after hours on needs not valued by the Client.
  • Lack of resources for the really important needs for the Client. In the definition of the scenario we find that a project requires a specific service, therefore, it is expected that those who provide the service do not know the global needs of the client. The project manager must make the necessary effort to communicate what is important and what is not, so that the service focuses its efforts properly.

Conclusions

The risks presented in the proposed scenario must be resolved by evaluating cost / effort between two alternatives:

  • Execute the request / incident according to the IT service as it is normally executed.
  • Break with the execution of the established IT service and request the execution of a mini-project facing the request / incident shorten the usual techniques of project management.

The art of the project manager should be to identify the indications that make it possible to decide which alternative to take and avoid wasting time starting as an IT service and ending up having to execute the mini-project.

The indications to be able to determine which option to choice could be:

  • Problems occurrence indicated in the previous chapter.
  • Previous experience and lessons learned.
  • Risk/Impact of the request/impact on the project.

error: Content is protected !!