How not to waste resources and not regret the implementation of the software

Short description

The author, with years of experience in project sales for software implementation, switched to freelancing in order to avoid the constraints of working in a company. The article focuses on how to get the desired results from a software implementation project, specifically for small to large enterprises that require process automation. The first issue highlighted is neglecting the purpose of the project, with no clear goals or indicators of success. The importance of pre-project inspections and thorough reports are emphasized. The article also provides a case study of a company that refused a pre-project survey, resulting in a failed project with a doubled budget. The author promises to continue with more cases, both successful and unsuccessful, if the topic generates enough interest.

How not to waste resources and not regret the implementation of the software

Prerequisites

Many years of work in project sales for the refinement and implementation of software enriched the opportunity to collect and systematize errors and problem points of projects.

Since working in a company imposes a number of insurmountable restrictions, which often reduces the quality of work, I switched to freelancing. A little more free time appeared, at least for the transport component, which made it possible to share experience.

The subject of the article

How to get the expected result from a software implementation project.

Indent I

The article will have a lot of stones in the garden of IT specialists. That is why the platform for publication was chosen. I think this material will help you avoid unpleasant situations.

Boundary conditions

What projects and enterprises will be discussed. Automation of the company’s business processes. Automation of technological equipment is not considered.

Enterprises:

  1. Small. As a rule, the issue is solved by using “boxed” products with minimal settings. Project implementations are not required.

  2. Average. The presence of structural subdivisions, possibly branches. Regulatory documents appear. Several levels of management. As a rule, the functionality of standard solutions is no longer enough, and the processes of finalizing the software and its implementation are needed.

  3. Large enterprises. A project approach is almost always required.

  4. holding structure. If we are talking about individual enterprises – everything is the same as in P.3. In the case of inclusion in the project of the main managing company, as a rule, significant refinement is required. The only question is what we will improve: business processes or software.

  5. World companies. Most often with state participation. Apparently, they need a separate consideration. Procedures for decision-making and work performance control significantly affect all processes of project preparation and implementation.

As you have already understood, I am considering the companies mentioned in P.2 – P.4.

And finally, let’s get down to the topic of the article.

Origins Or where the legs grow from

A decision was made to implement the software.

Sometimes under the influence of employees – we are overloaded with auxiliary work, we can never qualitatively perform the main functions, or something similar. By the way, they are far from always interested in successful implementation.

Sometimes it is a voluntary decision of the management. Moreover, it is not always justified, it is simply accepted. Most often due to the loss of control over the process due to inadequate reporting.

Sometimes (rarely) at the initiative of IT departments.

In any case (most often) finding performers is entrusted to the IT department. Everything is logical, who, besides them, will be able to understand various products and artists.

And here is the first problem

We completely forgot about the purpose of the event. I deliberately do not write about the company’s internal processes for preparing requirements for automation. Such documents are usually available. Sometimes in the most general form, sometimes in the format of a technical task. Most often, they contain general requirements (copied from the previous one or the Internet), but goals and indicators of their achievement are almost never recorded.

Yes, the goals are described in a general way (such a section is in any document), but such a description does not give an opportunity to evaluate the success of the project implementation. Let’s put it bluntly, performers do not like the presence in the contract of conditions for achieving target indicators. But you, as a Customer, plan to implement a product for the success of your business, not for the welfare of software developers.

I will return to this topic more than once, so different aspects of this problem will be revealed in cases.

Pre-project inspection

Professional contractors will definitely offer to conduct a pre-project inspection. The options range from a full audit of business processes and the development of a general / private technical task (depending on the scope of the project) to a brief analysis of requirements in coordination with the owner of the business process.

Such work is necessary for both parties to the contract. The Contractor will be provided with a preliminary assessment of the cost of implementation, and the Customer will be provided with an understanding of the scale of the disaster, the necessary resources and, of course, complete information to make a decision.

The survey must necessarily end with a report containing, at a minimum, a description of the current state (as it is), proposed solutions, a description of “how it will be”, an implementation plan and, of course, an estimate of the necessary resources.

Retreat II

Directors of companies practically never know all the intricacies of implementing business processes. And this is not their task. Well, the director shouldn’t know, for example, in which direction and with what torque the nut somewhere in the bowels of the engine should be tightened.

Warning

The article will not mention names, company names, or any other personal data. Depersonalized materials only.

Case 1

Output data:

  1. 1. The company provides services to legal entities and individuals;

  2. 2. The order is executed within a few hours or a day;

  3. 3. A feature of the order acceptance process is the depth of execution with limited resources. That is, the employee accepts an order that must be fulfilled in 123 days. It takes 2 hours to complete the order. It is not necessary to describe the other conditions in more detail for our purposes. Otherwise, the company will be too recognizable.

  4. 4. The customer studied the market, but did not find a ready-made solution;

  5. 5. An employee of the IT division of the company is entrusted with selecting the executor, let’s name him H;

  6. 6. H conducted preliminary searches and selected a possible executor.

Realization

The company categorically refused the pre-project survey. Reason: H independently described the process, formulated the requirements and, importantly, they were approved by the director. That is, only an executor is needed to finalize the software according to the Customer’s technical specifications

The contractor, having studied the technical specifications, decided on the terms and cost of the works. The customer was satisfied with the offer, the contract was signed.

It’s time to hand over the release for test operation. Control run of the system with participation H and the management of the company did not find any defects.

The system is installed on the technical equipment of employees who did not know anything about it until now.

I understand that you already know what result we came to. Of course, it started with small, non-critical edits, but as a result, the neglected subtleties of the process buried the entire system. The implementation of all requirements required a significant redesign of the core of the solution and, in fact, a doubling of the project budget.

Result. Dissatisfied with each other, they broke up. The customer did not admit his mistakes and refused to change the project budget. The contractor refused to redesign the system at his own expense.

To be continued

Dear reader. This is a test article. If the topic seems interesting to you and there will be reviews and discussions, I will supplement it with cases, which have accumulated quite a lot. Both successful and unsuccessful.

Related posts