The post has been translated automatically. Original language: Russian
The project team has been creating something for several months.
Developed, tested, and launched. All the main tasks are closed.
You can disperse :)
It's not until the next day that the project result begins to lead a normal life.
The user's access is not working.
Something needs to change.
An error has been found.
There is a new employee who needs to be connected.
A month later, a question arose that no one expected at all during development.
And then suddenly it turns out that the project is over, and it's unclear who should go with all this now.
It seems to me that the transfer of the result should not be considered on the last day.
Even before the project is completed, it is useful to determine:
Who is responsible for what we have created?
To whom do we send the instructions and necessary materials?
Have all the necessary access rights been granted?
Are there any other issues that the project team did not manage to resolve?
Who will deal with them after completion?
And most importantly, does the receiving party understand what exactly has become its responsibility now?
Because technically, it's possible to send someone a folder with documents and write "everything has been transferred" pretty quickly.
But this does not mean that a person will be able to work with it normally tomorrow.
I would generally separate the two points.
First, we have finished working on the project.
The second is that the result of the project has actually been transferred to those who will continue to use, support and develop it.
And sometimes there is still a decent chunk of work between the first and second point.
Therefore, the closure of the project for me is not only the last check mark in the plan.
Probably, it is really finished when there is no question after the departure of the project team.:
"And now whose is it anyway?"
Представим проект.
Первые месяцы постоянно что-то происходит.
На встречах команда говорит, что не успевает. Разработчик предупреждает о технической проблеме. Кто-то сомневается в сроках. Приходится разбираться, менять планы, объяснять ситуацию заказчику.
А потом вдруг становится тихо.
Проблем почти нет.
Все идет по плану.
Красота :)
Только иногда такая тишина означает совсем не то, что проект наконец наладился.
Мне кажется, очень многое зависит от того, как руководитель реагирует на плохие новости.
Допустим, сотрудник несколько раз заранее предупреждал о проблеме.
А в ответ каждый раз получал:
«Почему опять не успеваем?»
«А раньше нельзя было об этом подумать?»
«Мне теперь что заказчику говорить?»
В следующий раз он вполне может решить сначала попробовать разобраться сам.
Потом еще немного подождать.
Потом надеяться, что как-нибудь получится.
И к руководителю проблема попадет уже тогда, когда исправить ее спокойно невозможно.
Получается довольно странная вещь.
Чем неприятнее руководителю слышать плохие новости, тем позже он начинает их получать.
И отчеты действительно становятся красивее :)
Я бы поэтому обращала внимание не только на то, что команда мне сообщает, но иногда и на то, о чем она почему-то перестала говорить.
Если раньше люди спорили, задавали неудобные вопросы, предупреждали о сомнениях, а теперь на каждой встрече все неожиданно хорошо — возможно, стоит проверить, что изменилось.
И здесь, мне кажется, руководителю особенно важно разделять две вещи.
Проблема уже возникла.
И человек вовремя о ней сообщил.
Это не одно и то же.
За саму проблему, конечно, иногда придется разбираться, кто и что сделал неправильно.
Но раннее предупреждение я бы точно не превращала в повод получить по голове.
Потому что в следующий раз предупреждения может просто не быть.
А для руководителя проекта плохая новость сегодня обычно намного полезнее, чем та же самая плохая новость через две недели.
Даже если сегодня ее совсем не хотелось слышать.
Share
