🤷🏾 🧑🏾 🚮 Design technologies for the implementation of billing systems for corporate clients (part 1) 🤛🏿 🙏🏼 ☝🏿

Yes, everything has been written 100 times about project management

It’s absolutely true that unless the lazy have written about project management using different methodologies. Therefore, we will not discuss general situations and the delights of different methodologies. But we’ll tell you about several cases when the risks worked, despite the use of some of the project management methodologies, and how we got out of the problem situation.

Typical difficulties

First, the main and most interesting - about the problems from the point of view of the contractor-executor of the automation project. All methodologies should help get rid of problems even before they - difficulties - arise. But in life this does not happen.

Here are the typical difficulties that we most often encounter in projects:

.
, , - . , . , , , , .

, , , Forward, - - .
CRM- .
CRM , , . , CRM, .

, , , , . CRM . , CRM - , : « / ?».
«» open-source .

- IT-, , . : “ open-source, ”, — , . - « , !»

. , - , , . open-source , - . , 1 .
Expectations by timing.
Previously, the choice of information systems for billing was carried out by the IT-service of the enterprise. Now more and more often the choice is made by the units responsible for sales and marketing. The lack of a technical background, the spread of cloud services and the growth of general informatization of life create the illusion of simplicity. No one thinks that for the current comfortable work in the free for ordinary users Gmail resources of a huge organization have been expended for many years.

Therefore, we constantly hear that the expectations for the timing of the implementation of billing are 3-4 months. It is rare that a customer estimates the amount of work at six months or a year.

If I were to compile TOP subsystems with which various problems arise in complex projects, then these would be:

CRM
Service Desk,
Technical accounting / inventory.

Now let's move on to three small and slightly exaggerated cases. All coincidences with real persons are considered an accident. Not a single platypus was injured in the production of the film.

When the waterfall reverses

Once upon a time there was an Internet provider, and not a simple one, but consisting of many legal entities that provided services in different cities. In each city, a legal entity had its own historical billing, support, local leadership and much more that a business needed
.
So they decided in the main legal entity of the provider to combine all into one system, consider money and traffic in one place, and not leave it to separate historical systems. To crank it all up, the glavurlitso launches a tender and selects an automation supplier.
We study the tender documentation. We see that we meet the requirements, participate in the tender and turn out to be happy winners.

Problems begin

And then the fun begins. It turns out that the main director wants to immediately contract the project for the entire legal entity, to fix the terms and the total budget tightly. Clear water classic waterfall looms.

We communicate with the staff responsible for the tender, register the BPI (basic execution plan) of the project, study the provided detailed information and fix all the requirements documented. A bunch of papers signed, we enter the project.

And we are faced with a brutal reality in the form of a mismatch between the previously provided documentation and the real situation on the ground in the cities where the provider is present. We get the risks worked:

Stretching the terms of implementation.
The increase in project labor.
An incomprehensible degree of responsibility of the tender organizers in a situation where they do not manage historical systems on the ground.
Lack of interest in switching to a single billing in local legal entities.

Restart

The obvious gap between the formal requirements and the actual situation in the cities where the provider is present forces us to recount the terms and budget. Provide this information to the customer. At the same time, we include additional labor costs for the study of historical systems in the budget.

We have to conduct a lot of negotiations with representatives of the parent company. We are bargaining. The parent company really wants a single billing, so there is an amicable signing of an additional agreement for each city.
The overall result of the project is positive. The difficulties at the entrance to the project were resolved, the transition to a new single billing for the group of companies went without incidents.

Following the classical methodology did not help to identify the shortcomings of the statement of technical requirements, and required a complete revision of all agreements with the client and rewriting of all project documentation.

Pull on the vine

A client came to us who wanted to launch his virtual operator. We calculated the project of launching MVNO of varying degrees of independence from MNO. The client considered the project as a diversification of the business and did not have sufficient experience in telecom. The budgeting of the project was planned to be carried out on the basis of released funds from the main business. At the same time, the owner wanted to work exclusively on Agile, considering this methodology as progressive as possible and suitable for starting a new business.

It was decided to split up the tasks of launching the operator into small work quanta and work on sprints, attracting available resources for each sprint that are sufficient for developing the budget. Activation was supposed to be based on the results of the sprint.

A result came out that we won’t be proud of. Problems that were initially predictable showed in all their glory:

Instability of receipt of funds for work.
The time lag between the appearance of the budget and the allocation of specialists for budget development.
The temptation of the owner to spend the funds accumulated for the project instead of waiting for the end of the sprint and payment of the act. As a result, the time lag between the end of the sprint, the signing of the act and payment.

Over time, the owner's interest in launching a virtual operator decreased, and at some point, the implementation of sprint work was first postponed for an incomprehensible period, and then completely canceled.

The exit from the project, therefore, is also the result, although not positive.

Without sufficient customer motivation to achieve the result, a flexible methodology can only minimize our unactivated and unpaid labor costs. But working in this mode greatly dampens and distracts resources from the implementation of more cost-effective projects. This is a negative experience, and we will not launch projects with similar conditions.

Agile with time, budget and functionality limitations - WTF ?!

Yes, there is such a thing. The customer may want to work on Agile, but at the same time fix the deadlines, budget and functionality. For us, this causes dissonance.

For us, working on a pure Agile with a client implies that we provide a team, and the customer takes a significant share of the effort to manage the project. We are responsible for sprint execution and operational task management. The project manager on the part of the customer is actually responsible for the overall project result. Our experience says that it takes 3-4 sprints to get an acceptable result / MVP, test hypotheses on some functional area of a future information system. This is a fairly large time period and labor. And remember, we said earlier that the expected automation period is now 3-4 months? No, we generally do not mind, we can work with such a deadline, but not without the help of a client’s team.

The customer who perceives Agile as a progressive methodology, because it is heard a different understanding. He wants us to name a specific timeline, a specific budget, so that we manage the entire SCOPE of the project, but at the same time make it all happen “on the air”.

There are rarely customer managers who are ready to take responsibility for the results of the project. Often there is a substitution of concepts - almost a classic waterfall begins to be called an "Edge", only with presentations and displays of intermediate results every two weeks. And here we are smoothly moving on to the next case using the hybrid methodology.

Does Hybrid Save?

The situation is similar to the previous case - the owner wants to launch Full MVNO in addition to the main type of business. The client has tight deadlines, and the MVNO launch project is tied to several related internal automation projects.

The customer puts significant restrictions on the budget, the timing of the project and requires the integration of Forward systems with internal information systems using Oracle DBMS. In addition to this, as Full MVNO is launched, the purchase, installation and configuration of telecommunication equipment is required. Work will be in conjunction with the customer’s IT team and several teams of other contractors.

The project is starting, a very big load on our team. We have to work with refining, communicate very closely with colleagues. The composition of tasks in sprints changes very dynamically, the customer is involved in the project and flexit is no less a task than it adds.

The result of the project is positive. It was hard and very stressful, but the minimum functionality for launching MVNO was implemented as soon as possible, specified by the customer in the statement of work.

Tight time and budget constraints, high customer involvement and a flexible approach to the formation of a sprint task pool are a good reserve for the successful completion of the project. The key feature of this project is the synchronization of sprints of all teams launching an automation system.

What projects do we not take to work?

Low design literacy

For us, project literacy is expressed primarily in the presence of experience in implementing projects with client employees, functional customers, decision-makers, and RP from the client. We make an assessment at the stage of initial negotiations. We try to communicate with the DM and RP personally. If the experience is not clear from communication, then we can ask directly.

Sometimes the decision maker does not have an IT background, he poorly understands what software development is, the integration of different software with each other, but at the same time, the decision maker has many ambitions. Such a decision maker may consider that automation is simple, fast and cheap, and the vendor and integrator charge money for air. During negotiations, such an attitude is easy enough to see. It is important whether there are competent people in the environment of the DM and how they can influence the DM. If there are people with IT experience and the decision-maker listens to them, trusts, then this increases the chances that we will enter the project.

You can work with those who do not have project experience, but who are interested in the result, delve into the tasks and use the experience of colleagues and contractors.

You can’t work with stubborn, proud and deaf managers.

Inadequate Requirements

At the pre-project and TK stage, you can understand how adequate the requirements for the declared budget are. Inadequate attitude to terms, money is an important bell and management risks, which then will flow into project risks, because the customer’s expectations will not be justified. High-quality completion of such a project is very difficult.

The real case: they prepared a sale for a year, conducted a preliminary project, and prepared documentation. But the customer suddenly announced at the tender the conditions under which the risks of work were too great, and we refused to participate in the competition of suppliers. We lost a significant amount of time for preliminary work, but it was wrong to take risks and enter the project on the terms stated in the tender.

Another example: MVNO is launched, the requirements for the functionality of an information system are estimated at several thousand points. These requirements are compiled based on the experience of operators around the world and do not correlate well with the business conditions of this operator. In addition, the owners mean that the launch of MVNO is a kind of startup in which it is not planned to invest a large amount of funds. Our experience says that a list of 100+ requirements would be normal in this situation. To simply make out these thousands of requirements and give each answer with an indication of the documentation for the Forward platform, these are labor costs that won’t pay off, judging by the customer’s attitude to the budgeting of the project.

Low qualification of customer technical specialists

The qualification of the IT department of the customer is not a problem in itself, if this is sufficient for the functioning of the business. Problems arise when low-skilled people are hung up with critical tasks in an automation project, justifying this with the fact that "we have our own IT team, let them work."

If you are lucky, then as a result of the project, the customer’s IT department will improve competencies and cope with the tasks. But it may not be lucky. But it’s not always possible to talk closely with ordinary performers, to understand their abilities and motivation at the stage of initial negotiations.
Low qualification of the customer’s team is not a block factor, but this is a serious reason to think and re-evaluate all the conditions of interaction with the client.

The next article is about risks.

Large corporate projects are always financial and reputational risks. So we will release the second part of the article and talk about risks from the point of view of the automation contractor.

In the meantime, we invite you in the comments to share your experience about the difficulties and problems on projects!

Design technologies for the implementation of billing systems for corporate clients (part 1)