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
