IT services. Materiel - Part 5. Not all projects are the same projects

The subject areas of services and management in IT are quite complex and non-trivial. This difficulty is due to the intangibility of most items in these areas. Despite this, for some reason people use very simple approaches to classifying objects. Literally for several attributes.

This is exactly what happens with the concept of "project." If there are restrictions on finances, terms, and this is done once, then everything is a project! Let's stick project management and everything will be fine!

But it won’t be good, especially if it’s a “software development project”. If any activity by interested parties is perceived in this way, then this is NOT a project and / or project, but with huge disappointments and pain in the end.

What is a real project?

I look at the concept of a project through the eyes of PRINCE2. According to PRINCE2, the project has 3 categories that generate one another category of what is useful that arises during the project:

• Immediate " final products " at the output of the project (Outputs). This is all tangible that will be created within the project and transmitted to users. For instance,
  • "Software for process automation";
  • “Updated process work instructions”;
  • "A working process automation support service."
• " Outcomes " of the project (Outcomes). These are the results of changes in reality that have occurred as a result of the use of the “products” of the project and activities within the project. For instance,
  • "An increase in the average number of orders processed per day by 10%."
• " Benefits " from the project (Benefits). These are the measurable benefits (income, savings, market share, etc.) that were obtained as a result of the fact that the reality after the project became different. For instance,
  • “10% reduction in the cost of order processing”;
  • "Increasing customer attractiveness due to 10% faster order processing time."

In other words, the present project is always an organizational change, and the link “products - end results - benefits” should always be in sight. And organizational change can truly only take place from within the company. Accordingly, only a temporary organization, the management of which is located in the recipient company of the benefits and final results from this project , can be called and understood by this project . In fact, the company gives the manager of this project the authority to change it (the company).

The project should be called, first of all, according to the final results. Accordingly, what is understood as a “software development project” that exists within the recipient company should, for example, be understood as:

• project to increase process productivity through automation;
• project to create a new line of business around the software product being created

or something else, in accordance with the project being developed, the possibility of obtaining benefits.

What do you think is so much in common between the above two “software development projects”? I hope that the difference is clear, and that the phrase “software development project” will now sound like a “hammer assembly project” for you.

There should not be projects that create software. These are great projects for software developers, but terrible projects for business. The project should implement a change in business, changes in the behavior and / or ways of people working and, before completion, demonstrate a measurable positive effect. A large number of people do not like changes, and any innovation will cause them resistance. And for any real project, this is one of the biggest risks, without which the project should not be closed.

And then what do custom software companies do?

And they are engaged in activities that are classified as “ in a row ” under the Civil Code (CC) of the Russian Federation . Unsurprisingly, a contract also has a time limit, finances, and is usually done only once.
I highly recommend that all developers of custom software read articles 702-729 of our Civil Code .

Accordingly, what is called a “software development project” that exists outside the recipient company is nothing more than a “software development contract”. It is for this reason that such activities should be formalized in a work contract, and, for example, not in a service contract.
Below is a comparative table that will help you better distinguish between “project” and “contract”.



At its core, a contract is a professional service for IT projects. And it should be managed, first of all, as a service.

If the project organization is not formed on the side of the recipient company, the chances of the project failing increase markedly. A contract is NOT a real project and a contractor cannot effectively do the following things critical for the success of a project:

• identify all stakeholders, especially in large business;
• timely response to business changes;
• To propose changes that will be combined with the company's strategy and other projects;
• motivate or force employees of the recipient company to do the things necessary for the success of the project.

Since software development is an expensive and risky business, a contractor company can start a surrogate project within itself. But everyone should clearly understand that such a project is by no means a replacement for a normal, full-fledged project on the side of the recipient company. The "galvanic isolation" of the service is not going anywhere that they will call the project ...

What a real project looks like

A simplified model of the design organization according to PRINCE2 is shown in the diagram below.



As you can see, the contractor is also a participant in the project, but a real project is much more than a contract.
On the other hand, in order for the contractor to be the most effective participant in the project, it is necessary to make efforts so that he understands the essence of the project for which he is developing a product, as well as know what is happening with other participants.

ICL Services Case Study

Project to improve the brand image of ICL Services and create a lead channel through the website. In fact, it was briefly called inside of us as “creating a site”, but it was a project activity organized correctly from the perspective of PRINCE2. We had our own internal project manager, who distributed a large number of tasks within the company, managed a contractor and organized the interaction of all participants and stakeholders.

The creation of automation and visual presentation of the site was done by a third-party contractor. Despite the fact that the contractor was probably busy all this time, to me, as an ordinary participant and non-ordinary stakeholder of the project, this was almost not noticeable. Moreover, the work on our side was in full swing.
As part of this project, in addition to that created by the contractorThe site was made at least:

• a large number of materials in Russian;
• lead development process with documentation and allocated resources;
• processes for updating the materials and content of the site, both in marketing and in the HR field.

In addition, the entire top management was involved in the acceptance testing (validation) of the site. No matter what quality testing (verification) is organized by a contractor, the final validation can be done only by those who have to use the software and / or be responsible for it. The project ended significantly later than the acceptance of the site as a result of the work of the contractor. He finished after accepting the site as the final product of the project .

As a result, at the output of the project, we received not just a web application available from the Internet, but a working tool woven into the company's processes.

No contractor will do this for you. Not a single contractor will be able to motivate or force the use of the employees of your company to use the system developed by him as efficiently as possible. This is your work that is worth doing within the framework of this project.

Sources:

1. Managing Successful Projects with PRINCE2®. 4.2 “Business case defined”, 5.3 “The PRINCE2 approach to organization”
2. The official Russian-language glossary of PRINCE2®