False goals of the project team

The goal is a fundamental mechanism that has a direct impact on the structure and behavior of the system. Each module (participant) of the system can work within a single mechanism and receive its own benefit from it, but if each of the participants pursue their own goals, it will not be a system, but another fable from a famous author.
In projects of introducing third-party software into the enterprise information system, the problem of a single vision is particularly acute. In such projects there are usually many participants:

• A business that aims to maximize the benefits of implemented automation;
• A contractor whose goal is to gain material benefits from the implementation;
• Own development team of the customer, which seeks to minimize labor costs and responsibility;
• End users of the system who have the need to protect against changes.

And the difference of goals often leads to the failure of the product, “welded” in this pot of conflicting ideas.
In this article, on a clear example, we consider the negative processes to which inconsistent goals lead. The project considered in our case is the implementation of the ERP system.

Problem formation

Usually the first step in the implementation of ERP is the ordering of accounting units - reference data (MDM stage). ERP reference data is very capricious. If for cases of semi automated accounting, searching and comparing with the name in EXCEL is sufficient, then the ERP bowler requires unambiguous IDs. In addition, multiple input of reference data in various systems is a lot of effort. Based on the description of the problem, we have a common goal - “Create a unified reference data system (MDM) and clean up the maintenance of reference books”. But it is not clearly formed, and at this stage we are already confronted with a disagreement about a single goal:

• The business already considers how many people / hours can be saved by automating directories;
• The contractor is already preparing an estimate - this is a fairly quick profit with minimal labor costs;
• The development team is trying to "map" objects of systems with different data structures to minimize the improvements and trying to get acquainted with the new "foreign body" in its information landscape
• Business users are expressing more and more “helpers” to leave, as it was and not to break the existing processes, the justification “why you need it” is often difficult and in some cases make compromises

Short-term result

And even in this situation, the project team has worked perfectly. Passed design, development, testing. Almost met the deadlines and quickly stabilized. Business got used to the new system. We could put an end to this - with a great stretch the project could be called successful, but we forgot about the main thing. Namely, what really was the purpose of the selection of this stage?
After the introduction of the “data master”, the transfer of directories from a single MDM system to all potential users of this information was automated. ID objects of the system where you can have been synchronized. Where it is impossible - conversion tables are configured. The directories are synchronized, but so far no one really uses them because the accounting systems still work according to the old rules that are not very demanding on the accuracy of the reference data.

First fruits

At the next stage of the implementation of the ERP system (the documents began to be delivered), a misfortune happened, which has quite a lot of symptoms and their causes, but the root cause is the same. I will begin by listing some of the “symptoms” and their causes.

• It is impossible to remove reference data from current systems, and ERP decided not to pull the entire volume of directories. Therefore, part of the data remained without an ERP ID. And, as it turned out, reference data that did not have “links to ERP” were actively used by mistake, which made it impossible to process many documents.
• Some objects of the ERP system had a "lifetime". For example, in the ERP counterparty may be active and not active. It is not possible to create a document for the non-active counterparty, and they were created by mistake in the source systems
• The possibilities of ERP turned out to be much broader than the possibilities of LS (legacy systems) and the business processes that users promised not to use actively began to use in connection with the transition to new phases of the system life cycle. In other words, LS turned out to be less flexible with respect to ERP.

And there were a lot of such examples. And the original cause is the goal of the system .

Determining the cause of failure

Viewed from a retrospective, the goal of the MDM phase was to restore order in the company's reference data, because the very demanding ERP system will not miss more than one document with at least one section of curved data.
If this goal were set, then:

• The business would actively participate in establishing order in the reference data and related business processes.
• Own development team - would design a system with an eye on data structures and ERP business processes
• Business users would actively consult on future document handling processes and make constructive suggestions.
• Contractor - actively advised on the operation of its system, because it would be more requests from the business and IT customer

Effects

In large projects, we often face the problem of communications. I don’t remember how everything happened, but the goal was quite obvious for some time and was visible to everyone. At a certain stage, each team member is immersed in the work within his competence and area of ​​responsibility. At the same time, everyone performs their tasks quite efficiently and effectively.
After the implementation of the project and the “mopping up” of massive and obvious problems, the implementation team faced a period of stagnation. During this period, the system has stabilized on a certain amount of point problems, which are solved at best by “crutch” developments, and at worst by manual intervention in these systems. And no one knew what to do about it.
No, there is no super-hero in our history who made us return to our original goals and radically change the approach to certain things. The maximum that we managed to do was to consider new crutches through the prism of these goals and try to get people to act in the key “... a temporary decision was made ... we also strongly recommend to reconsider the approaches to the following processes ...”.
')

findings

1. Goals are the basis of the system and need to be taken no less seriously than, for example, documentation of interface specifications.
   I personally write them down in the architecture documentation and voice them during the presentation of my decisions.
2. Each decision should be viewed through the prism of goals and the goal of each project participant, at least, should not contradict the fundamental goals of the project.
   I write down how each decision implements the project objectives, how it came to this decision and what were the alternative solutions.
3. Often the goal is quite difficult to learn.
   But where the goal is clearly not described, I guess about them and coordinate them with all the participants.
   The purpose of this article is to acquaint the reader with a look at the obvious and rather poorly researched problem of large IT projects, and also to understand whether I am moving in the right direction in my reasoning and conclusions.