Report on the Business Analytics ReqLabs Conference (Kiev)
Recently visited Kiev at the ReqLabs conference on the activities of business analysts. The main audience of listeners are Project managers, Team Leaders, business / system analysts, in a word, people occupying management positions in their companies.
In general, I liked it: a lot of sensible ideas, interesting reports, as well as the speakers themselves. The latter are also of a very high level: from regular business / system analysts to company executives.
The conference was held on the basis of the training center of the Moscow company Luxoft (although, as I understood, it has many offices scattered around the world). In terms of organizing the event itself, everything was at a good level: rooms, furniture, dinners, snacks, etc. I took note: the organization of such events is a good way to promote the company:
The main ideas and just interesting thoughts in the reports that were remembered:
')
I remember this phrase, in which, in general, there is nothing new, but which, nevertheless, is sometimes relevant, when, without thinking, you start to “improve” something on the project.
Very interesting was said about the methodology of IBM RUP: “RUP is a cookbook. You open it when you want to know the solution to a particular problem, and you will be given a clear sequence of actions, exactly how to solve the problem. As soon as you solve it, you can close the book. "
The idea here is the following: in any company, in one way or another, there is a vertical line of the type “management / top management - managers are the lowest links”. So, it is very important that some kind of feedback come up from the “lower links” about various kinds of problems and shortcomings. Moreover, the local managers should accumulate opinions and transfer them to the top so that they reach the leadership.
This, I must say, is relevant, because It happens that people “downstairs” are afraid to talk about bad things to higher-level managers, which in general is understandable: no one wants to bring bad news :)
If the feedback is not received, a situation may arise when top management lives in a separate reality, believing that everything is okay and there are no problems.
“Failures and failures in solving various problems are caused, first of all, by mistakes of the top management who incorrectly set the process. This is 90% of cases. And only in the remaining 10% of cases, ordinary workers are to blame for not doing something according to the instructions / regulations. ”
I agree with this phrase, most often it happens. If you take some kind of leadership position, you need to first ask yourself what was done wrong.
It is very important to motivate all team members to increase its efficiency. This can be done in different ways:
a) High salary, as an indicator of the value of a person.
b) Promises of career growth (position in the company / salary).
c) The promise to provide a stake in the project upon its launch (probably more relevant for startups with a small team).
Here were raised current issues:
1. How and in what to evaluate the quality?
2. How to increase it?
The basic idea: quality control should occur as the person himself is doing something. This is more effective than putting a supervisor who will control the performer, because no one will control the supervisor, and he may also be mistaken. Of course, you can discuss this topic, but there is some truth in it. This can be achieved, it seems to me, if one motivates a person well (see p1.4), and of course the level of professionalism must be appropriate.
Teams without a clear leader seem to solve problems more efficiently than traditional teams with a pronounced structure (the leader is the performers). But here, it seems to me, not everything is smooth. First of all, in order for such a team to take place, the professionalism of each of her students should be quite high.
Such an opinion was voiced that “if a team has a weak link that reduces its (team) efficiency, then it’s easier to throw out the link than to do some optimization within the team itself”. Probably, to assemble such a team is not easy.
The meaning is approximately that there are different types of tasks:
a) Specific technical tasks assigned by the manager.
b) Resource tasks (fuzzy), in which you need to show creativity and which are clearly not set by the manager.
It is believed that the tasks of the second type are solved by a person more effectively due to the fact that he can here show some flight of fantasy and more creativity.
Here, probably, you can draw some analogy with the work for yourself (business, freelancing, etc.) and with the work “for uncle”. The idea of ​​“working for yourself”, I think, is more pleasant for everyone :)
I liked about the principle of involving stakeholders (stakeholders) in the project. The basic idea: before starting work on any project, it is necessary to determine a list of all stakeholders (stakeholders) who can somehow influence the project. Next, these people need to be moved to the square of the following form:
People who are very interested in the project, but who do not make key decisions on the project.
Decision makers (decision makers) who are actively working on the project.
People who need to be kept "at gunpoint", because on the one hand, they are the decision maker; on the other hand, they do not show a strong interest in the project. You, probably, faced with a situation when you are doing a project, everything is OK, and then suddenly someone comes (director or some top-manager) and says: “Everything you did here is garbage, it was not necessary to do so.” And rushed :)
Just so that this does not happen, people from the 3rd square need to be maximally involved in the project, increasing their interest.
People who just need to "monitor", because today they are in the 4th square, and tomorrow they will move to another, and this should be tracked and taken into account in time.
With such a formalization, it becomes immediately clear who takes what position on the project.
Among the interesting speakers, it is worth noting Paul Turner: “The Evolving role of the Business Analyst” , Adrian Reed: “Stakeholder Engagement: Delivering projects in the face of adversity” , Mikhail Kumskov: “Processes and people” and Peter Loboda / Elena Golubenko: “ Business analysis in the field of telecommunications . These speakers were one of the best, although I liked the British speakers against the background of their Ukrainian “colleagues”: they gave the audience better information, the reports were very well developed.
Ps. There was a lot of interesting things at the conference, but, unfortunately, you cannot cover everything in one article, I highlighted only the most interesting, in my opinion, moments. I will be glad to answer questions.
In general, I liked it: a lot of sensible ideas, interesting reports, as well as the speakers themselves. The latter are also of a very high level: from regular business / system analysts to company executives.
The conference was held on the basis of the training center of the Moscow company Luxoft (although, as I understood, it has many offices scattered around the world). In terms of organizing the event itself, everything was at a good level: rooms, furniture, dinners, snacks, etc. I took note: the organization of such events is a good way to promote the company:
- You can assemble a large database of resumes and potential employees.
- About the company will know better in the country, because the participants are not only Kyiv residents and not only ordinary IT's, but also managers / managers.
- About the company will be able to learn abroad, because speakers - not only from Ukraine.
The main ideas and just interesting thoughts in the reports that were remembered:
')
Before you solve a problem, you must identify it.
I remember this phrase, in which, in general, there is nothing new, but which, nevertheless, is sometimes relevant, when, without thinking, you start to “improve” something on the project.
Very interesting was said about the methodology of IBM RUP: “RUP is a cookbook. You open it when you want to know the solution to a particular problem, and you will be given a clear sequence of actions, exactly how to solve the problem. As soon as you solve it, you can close the book. "
Fear-based companies are ineffective.
The idea here is the following: in any company, in one way or another, there is a vertical line of the type “management / top management - managers are the lowest links”. So, it is very important that some kind of feedback come up from the “lower links” about various kinds of problems and shortcomings. Moreover, the local managers should accumulate opinions and transfer them to the top so that they reach the leadership.
This, I must say, is relevant, because It happens that people “downstairs” are afraid to talk about bad things to higher-level managers, which in general is understandable: no one wants to bring bad news :)
If the feedback is not received, a situation may arise when top management lives in a separate reality, believing that everything is okay and there are no problems.
About company failures
“Failures and failures in solving various problems are caused, first of all, by mistakes of the top management who incorrectly set the process. This is 90% of cases. And only in the remaining 10% of cases, ordinary workers are to blame for not doing something according to the instructions / regulations. ”
I agree with this phrase, most often it happens. If you take some kind of leadership position, you need to first ask yourself what was done wrong.
About team motivation
It is very important to motivate all team members to increase its efficiency. This can be done in different ways:
a) High salary, as an indicator of the value of a person.
b) Promises of career growth (position in the company / salary).
c) The promise to provide a stake in the project upon its launch (probably more relevant for startups with a small team).
About quality control
Here were raised current issues:
1. How and in what to evaluate the quality?
2. How to increase it?
The basic idea: quality control should occur as the person himself is doing something. This is more effective than putting a supervisor who will control the performer, because no one will control the supervisor, and he may also be mistaken. Of course, you can discuss this topic, but there is some truth in it. This can be achieved, it seems to me, if one motivates a person well (see p1.4), and of course the level of professionalism must be appropriate.
Self-organizing teams
Teams without a clear leader seem to solve problems more efficiently than traditional teams with a pronounced structure (the leader is the performers). But here, it seems to me, not everything is smooth. First of all, in order for such a team to take place, the professionalism of each of her students should be quite high.
Such an opinion was voiced that “if a team has a weak link that reduces its (team) efficiency, then it’s easier to throw out the link than to do some optimization within the team itself”. Probably, to assemble such a team is not easy.
Tasks that are not explicitly set are performed with great enthusiasm.
The meaning is approximately that there are different types of tasks:
a) Specific technical tasks assigned by the manager.
b) Resource tasks (fuzzy), in which you need to show creativity and which are clearly not set by the manager.
It is believed that the tasks of the second type are solved by a person more effectively due to the fact that he can here show some flight of fantasy and more creativity.
Here, probably, you can draw some analogy with the work for yourself (business, freelancing, etc.) and with the work “for uncle”. The idea of ​​“working for yourself”, I think, is more pleasant for everyone :)
Involvement of stakeholders in the project
I liked about the principle of involving stakeholders (stakeholders) in the project. The basic idea: before starting work on any project, it is necessary to determine a list of all stakeholders (stakeholders) who can somehow influence the project. Next, these people need to be moved to the square of the following form:
1st quarter
People who are very interested in the project, but who do not make key decisions on the project.
2nd quarter
Decision makers (decision makers) who are actively working on the project.
3rd quarter
People who need to be kept "at gunpoint", because on the one hand, they are the decision maker; on the other hand, they do not show a strong interest in the project. You, probably, faced with a situation when you are doing a project, everything is OK, and then suddenly someone comes (director or some top-manager) and says: “Everything you did here is garbage, it was not necessary to do so.” And rushed :)
Just so that this does not happen, people from the 3rd square need to be maximally involved in the project, increasing their interest.
4th quarter
People who just need to "monitor", because today they are in the 4th square, and tomorrow they will move to another, and this should be tracked and taken into account in time.
With such a formalization, it becomes immediately clear who takes what position on the project.
Among the interesting speakers, it is worth noting Paul Turner: “The Evolving role of the Business Analyst” , Adrian Reed: “Stakeholder Engagement: Delivering projects in the face of adversity” , Mikhail Kumskov: “Processes and people” and Peter Loboda / Elena Golubenko: “ Business analysis in the field of telecommunications . These speakers were one of the best, although I liked the British speakers against the background of their Ukrainian “colleagues”: they gave the audience better information, the reports were very well developed.
Ps. There was a lot of interesting things at the conference, but, unfortunately, you cannot cover everything in one article, I highlighted only the most interesting, in my opinion, moments. I will be glad to answer questions.
Source: https://habr.com/ru/post/116642/
All Articles