How can a manager avoid problems on a new project?

During my 20-year career, I managed to work as an electrician, and a developer, and a manager, and a CTO, and even a BigData director at Cloud in a green bank. Over the years, I managed to change more than 10 companies and a hundred projects (recently I wrote out directly in excel). I won’t say that changing a project or a company is like going for “bread” for me, and there is absolutely always stress. Obvious problems: new people, new projects and tasks, a new office – and you need to get used to everything. And there is an unobvious problem: not all information may be transferred to you on a new project, not because of malicious intent, but because of the lack of a methodological approach to transferring cases. I present a checklist for handing over projects.

Let’s just agree that we’re handing over a software development project. Some parts will be useful for other types of projects, but I suggest that you refine the checklist for your subject area.

The checklist will be useful for both project managers and development, testing and devops leads. There was an attempt to stretch the story on a globe for product managers, even some artifacts remained on the checklist, but familiar products were criticized with development phases, etc.

This is the second version edited by my manager friends from Sberbank, MTS, Acronis, EPAM Systems and Amazon. It is interesting that the most adequate comments were from agile adherents, and from waterfall’s there was only non-constructive criticism of the form “everything is not right, but I won’t tell you how it should be”, they also sent PMBOK to read (secretly, I studied PMBOK and ITIL, everything to get from there is to write a new book).

The checklist is available at the link https://github.com/wonderu/phf.

What topics do I cover?

  • General information on the project;

  • Team;

  • Architecture and design;

  • Development tools;

  • Source;

  • Release policy;

  • Testing;

  • Documentation;

  • Project management;

  • Administration and technical support;

  • Budget and supplier management.

When useful:

  1. If you are leaving a project/company, try to provide as much information as possible on the checklist for the new employee. This will be useful if there is a lag between your dismissal and the hiring of a new manager.

  2. If you’re joining a new company, arm yourself with a checklist to gather information during an interview with an outgoing manager.

  3. And at any other time when you feel that the project is not well documented and your onboarding guides do not answer all your questions.

Hope the checklist is helpful. I expect constructive criticism from you, stars and contributions on github.

advantage

Similar Posts

Leave a Reply