Everything is fine, we fall
Before you start reading, think about what kind of emotion does the mention of large companies evoke in you? Is it drive, innovation, movement, or, rather, bureaucracy, conservatism? Let's talk about where such ideas come from and what to do with it.
Under the cut is a dramatic story about an attempt to introduce a flexible management methodology in a large enterprise company .
This article is based on Dmitry Smolyarov's report at the Web-scale IT Conference 2017. Dmitry has been working in large holdings for more than fifteen years, in particular, he headed the IT department at RusHydro, and knows firsthand the structure of the corporate machine. His story will help to better understand the protocol of interaction with the enterprise-customer and will let you know how this protocol can be violated. Go!
')
First I want to tell one story. Once upon a time, as a young engineer, I arrived at one of the hydropower stations of our vast country with an ambitious task: in 3 days to include it in the common corporate space.
I met a wonderful person there, whose name was Nikolai Ivanovich. It was a strong business executive who reacted to my appearance something like this:
Indeed, everything is fine with him: everything is adjusted, everything works stably, IT systems are documented in detail (which is especially surprising), everything is stable. And suddenly, someone invades and offers a quick, unusual way for this experienced business executive to change everything. I met powerful resistance. It was a lesson that gave impetus to my understanding of what big companies need.
Why there is often no drive, driving and so on? - Because in large companies, other priorities and other values.
There are always a lot of risk factors and willing to join the company and “feed up” at its expense.
Often, we need not the most advanced innovations and revolutionary solutions, but a guaranteed result. Big companies just do not like revolutions.
Decision makers manage the capital of others and there comes a time when you need to explain your actions and answer for their decisions to the owners and regulatory authorities.
This has several implications for the implementation of IT systems, including:
Making decisions and passing control points is always accompanied by the preparation of reporting documents. This is the same reporting and the same documents that are most often associated with bureaucracy in large companies.
I understand you if you start yawning at this place. But I once again specifically draw your attention to the fact that daily life in large companies is always associated with this very “bureaucracy”, this is its natural component, and it always exists.
Traditionally, the contract is constructed in such a way that at each stage a complete result is obtained, which can be used in the future activities of the company, this result is documented. Examples of such documents are conceptual and technical projects, private technical specifications, test reports, and so on.
The availability of such documents is especially important for IT projects, which, as a rule, give rise to an intangible asset. And if you do not document the results, it may not even remain a trace: there is a certain server on which a certain system is installed, and this system does something. What was done, what the act was signed for and paid for is not clear. Therefore, the traditional implementation of IT projects in large companies is a consistent achievement of the results described in the documents. Each of which passes internally the coordination and the statement, is accepted, as the finished decision, and is paid.
This is somewhat similar to Agile, but has a different meaning. The division of the IT project into stages is done with the aim of improving manageability and protecting the client company. Unlike Agile, aimed at obtaining a result that best suits the customer.
The other side of project implementation is the behavior of customer managers. Among their priorities is the desire to confirm their own solvency and significance, to preserve their place and make a career. That is why customers very often try to reduce risks and guarantee a result . This imposes certain features on their behavior, both as people and as company employees.
As a rule, customers seek to limit the number of participants in the project. Of course, colleagues are respected people, but their inclusion in the project team means an increase in the number of approvals of reporting documents. What in practice leads to an increase in the duration of the project. The fewer people involved in decision making, the easier it is to conduct a project within a company.
It is clear that the company seeks to reduce the cost of the project in any way, including at the expense of users, who in large companies are the subject. And are considered as a resource. Therefore, they are usually excluded from the implementation cycle - the user should simply work. User opinion is not important. In addition, training is a significant cost item and the less we train, the cheaper the project.
Another factor is the unavailability of the customer to fulfill its role as a customer. Often to formulate what they want from the point of view of automation, for the head in a large company, the problem. They simply do not know how to do this, even with the understanding that automation is needed.
The project described here is a project for the replacement of the electronic document management system (EDMS). There was nothing unique in the system itself, I wonder how we implemented this project.
The company in which the project took place was in the process of significant transformation. Significant personnel changes took place, business processes changed, there was even a transfer of the company's office to another city. At the same time, the company led several important projects for its customers and its activities were accompanied by about 8,000 documents and 34,000 instructions. Despite the changes, it was necessary to ensure uninterrupted activity.
In order to adjust the company's activities from the point of view of processes and to establish control over executive discipline, it was decided to replace the electronic document management system.
With all the features of large companies described above and in the context of changes, we embarked on a project.
As usual, the platform and the contractor’s team were chosen for a long time. Formed an internal team, which included a minimum of people. Signed a contract that included such mandatory milestones as the development of the project and private technical tasks for each functional area. In the meantime, until the moment when the system should work, 30 days remained. The implications of this approach are simple - if we do not change the way we worked until this point, the outcome is absolutely clear: there will be no system.
By this time, when there was a reserve of 30 days, drafts of all reporting documents were formally ready, including:
None of the documents was approved by the functional customer. Moving on is impossible.
Someone from the great said:
Therefore, we decided to turn to another experience.
Much was not clear, there was no practical knowledge, but there was a drive and a desire to try to do something differently. There was no experience of implementation either, and it was not clear how this falls on corporate culture. We understood one thing: if we don’t try, we won’t find out. And we began to learn.
We moved away from the usual corporate culture and began a dialogue with the customer in a different logic. Previously, we were looking for a way to fulfill the plan prepared in the usual logic, and now we asked ourselves the question: what is the root reason for the customer not signing the documents. We were lucky, the functional customer was open for communication, and we received enough information to understand his pains and aspirations. The main factors determining the actions of the customer, it turned out three.
The first is a simple lack of time for the project. Even with the desire to complete the project on time, the customer simply could not devote as much time to the project as needed. This was due to the performance of functional duties.
The second. It turned out that the project has three main priorities defined by the requirements of the Director General:
Third. The functional customer has a negative experience in the implementation of such a project, when, despite the availability of a detailed TK, the finished system did not meet expectations, so he fears a repeat of the story.
Having understood these factors, we decided to postpone the preparation of final versions of reporting documents and endorsement at the end of the project, and concentrate on achieving key results: putting the system into operation from 01/09/2017 and ensuring the preparation of a report on performing discipline.
That is, the first thing we have violated is the traditional way of consistently implementing the project through passing control points and points of transition of responsibility from the contractor to the customer. We did not demand from our functional customer the sighting of documents and the transfer of this responsibility. She is still behind the project team.
In this sense, it was quite bold, because in this case, the risks are assumed by the entire IT department and contractor. Including the risk of inability to close the project stages on time.
As I said, at this point we already had interviews, in general, it was clear what the system should do. It was possible to prepare the launch of the system by the deadline in order to collect the statistics that will allow the report to be generated at the end of the quarter.
We quite consciously understood that we did not have a system that would suit the customer, company, users - everyone! That is, it will be something similar, but not that. However, proceeded to start the operation of what happened.
The next step is how to ensure that the system is brought to a result close to that which the customer expects. We have created a continuous improvement system with feedback.
It has the following subjects: the customer; dedicated person of the customer (for which, too, thanks to him!), who describes the processes and is the accumulator of requirements - the process administrator; project team.
The exploitation, which we called pilot industrial, began, and was consolidated by an order. Our customer was able, as far as using the system, to form requirements for its refinement, indicating what needs to be corrected and changed. The resulting task flow to the project team is difficult to call sprints. We had a long list of proposals for finalizing the system, which were prioritized by our process administrator and submitted for execution. Went to the process of continuous improvement of the system.
In the next step, we deliberately included users to those who helped rebuild the system. In fact, we expanded the composition of the project team and transferred users from the role of the subject to the role of the object.
Initially it was assumed that we would train a limited number of users who are in direct administrative subordination of a functional customer, and they will give feedback. Reaching this inflection point, we decided to expand this number and allow all users to write what is wrong with the system.
There were 3 more information flow:
The important point is that the last thread went to the administrator of the process, who made the decision which proposals to start up, which did not. We received filtered offers.
This action made it possible not only to identify and eliminate errors, but also productively formulate requirements for the system refinement by the users.
The next thing we did was to separately engage in engaging the heads of structural units of the same level with a functional customer.
First, a group training was conducted, which ended with two proposals to middle managers: to give feedback in the form of proposals for improving the system and, if necessary, to undergo individual training. This could potentially lead to a financial explosion, that is, could require too much money for change and individual training. In fact, there was only one service note with a proposal for improvement, and only 1 person wanted to study individually. But the rest of our proposal was remembered. People saw our attention, and the emotional heat was sleeping.
You, probably, imagine: the crude system is in pilot operation, the company is close to revolution - sparks sparkle through the corridors! Naturally, for people who form the opinion of the management of the company, such a sign proved to be very effective. We have shown our willingness to receive feedback from them and the willingness to work with them individually. The functional customer himself was also present at the training and was open to contact.
The next step was giving publicity. To do this, we wrote and published an article on the corporate portal about why we chose this way of introduction. The article allowed explaining what is happening and reducing the heat generated due to the hard mode of implementation. In addition, when entering the system, any user could go to the questionnaire and express their opinion. This is a simple step that also brought benefits.
I will give a small statistic on appeals:
The first surge was in December, when we made only a prototype and received feedback from a functional customer. Further, as users connect, the jumps are visible, which lasted until February. The decreasing trend demonstrates how the system has been improved and the number of proposals for its change has decreased.
The consolidated implementation results in figures turned out to be as follows:
I regard the latter fact as an illustration of the emotional state of a company when a person wants to join the project. Our operator himself offered to answer questions about how to use the system, although this is not his function.
Not everything was good, there were difficulties. On the one hand, we were pleased that our approach enables the customer to form requirements for changing the system as they become aware of their needs. On the other hand, the customer got used to it very quickly, and when it was necessary to leave the project, we received “errors”. In reality, these were not errors, but rather questions related to how to use the system, or the results of the fact that the customer did not fully realize his own requirements and read the reports incorrectly. From all that was finalized in the last month of the project, only one event was really a mistake of developers.
But the customer was accustomed to this way of working, and as a result, we (IT) put a lot of effort to obtain visas under the reporting documents, had to write a program and test methods, assign tests, that is, include the formalism common to all large companies.
In addition, we must admit that some actions were performed with a delay. For example, an article on the portal would be more effective if it were published before the start of pilot operation.
Summing up, I will tell you what the key difference between this project and the ordinary for me. I have been working in large companies for a long time, I am a product of these companies, and I got used to the fact that at first it is a procedure. This gives the very stability, clarity of the relationship, removes the risks. In this case, we departed from the procedure and looked at our customer as a person with his own fears, peculiarities, priorities and so on.
Such a view allowed to come to the ideas that were born and were implemented. That is Agile here, rather, not a tool, but a flag, a catalyst, an idea! But this idea just led to a change in the minds, which allowed us to see the customer-person and orient him.
At the next stages, I would like to preserve the value we received, change the standard course of the project and the standard contract.
However, there are rules that we do not yet know how to get around, and are not even sure that we need to bypass them. First of all, this is the point of transfer of responsibility in the form of a signature on the reporting documents, and a limit on the amount and time. Inheritance in the form of reporting documents that allow you to transfer the system to other completion teams will also continue.
Concluding the article, I would like to say that, on the one hand, it is necessary to know the rules by which large companies live, understanding and accepting their bureaucratization, but not be afraid to violate them.
Be bold and act!
We invite experts and professionals to share interesting experiences of development or introduction by speaking at the RIT ++ conference festival in May. The program includes various narrowly focused areas; a conference on today's topic is called Web-scale IT Conference 2017, and the full list is on the website .
Under the cut is a dramatic story about an attempt to introduce a flexible management methodology in a large enterprise company .
This article is based on Dmitry Smolyarov's report at the Web-scale IT Conference 2017. Dmitry has been working in large holdings for more than fifteen years, in particular, he headed the IT department at RusHydro, and knows firsthand the structure of the corporate machine. His story will help to better understand the protocol of interaction with the enterprise-customer and will let you know how this protocol can be violated. Go!
')
What came?
First I want to tell one story. Once upon a time, as a young engineer, I arrived at one of the hydropower stations of our vast country with an ambitious task: in 3 days to include it in the common corporate space.
I met a wonderful person there, whose name was Nikolai Ivanovich. It was a strong business executive who reacted to my appearance something like this:
Indeed, everything is fine with him: everything is adjusted, everything works stably, IT systems are documented in detail (which is especially surprising), everything is stable. And suddenly, someone invades and offers a quick, unusual way for this experienced business executive to change everything. I met powerful resistance. It was a lesson that gave impetus to my understanding of what big companies need.
Why there is often no drive, driving and so on? - Because in large companies, other priorities and other values.
The main risks and motivators of a large company
- Protection - large companies always protect themselves, their assets and investments.
There are always a lot of risk factors and willing to join the company and “feed up” at its expense.
- Stability and predictability .
Often, we need not the most advanced innovations and revolutionary solutions, but a guaranteed result. Big companies just do not like revolutions.
- In addition, it is still always other people's money .
Decision makers manage the capital of others and there comes a time when you need to explain your actions and answer for their decisions to the owners and regulatory authorities.
This has several implications for the implementation of IT systems, including:
- Careful selection of contractor ;
- A well-considered contract - a system of gates (decision-making points about the possibility to continue the project, the ability to protect investments);
- Certain points of control ;
- Ensuring continuity with existing solutions;
- Reporting and documents!
Making decisions and passing control points is always accompanied by the preparation of reporting documents. This is the same reporting and the same documents that are most often associated with bureaucracy in large companies.
I understand you if you start yawning at this place. But I once again specifically draw your attention to the fact that daily life in large companies is always associated with this very “bureaucracy”, this is its natural component, and it always exists.
"Gate" - a control tool
Traditionally, the contract is constructed in such a way that at each stage a complete result is obtained, which can be used in the future activities of the company, this result is documented. Examples of such documents are conceptual and technical projects, private technical specifications, test reports, and so on.
The availability of such documents is especially important for IT projects, which, as a rule, give rise to an intangible asset. And if you do not document the results, it may not even remain a trace: there is a certain server on which a certain system is installed, and this system does something. What was done, what the act was signed for and paid for is not clear. Therefore, the traditional implementation of IT projects in large companies is a consistent achievement of the results described in the documents. Each of which passes internally the coordination and the statement, is accepted, as the finished decision, and is paid.
This is somewhat similar to Agile, but has a different meaning. The division of the IT project into stages is done with the aim of improving manageability and protecting the client company. Unlike Agile, aimed at obtaining a result that best suits the customer.
Features of the implementation
The other side of project implementation is the behavior of customer managers. Among their priorities is the desire to confirm their own solvency and significance, to preserve their place and make a career. That is why customers very often try to reduce risks and guarantee a result . This imposes certain features on their behavior, both as people and as company employees.
As a rule, customers seek to limit the number of participants in the project. Of course, colleagues are respected people, but their inclusion in the project team means an increase in the number of approvals of reporting documents. What in practice leads to an increase in the duration of the project. The fewer people involved in decision making, the easier it is to conduct a project within a company.
It is clear that the company seeks to reduce the cost of the project in any way, including at the expense of users, who in large companies are the subject. And are considered as a resource. Therefore, they are usually excluded from the implementation cycle - the user should simply work. User opinion is not important. In addition, training is a significant cost item and the less we train, the cheaper the project.
Another factor is the unavailability of the customer to fulfill its role as a customer. Often to formulate what they want from the point of view of automation, for the head in a large company, the problem. They simply do not know how to do this, even with the understanding that automation is needed.
Project context
The project described here is a project for the replacement of the electronic document management system (EDMS). There was nothing unique in the system itself, I wonder how we implemented this project.
The company in which the project took place was in the process of significant transformation. Significant personnel changes took place, business processes changed, there was even a transfer of the company's office to another city. At the same time, the company led several important projects for its customers and its activities were accompanied by about 8,000 documents and 34,000 instructions. Despite the changes, it was necessary to ensure uninterrupted activity.
In order to adjust the company's activities from the point of view of processes and to establish control over executive discipline, it was decided to replace the electronic document management system.
Everything is fine - we are falling!
With all the features of large companies described above and in the context of changes, we embarked on a project.
As usual, the platform and the contractor’s team were chosen for a long time. Formed an internal team, which included a minimum of people. Signed a contract that included such mandatory milestones as the development of the project and private technical tasks for each functional area. In the meantime, until the moment when the system should work, 30 days remained. The implications of this approach are simple - if we do not change the way we worked until this point, the outcome is absolutely clear: there will be no system.
Need another way ...
By this time, when there was a reserve of 30 days, drafts of all reporting documents were formally ready, including:
- Sketch of a technical project;
- Sketch of a conceptual project;
- Drafts of all private technical tasks.
None of the documents was approved by the functional customer. Moving on is impossible.
Someone from the great said:
“... if you do business in the same way you did before, it’s hard to expect a different result”
Therefore, we decided to turn to another experience.
Much was not clear, there was no practical knowledge, but there was a drive and a desire to try to do something differently. There was no experience of implementation either, and it was not clear how this falls on corporate culture. We understood one thing: if we don’t try, we won’t find out. And we began to learn.
- People and interaction are more important than processes and tools.
- A working product is more important than comprehensive documentation.
- Cooperation with the customer is more important than agreeing the terms of the contract.
- Readiness for change is more important than following the original plan.
"Pain" functional customer
We moved away from the usual corporate culture and began a dialogue with the customer in a different logic. Previously, we were looking for a way to fulfill the plan prepared in the usual logic, and now we asked ourselves the question: what is the root reason for the customer not signing the documents. We were lucky, the functional customer was open for communication, and we received enough information to understand his pains and aspirations. The main factors determining the actions of the customer, it turned out three.
The first is a simple lack of time for the project. Even with the desire to complete the project on time, the customer simply could not devote as much time to the project as needed. This was due to the performance of functional duties.
The second. It turned out that the project has three main priorities defined by the requirements of the Director General:
- from the beginning of the year the company should start working in the new EDS;
- at the end of the quarter, reports should be generated on executive discipline for calculating bonuses in accordance with the new, just approved personnel motivation system;
- a report on the performance discipline should be on the table at the State Duma.
Third. The functional customer has a negative experience in the implementation of such a project, when, despite the availability of a detailed TK, the finished system did not meet expectations, so he fears a repeat of the story.
Implementation
Having understood these factors, we decided to postpone the preparation of final versions of reporting documents and endorsement at the end of the project, and concentrate on achieving key results: putting the system into operation from 01/09/2017 and ensuring the preparation of a report on performing discipline.
That is, the first thing we have violated is the traditional way of consistently implementing the project through passing control points and points of transition of responsibility from the contractor to the customer. We did not demand from our functional customer the sighting of documents and the transfer of this responsibility. She is still behind the project team.
In this sense, it was quite bold, because in this case, the risks are assumed by the entire IT department and contractor. Including the risk of inability to close the project stages on time.
Step 1. Change priorities in the work and project control scheme
As I said, at this point we already had interviews, in general, it was clear what the system should do. It was possible to prepare the launch of the system by the deadline in order to collect the statistics that will allow the report to be generated at the end of the quarter.
Question from the audience: Could the senior management say that the project was on fire, and you could not get a signature?
This decision is in the spirit of large companies - 5 points! I would probably have done that before. But as I said, the way with the preparation of CTZ has not worked. This approach led us to what it led to: there is no time, the system should work. In addition, I believe that it is not very good to put pressure on colleagues, although sometimes I do it. But we consciously decided to go the other way. The main answer is this.
We quite consciously understood that we did not have a system that would suit the customer, company, users - everyone! That is, it will be something similar, but not that. However, proceeded to start the operation of what happened.
Step 2. Create a continuous improvement system with feedback
The next step is how to ensure that the system is brought to a result close to that which the customer expects. We have created a continuous improvement system with feedback.
It has the following subjects: the customer; dedicated person of the customer (for which, too, thanks to him!), who describes the processes and is the accumulator of requirements - the process administrator; project team.
The exploitation, which we called pilot industrial, began, and was consolidated by an order. Our customer was able, as far as using the system, to form requirements for its refinement, indicating what needs to be corrected and changed. The resulting task flow to the project team is difficult to call sprints. We had a long list of proposals for finalizing the system, which were prioritized by our process administrator and submitted for execution. Went to the process of continuous improvement of the system.
Step 3. Involving users in system improvements
In the next step, we deliberately included users to those who helped rebuild the system. In fact, we expanded the composition of the project team and transferred users from the role of the subject to the role of the object.
Initially it was assumed that we would train a limited number of users who are in direct administrative subordination of a functional customer, and they will give feedback. Reaching this inflection point, we decided to expand this number and allow all users to write what is wrong with the system.
There were 3 more information flow:
- Questions "How to use it?" Following the results of short training.
- Error messages: "The system does not work as it should - we see a mistake and are able to clearly describe it."
- Suggestions for changing the system.
The important point is that the last thread went to the administrator of the process, who made the decision which proposals to start up, which did not. We received filtered offers.
This action made it possible not only to identify and eliminate errors, but also productively formulate requirements for the system refinement by the users.
Step 4. Involve the middle management level
The next thing we did was to separately engage in engaging the heads of structural units of the same level with a functional customer.
First, a group training was conducted, which ended with two proposals to middle managers: to give feedback in the form of proposals for improving the system and, if necessary, to undergo individual training. This could potentially lead to a financial explosion, that is, could require too much money for change and individual training. In fact, there was only one service note with a proposal for improvement, and only 1 person wanted to study individually. But the rest of our proposal was remembered. People saw our attention, and the emotional heat was sleeping.
You, probably, imagine: the crude system is in pilot operation, the company is close to revolution - sparks sparkle through the corridors! Naturally, for people who form the opinion of the management of the company, such a sign proved to be very effective. We have shown our willingness to receive feedback from them and the willingness to work with them individually. The functional customer himself was also present at the training and was open to contact.
Step 5. Making the public
The next step was giving publicity. To do this, we wrote and published an article on the corporate portal about why we chose this way of introduction. The article allowed explaining what is happening and reducing the heat generated due to the hard mode of implementation. In addition, when entering the system, any user could go to the questionnaire and express their opinion. This is a simple step that also brought benefits.
Dynamics of the decrease in calls
I will give a small statistic on appeals:
- In just 5 months, the received and realized changes are about 250;
- Of these, 200 in the first 3 months.
The first surge was in December, when we made only a prototype and received feedback from a functional customer. Further, as users connect, the jumps are visible, which lasted until February. The decreasing trend demonstrates how the system has been improved and the number of proposals for its change has decreased.
Some facts
The consolidated implementation results in figures turned out to be as follows:
- Only 3 (at the peak of January 10) contractor’s specialists, internal services for training and user support were used to implement the system.
- On average, implementation was 20% faster than other similar projects.
- The cost has increased by about 5% due to an increase in the amount of training.
- Already at the start, 400 users independently connected (eventually more than 800) instead of the planned 120.
- Only one (official) memo with suggestions for improvement.
- The SPP operator expressed the wish to take on the first line of support entirely.
I regard the latter fact as an illustration of the emotional state of a company when a person wants to join the project. Our operator himself offered to answer questions about how to use the system, although this is not his function.
Drops of tar in a barrel of honey
Not everything was good, there were difficulties. On the one hand, we were pleased that our approach enables the customer to form requirements for changing the system as they become aware of their needs. On the other hand, the customer got used to it very quickly, and when it was necessary to leave the project, we received “errors”. In reality, these were not errors, but rather questions related to how to use the system, or the results of the fact that the customer did not fully realize his own requirements and read the reports incorrectly. From all that was finalized in the last month of the project, only one event was really a mistake of developers.
But the customer was accustomed to this way of working, and as a result, we (IT) put a lot of effort to obtain visas under the reporting documents, had to write a program and test methods, assign tests, that is, include the formalism common to all large companies.
In addition, we must admit that some actions were performed with a delay. For example, an article on the portal would be more effective if it were published before the start of pilot operation.
Procedure or person?
Summing up, I will tell you what the key difference between this project and the ordinary for me. I have been working in large companies for a long time, I am a product of these companies, and I got used to the fact that at first it is a procedure. This gives the very stability, clarity of the relationship, removes the risks. In this case, we departed from the procedure and looked at our customer as a person with his own fears, peculiarities, priorities and so on.
Such a view allowed to come to the ideas that were born and were implemented. That is Agile here, rather, not a tool, but a flag, a catalyst, an idea! But this idea just led to a change in the minds, which allowed us to see the customer-person and orient him.
At the next stages, I would like to preserve the value we received, change the standard course of the project and the standard contract.
However, there are rules that we do not yet know how to get around, and are not even sure that we need to bypass them. First of all, this is the point of transfer of responsibility in the form of a signature on the reporting documents, and a limit on the amount and time. Inheritance in the form of reporting documents that allow you to transfer the system to other completion teams will also continue.
The flight continues!
Concluding the article, I would like to say that, on the one hand, it is necessary to know the rules by which large companies live, understanding and accepting their bureaucratization, but not be afraid to violate them.
Be bold and act!
Questions and answers
- How much functionality has the project started for users?
SED started from the basics, as usual: incoming, outgoing, internal. But the leadership needed only 2 things: as usual, orders / orders and protocols. The peculiarity of the company is due to the fact that many solutions from the company's customers arrive to us. There are enormous numbers, in my opinion, 8,000 internal documents and 32,000 instructions, each of which has its own life cycle, and it must be monitored.
- But in general, you also had the TZ, what percentage was ready at the initial launch?
Almost everything that was in the TZ, we started immediately. There was no reporting. Further, the system was refined and business processes were customized to meet customer requirements. It was assumed that certain functions would be automated: incoming / outgoing, protocols, orders, reporting, and so on. We did not change their list regarding TK.
The contractor set up this functionality of the system, as he considered necessary, according to the results of the interview. But the vision of the contractor and the vision of the customer were different. Feedback allowed to bring together understanding and set up the system the way the customer wanted. That was the point of continuous improvement and feedback.
- That is, the functionality was one, and you changed a little bit of the logic plus the interface - as I understand it?
Roughly speaking, yes.
- Then the second question. How did you manage incoming requirements? How did you regulate what to take, what not to take?
There were 3 information flow. A user memo was written describing all these 3 information flows. A document was associated with each thread. The main stream - these are requests for changes - went through a customer representative. It was just an Exel file that was shared by 2 parties - a contractor and a process administrator controlled by IT.
For the rest, we have the Service Desk system in which we recorded the calls in the usual way. But 3 streams were set, described - memos, document, mailing - everything is as it should be.
- I have a question not so much from a technical point of view, but from the point of view of how you understood what functionality to include, what not, and whether you compared it with the budget that remained for this or that functionality. How did you regulate it?
The functionality that was supposed to happen at the start was in the contract. The changes, as I said, went through the functional customer process administrator. He expertly made decisions about what to include and what not to include. He is an external person in relation to money, quite right. I received feedback from the contractor and acted as a kind of regulator, also an expert.
Fortunately, this interaction was very effective. Maybe we were lucky - all adequate, all were within the course to the goal. There were no problems. Problems came when it was necessary to close the contract and decide on the termination of further improvements, on the readiness of the system.
- You can give a couple of tips to small companies who start working with major players. Suppose I come to Gazprom and offer this option of work. They'll look at me with a strange look and say that they are used to working wrong. How to find words for large companies to agree to try?
How to find the words, I guess I will not tell you. I'm still the seller. But I repeat once again - big companies have rules, procedures, as a way to protect and remove risks for specific people. What happened here is not a piece of advice, but more some detailing.
In this project, a visual scheme was prepared to remove the risks, which were voiced by the functional customer, in the form of a time line and drawing on it key project events, including points of transition of responsibility and points of improvement of the system. I myself drew a draft of the project, a time line, showed how it used to be, and how we will do now, indicated the transition point when the customer will endorse the documents. It was a way to convince a customer that he retains control.
The tips are actually the same. You need to know the customer, his fears and risks, and know the system rules of the company. Then you can find an option, like without breaking the basic rules, understanding what the customer is waiting for, suggest an option that will allow you to implement the project.
- The question is similar. It turns out that first of all you were on the side of the integrator, you won the procrastination on the part of the customer himself, and then, being inside the customer, you did everything possible so that the customer himself wanted to do it. Do you plan this further, how to offer some kind of consulting service? Here many people think how he did it?
In the format of the training to tell how the big companies are arranged - would it be interesting, colleagues? OK. We probably won ourselves in the first place. It was a victory in my head. It was necessary to move away from the desire to maintain the status quo and find a way to achieve the goal.
- A question on the budget. As I understand it, the project began even in advance, you did CTZ, all formal documents, and realized that the deadline that was set was not enough for normal implementation.
As you said, you convinced a functional customer by drawing a dot when he signs the documents. Before that you pledged to do everything.
The question is - how did you determine this point, what will it be, for example, at the end of May? After all, with such a flexible development, it’s really long and expensive, it’s not fast and cheap — as long as there is money, everything works, money runs out, everything ends — in the classics, right?
We can't work like that. It is necessary to coordinate the budget in advance with the directors, with all the company's founders. We cannot say that, you know, we ran out of money in June, and the requirements of another 120 lies, we must do. How did you regulate the budget?
These were some extras. agreement, or how? I understand that you were in the same boat with the contractor, but how did this decide within the company?
Valuable question. This was preceded by several circumstances. First, Scrum Trek last year gave statistics that the use of Scrum / Agile does not statistically lead to a reduction in the budget and the project’s deadlines. I just knew it would be about the same.
In addition, I like to read theoretical things, but in theory, Scrum allows you to achieve greater quality with the same time frame and budget.
I had an idea what a contracting company was, I knew what result to expect from them. It was a volitional decision, a risk. I assumed we could handle it.
As for money management, we concluded only one add. agreement to increase the volume of trainees, due to which the amount of the project slightly increased.
I add up all 3 components:
1. I understood the risks we were taking.
2. We were all limited by a contract that no one changed.
3. Understanding that we statistically fit into this budget and on time, we simply did not change these components, we only changed the way the project was implemented.
This is a different approach than you are voicing. The contract was and remains fixed, with a clearly agreed price and terms.
- As I understand it, at the implementation stage you provided some functionality that was not yet complete. In the future, you had to refine the functionality that you provided, to make a new functionality. But besides this, as users began to use the product, hot tasks began to appear. How did you cope with this flow and how did you regulate it?
And immediately the second question - whether you have filtered these errors. The process manager who gave you all the errors, in fact, could not be embedded in the essence of the problem, but simply put all of them and send them to you.
Accumulated all requests in one file. Simply organized in such a way that there was a fixation, filtering and prioritization. The project team has already received a list of tasks that have been previously processed on our side. Prioritization and filtering was carried out expertly based on an understanding of the company's needs and the content of the proposal.
What happened in the contractor’s team, I don’t know. Because I reduced the number of management points according to the classics and communicated with only one person who regularly brought me reports. I, as a representative of the customer, tracked the steady decline in the number of open hits.
To summarize the answer, it sounds like this:
1. There was a clear understandable mechanism for requests to the project team.
2. There was a clear, understandable tool to fulfill these requests.
The only thing I regulated was a surge when we needed more resources. It was visually visible the number of tasks that now exist, and we discussed how many and what kind of people need to digest this volume.
- Have you used any consultants, the same Scrum Trek? Or did everything yourself?
Yes, all by yourself. To use Scrum Trek, you must first sell the idea inside the company: so that it finds a lot of followers, and the company changes its culture.
- Sorry, if not a secret, what is the profitability of the project at the output?
I do not know.This is a question for the contractor. For the customer - let's answer this way - this project fits into the average. That is, it does not come with an inflated price. We have very tight control over this within the company.
SED started from the basics, as usual: incoming, outgoing, internal. But the leadership needed only 2 things: as usual, orders / orders and protocols. The peculiarity of the company is due to the fact that many solutions from the company's customers arrive to us. There are enormous numbers, in my opinion, 8,000 internal documents and 32,000 instructions, each of which has its own life cycle, and it must be monitored.
- But in general, you also had the TZ, what percentage was ready at the initial launch?
Almost everything that was in the TZ, we started immediately. There was no reporting. Further, the system was refined and business processes were customized to meet customer requirements. It was assumed that certain functions would be automated: incoming / outgoing, protocols, orders, reporting, and so on. We did not change their list regarding TK.
The contractor set up this functionality of the system, as he considered necessary, according to the results of the interview. But the vision of the contractor and the vision of the customer were different. Feedback allowed to bring together understanding and set up the system the way the customer wanted. That was the point of continuous improvement and feedback.
- That is, the functionality was one, and you changed a little bit of the logic plus the interface - as I understand it?
Roughly speaking, yes.
- Then the second question. How did you manage incoming requirements? How did you regulate what to take, what not to take?
There were 3 information flow. A user memo was written describing all these 3 information flows. A document was associated with each thread. The main stream - these are requests for changes - went through a customer representative. It was just an Exel file that was shared by 2 parties - a contractor and a process administrator controlled by IT.
For the rest, we have the Service Desk system in which we recorded the calls in the usual way. But 3 streams were set, described - memos, document, mailing - everything is as it should be.
- I have a question not so much from a technical point of view, but from the point of view of how you understood what functionality to include, what not, and whether you compared it with the budget that remained for this or that functionality. How did you regulate it?
The functionality that was supposed to happen at the start was in the contract. The changes, as I said, went through the functional customer process administrator. He expertly made decisions about what to include and what not to include. He is an external person in relation to money, quite right. I received feedback from the contractor and acted as a kind of regulator, also an expert.
Fortunately, this interaction was very effective. Maybe we were lucky - all adequate, all were within the course to the goal. There were no problems. Problems came when it was necessary to close the contract and decide on the termination of further improvements, on the readiness of the system.
- You can give a couple of tips to small companies who start working with major players. Suppose I come to Gazprom and offer this option of work. They'll look at me with a strange look and say that they are used to working wrong. How to find words for large companies to agree to try?
How to find the words, I guess I will not tell you. I'm still the seller. But I repeat once again - big companies have rules, procedures, as a way to protect and remove risks for specific people. What happened here is not a piece of advice, but more some detailing.
In this project, a visual scheme was prepared to remove the risks, which were voiced by the functional customer, in the form of a time line and drawing on it key project events, including points of transition of responsibility and points of improvement of the system. I myself drew a draft of the project, a time line, showed how it used to be, and how we will do now, indicated the transition point when the customer will endorse the documents. It was a way to convince a customer that he retains control.
The tips are actually the same. You need to know the customer, his fears and risks, and know the system rules of the company. Then you can find an option, like without breaking the basic rules, understanding what the customer is waiting for, suggest an option that will allow you to implement the project.
- The question is similar. It turns out that first of all you were on the side of the integrator, you won the procrastination on the part of the customer himself, and then, being inside the customer, you did everything possible so that the customer himself wanted to do it. Do you plan this further, how to offer some kind of consulting service? Here many people think how he did it?
In the format of the training to tell how the big companies are arranged - would it be interesting, colleagues? OK. We probably won ourselves in the first place. It was a victory in my head. It was necessary to move away from the desire to maintain the status quo and find a way to achieve the goal.
- A question on the budget. As I understand it, the project began even in advance, you did CTZ, all formal documents, and realized that the deadline that was set was not enough for normal implementation.
As you said, you convinced a functional customer by drawing a dot when he signs the documents. Before that you pledged to do everything.
The question is - how did you determine this point, what will it be, for example, at the end of May? After all, with such a flexible development, it’s really long and expensive, it’s not fast and cheap — as long as there is money, everything works, money runs out, everything ends — in the classics, right?
We can't work like that. It is necessary to coordinate the budget in advance with the directors, with all the company's founders. We cannot say that, you know, we ran out of money in June, and the requirements of another 120 lies, we must do. How did you regulate the budget?
These were some extras. agreement, or how? I understand that you were in the same boat with the contractor, but how did this decide within the company?
Valuable question. This was preceded by several circumstances. First, Scrum Trek last year gave statistics that the use of Scrum / Agile does not statistically lead to a reduction in the budget and the project’s deadlines. I just knew it would be about the same.
In addition, I like to read theoretical things, but in theory, Scrum allows you to achieve greater quality with the same time frame and budget.
I had an idea what a contracting company was, I knew what result to expect from them. It was a volitional decision, a risk. I assumed we could handle it.
As for money management, we concluded only one add. agreement to increase the volume of trainees, due to which the amount of the project slightly increased.
I add up all 3 components:
1. I understood the risks we were taking.
2. We were all limited by a contract that no one changed.
3. Understanding that we statistically fit into this budget and on time, we simply did not change these components, we only changed the way the project was implemented.
This is a different approach than you are voicing. The contract was and remains fixed, with a clearly agreed price and terms.
- As I understand it, at the implementation stage you provided some functionality that was not yet complete. In the future, you had to refine the functionality that you provided, to make a new functionality. But besides this, as users began to use the product, hot tasks began to appear. How did you cope with this flow and how did you regulate it?
And immediately the second question - whether you have filtered these errors. The process manager who gave you all the errors, in fact, could not be embedded in the essence of the problem, but simply put all of them and send them to you.
Accumulated all requests in one file. Simply organized in such a way that there was a fixation, filtering and prioritization. The project team has already received a list of tasks that have been previously processed on our side. Prioritization and filtering was carried out expertly based on an understanding of the company's needs and the content of the proposal.
What happened in the contractor’s team, I don’t know. Because I reduced the number of management points according to the classics and communicated with only one person who regularly brought me reports. I, as a representative of the customer, tracked the steady decline in the number of open hits.
To summarize the answer, it sounds like this:
1. There was a clear understandable mechanism for requests to the project team.
2. There was a clear, understandable tool to fulfill these requests.
The only thing I regulated was a surge when we needed more resources. It was visually visible the number of tasks that now exist, and we discussed how many and what kind of people need to digest this volume.
- Have you used any consultants, the same Scrum Trek? Or did everything yourself?
Yes, all by yourself. To use Scrum Trek, you must first sell the idea inside the company: so that it finds a lot of followers, and the company changes its culture.
- Sorry, if not a secret, what is the profitability of the project at the output?
I do not know.This is a question for the contractor. For the customer - let's answer this way - this project fits into the average. That is, it does not come with an inflated price. We have very tight control over this within the company.
We invite experts and professionals to share interesting experiences of development or introduction by speaking at the RIT ++ conference festival in May. The program includes various narrowly focused areas; a conference on today's topic is called Web-scale IT Conference 2017, and the full list is on the website .
Source: https://habr.com/ru/post/349082/
All Articles