Manage development tasks. Life story
About when there are more tasks than resources for their implementation, the queue of tasks increases over time and some of them can be safely called “stupid”.
Briefly about the company to outline the context of the situation. By type of activity - Mortgage Lending Regulator. Industry - Finance. Scale - Federal. Partner network from Vladivostok to Kaliningrad with the organization of interaction with Partners through the company's IT systems. The direction of IT work is the development and refinement of its own corporate information systems supporting business processes both within the Company and on the Partner’s side. The budget for the development of EIS - 100 million rubles per year. CIS maintains a business of 60 billion rubles a year. Number of users KIS -> 2000 people.
At the time of my arrival at the company, the situation looked like that the IT department had long since drowned in the stream of tasks for automating business processes and refining those already covered by IT solutions.
Having worked for a while, I already perceived this situation personally. You try to do something good and do it well for your Customer, but in the end you are still bad for him.
The reasons for the large flow of tasks:
')
In the picture, the moral and psychological state of the director of the DIT when studying the list of requests from which he should choose the ones that we will do.
We began by introducing a feasibility study for the requested development / refinement and implementation of IT solutions.
The feasibility study consisted of an assessment of the complexity of the task and the expected economic effect. The complexity of the implementation provided DIT, an assessment of the economic effect - the customer. Justification showed what tasks are able to pay for themselves and for what period.
At the suggestion of DIT, the Management of the Company and the Business Units decided that the Company does not spend resources / budget on tasks where there is no economic benefit. If the solution of the task is capable of bringing the Company substantial non-economic benefits, then this should be spelled out in the justification and this is the focus of the attention of the Steering Committee, which authorizes these requests.
Since the employees of the Partners worked in the CIS, we considered the economic effect from the implementation of the tasks for them as well. For the Company, direct economic benefits could not be here, but in this way we increased the attractiveness and profitability of cooperation with the Company. We did refinement on “1 ruble”, and all 200 Partners received the economic effect from it.
This decision led to the fact that the huge flow of requests with small and "stupid" modifications that did not bring added value but consumed resources reduced to "no".
The period when employees tried to automate everything that could be automated, to do nothing with their hands, ended.
The feasibility study led the situation to the fact that now the resources of the DIT were focused on the most profitable tasks and projects for the company. It solved the first part of the problem, now the resources were used efficiently. There was a second - Customers were still not happy that the DIT did not do what they were asked.
In the figure, the change for the better is the moral and psychological state of the director of DIT when selecting requests for implementation.
Each Business Unit was set for the year indicators (KPI), which it should achieve. To achieve these indicators, the Business Units have generated requests to the DIT for providing the necessary IT solutions. The situation with the feasibility study led to the fact that the tasks of the earning divisions received more resources, and the servicing (spending) divisions found themselves in the position of “poor” relatives.
The first projects were aimed at making more money, while the second ones were aimed at saving. It was less profitable to save / improve the efficiency of your own work than to think up decisions about how to earn more. This was due to the fact that
Since the DIT made a decision about what tasks to implement and where to direct the budget, this gave rise to accusations against the DIT that we ignore the tasks of the service business units and give preference to the tasks of earning.
The decision did not come immediately, since on the one hand everything was in order. Resources fall into the most profitable tasks and projects for the company. On the other hand, it turns out that it is wrong to set the indicators for the units, which they must achieve, and not provide them with the necessary resources for this.
It was decided to divide the budget between departments in accordance with the accumulated volume of authorized tasks. For this, we calculated the amount of required resources for the implementation of all tasks and determined the share of tasks of each business unit in this volume. In these shares, "distributed" the budget.
The DIT was still responsible for the budget, but now each business unit itself decided on what tasks, on what annual indicators to achieve, to send the amount allocated to it.
That was the way the second part of the problem was solved; they did what the Business Division asks within the limits of its opportunities for that.
In the “Happy End” picture.
The feasibility study for Business Units was not necessary, they were not interested in it.
First, they wanted everything they asked for.
Secondly - the resulting economic effect is then checked.
For that, the feasibility study was clear and necessary for the Company’s Management, therefore this tool was introduced by the decision “from above”.
It took more than a year to teach Business Units to form an intelligible feasibility study.
The division of the budget between business units has led to organizational changes within the DIT. Each business unit was assigned to a specific Project Manager. Subsequently, the position of the Direction Manager was introduced. Her area of ​​responsibility includes managing the budget and portfolio of project and non-project IT requests from the business unit.
Share in the comments your "cases" and links to stories you know about. By this you will help me to gather, and other readers to get an overview of the practice.
If, after reading the article, you have a desire to disturb my karma with Minus, then leave a comment to it below, which in the article and my personality hurt you and did not like it. I will consider your position and opinion in the future.
Stupid task - when the expected use of the implementation does not justify the number of required resources, but the Customer insists on the need to carry it out.ABOUT
- managing the flow of development tasks,
How to get rid of "stupid" tasks? - managing development costs,
How to identify and select the most profitable tasks? - allocation of limited resources.
How to make so that all Customers are satisfied, and the amount of resources at the same time remains the same?
The essence of the problem and its causes
Briefly about the company to outline the context of the situation. By type of activity - Mortgage Lending Regulator. Industry - Finance. Scale - Federal. Partner network from Vladivostok to Kaliningrad with the organization of interaction with Partners through the company's IT systems. The direction of IT work is the development and refinement of its own corporate information systems supporting business processes both within the Company and on the Partner’s side. The budget for the development of EIS - 100 million rubles per year. CIS maintains a business of 60 billion rubles a year. Number of users KIS -> 2000 people.
At the time of my arrival at the company, the situation looked like that the IT department had long since drowned in the stream of tasks for automating business processes and refining those already covered by IT solutions.
The main complaint of customers (internal business units) - DIT works inefficiently and does not do what they ask.At the same time, customers appeal to the figures that in a quarter of 40 requests were made only 5. And so for each customer: accounting, financial, legal, purchasing mortgage….
Having worked for a while, I already perceived this situation personally. You try to do something good and do it well for your Customer, but in the end you are still bad for him.
This is the situation when being a productive project manager and “delivering” is not enough.
The reasons for the large flow of tasks:
')
- The amount of the allocated budget for the development of EIS allows you to realize a lot in it.
- A large number of local solutions based on Excel and Access on the rejection of which sets the direction for the development of EIS.
- Users and Customers, accustomed to the fact that each request is implemented.
- Employees of DIT, accustomed to the fact that all the same what to do, what they are asked to do.
In the picture, the moral and psychological state of the director of the DIT when studying the list of requests from which he should choose the ones that we will do.
Step # 1: Introducing a Feasibility Study for IT Requests
We began by introducing a feasibility study for the requested development / refinement and implementation of IT solutions.
The feasibility study consisted of an assessment of the complexity of the task and the expected economic effect. The complexity of the implementation provided DIT, an assessment of the economic effect - the customer. Justification showed what tasks are able to pay for themselves and for what period.
Example Feasibility Study
Situation: The company regularly updates the Loan Agreement template, which is used by Partners in processing loans.
Problem: For some of the Partners, the employees who draw up credit agreements do not have access to the Internet (internal policy of banks), for this reason there is a lag between the release of a new contract template and its reception by employees, this leads to the use of outdated templates and the execution of additional agreements to credit treaties.
Sometimes it happens that the employees of the Partners make changes to the loan agreement template, which makes it necessary to check the wording of the loan agreement for compliance with the reference ones, and if they do not comply, conduct an analysis of the changes made and necessary actions.
Objective: To reduce the time spent by the Expert on checking the Loan Agreement by implementing the verification of the Credit Agreement of the Corporate IP.
Technological solution:
Use the IT solution of ABBYY (Service) for document recognition and verification with the standard.
In ICC it is necessary:
Evaluation of the implementation of labor: 1 300 000 rubles.
Expected economic effect: Reduction of time to read a loan agreement (about 15 pages), check pattern compliance and availability of changes from 20 minutes to 5. The average monthly flow of loan agreements is 3,500 pieces. An expert’s hour costs 523 rubles. Expected savings = (15 minutes * 3 500 KD) / 60 minutes * 523 rubles = 457 625 rubles per month .
Payback period: 1 300 000/457 625 = 2.8 months.
Duration: 3 months from the date of sending to work / to sell.
Problem: For some of the Partners, the employees who draw up credit agreements do not have access to the Internet (internal policy of banks), for this reason there is a lag between the release of a new contract template and its reception by employees, this leads to the use of outdated templates and the execution of additional agreements to credit treaties.
Sometimes it happens that the employees of the Partners make changes to the loan agreement template, which makes it necessary to check the wording of the loan agreement for compliance with the reference ones, and if they do not comply, conduct an analysis of the changes made and necessary actions.
Objective: To reduce the time spent by the Expert on checking the Loan Agreement by implementing the verification of the Credit Agreement of the Corporate IP.
Technological solution:
Use the IT solution of ABBYY (Service) for document recognition and verification with the standard.
In ICC it is necessary:
- Implement the transfer mechanism to the Service scanned copies of the loan agreement and the corresponding standard;
- Implement the processing mechanism from the Service of the recognized document and the results of verification.
Evaluation of the implementation of labor: 1 300 000 rubles.
Expected economic effect: Reduction of time to read a loan agreement (about 15 pages), check pattern compliance and availability of changes from 20 minutes to 5. The average monthly flow of loan agreements is 3,500 pieces. An expert’s hour costs 523 rubles. Expected savings = (15 minutes * 3 500 KD) / 60 minutes * 523 rubles = 457 625 rubles per month .
Payback period: 1 300 000/457 625 = 2.8 months.
Duration: 3 months from the date of sending to work / to sell.
At the suggestion of DIT, the Management of the Company and the Business Units decided that the Company does not spend resources / budget on tasks where there is no economic benefit. If the solution of the task is capable of bringing the Company substantial non-economic benefits, then this should be spelled out in the justification and this is the focus of the attention of the Steering Committee, which authorizes these requests.
Since the employees of the Partners worked in the CIS, we considered the economic effect from the implementation of the tasks for them as well. For the Company, direct economic benefits could not be here, but in this way we increased the attractiveness and profitability of cooperation with the Company. We did refinement on “1 ruble”, and all 200 Partners received the economic effect from it.
This decision led to the fact that the huge flow of requests with small and "stupid" modifications that did not bring added value but consumed resources reduced to "no".
The period when employees tried to automate everything that could be automated, to do nothing with their hands, ended.
The feasibility study led the situation to the fact that now the resources of the DIT were focused on the most profitable tasks and projects for the company. It solved the first part of the problem, now the resources were used efficiently. There was a second - Customers were still not happy that the DIT did not do what they were asked.
In the figure, the change for the better is the moral and psychological state of the director of DIT when selecting requests for implementation.
Step 2: Allocation of IT budget for each customer
Each Business Unit was set for the year indicators (KPI), which it should achieve. To achieve these indicators, the Business Units have generated requests to the DIT for providing the necessary IT solutions. The situation with the feasibility study led to the fact that the tasks of the earning divisions received more resources, and the servicing (spending) divisions found themselves in the position of “poor” relatives.
The first projects were aimed at making more money, while the second ones were aimed at saving. It was less profitable to save / improve the efficiency of your own work than to think up decisions about how to earn more. This was due to the fact that
mortgage market grew.
Since the DIT made a decision about what tasks to implement and where to direct the budget, this gave rise to accusations against the DIT that we ignore the tasks of the service business units and give preference to the tasks of earning.
The decision did not come immediately, since on the one hand everything was in order. Resources fall into the most profitable tasks and projects for the company. On the other hand, it turns out that it is wrong to set the indicators for the units, which they must achieve, and not provide them with the necessary resources for this.
It was decided to divide the budget between departments in accordance with the accumulated volume of authorized tasks. For this, we calculated the amount of required resources for the implementation of all tasks and determined the share of tasks of each business unit in this volume. In these shares, "distributed" the budget.
The DIT was still responsible for the budget, but now each business unit itself decided on what tasks, on what annual indicators to achieve, to send the amount allocated to it.
That was the way the second part of the problem was solved; they did what the Business Division asks within the limits of its opportunities for that.
What got
- Tasks that are advisable to do in terms of benefits for the company.
- Ensured the implementation of the tasks and projects of each unit without having to compare the importance of the tasks of the units with each other
- They provided the Business Unit with the opportunity to independently decide on the implementation of which IT requests to send the budget to achieve annual targets.
- Budget planning with the Business Unit so that it lasts for a year and all the most important initiatives are implemented.
- The opportunity to go to the Budget Committee with a proposal to increase the company's IT budget supported by the list of tasks of the Business Units with a positive feasibility study, which were not implemented last year due to budget deficit.
In the “Happy End” picture.
Afterword
The feasibility study for Business Units was not necessary, they were not interested in it.
First, they wanted everything they asked for.
Secondly - the resulting economic effect is then checked.
For that, the feasibility study was clear and necessary for the Company’s Management, therefore this tool was introduced by the decision “from above”.
It took more than a year to teach Business Units to form an intelligible feasibility study.
The division of the budget between business units has led to organizational changes within the DIT. Each business unit was assigned to a specific Project Manager. Subsequently, the position of the Direction Manager was introduced. Her area of ​​responsibility includes managing the budget and portfolio of project and non-project IT requests from the business unit.
What to read on the topic
- Strategies for the formation of a portfolio of orders for the enterprise, producing products for the order
- Optimization of web-studio work. Application of the theory of restrictions in the production of sites
- Application of the Theory of System Constraints to the formulation of a process
Share in the comments your "cases" and links to stories you know about. By this you will help me to gather, and other readers to get an overview of the practice.
If, after reading the article, you have a desire to disturb my karma with Minus, then leave a comment to it below, which in the article and my personality hurt you and did not like it. I will consider your position and opinion in the future.
Source: https://habr.com/ru/post/314448/
All Articles