It is useful for each of us (although not always pleasant!) to find out what they think about him on the sidelines, what he really is like if you look at him from the outside. Surely something can be corrected in time before it reaches a critical mass and begins to negatively affect others, be it bad breath from an untreated tooth or the habit of wearing week-old shirts – you just need to carefully ask others.

Such an impartial assessment could also be very useful for our projects. Perhaps steam is just beginning to accumulate under the lid, and now is the time to lift it, review the project plan, assign tasks to people, ask the developers what they are doing, and of course ask the customer if he is satisfied with the progress of the project. In the absence of systematic practice of this kind, there is a serious risk of not hitting the bull’s eye, and if it does, it will be in such a way that the team will no longer be able to take the second shot.

How to review your project, what needs to be checked, and what should you pay attention to? I offer a small “reminder” that you should periodically go through, and in each of the points there should be “ticks”.

1. Satisfaction with the progress of the customer’s project.
   1. The customer has weekly updated information about the progress of the project.
   2. The project team is transparent to the customer, he knows about each of its participants, and as a result, knows what he is paying for.
   3. However, direct communication with the customer is allowed only as an exception. The customer knows about this and accepts the rules of the game.
   4. Each customer requirement is recorded and either accepted into development into the current version of the product with an approximate deadline (which the team must meet), or postponed to the future, or rejected with an indication of the reason and possible alternative options.
2. Match expected and actual team performance.
   1. Quantitative performance indicators should be defined and regularly updated for the project. For example:
      1. Velocity in story points in the sprint compared to the previous one
      2. The difference in the time actually spent and planned for all features, again for the sprint.
   2. There should be no regular backlog. If it exists, identify the reason: it could be, for example, external factors, the internal organizational environment, imperfect tools, or individual dissatisfied team members.
3. Management of risks.
   1. Relevance of design requirements, and their compliance with environmental conditions. For example:
      1. A new, similar product may appear, which will entail a change in functionality to get out of the area of ​​direct competition.
      2. Legislation may change, which will make it impossible or difficult to use existing functionality.
   2. Relevance of the risk register.
   3. Availability of countermeasures to the most important risks in the backlog and their periodic implementation.
4. Healthy team morale.
   1. People work on features that are then included in new product releases. “On the table”, we don’t work in reserve.
   2. There are no overtimes.
   3. 1:1 meetings in the meeting room are held at least once a month. Informal meetings in the smoking room or over lunch are not enough.
   4. There is a personal development plan for each developer, drawn up by him and approved by the manager.
      1. This plan allows you to avoid procrastination during moments of forced downtime since it already contains answers to the question “What should I do.”
      2. It is useful in conducting quarterly performance reviews.
   5. Dissatisfied employees should not be left alone. There is always a way to solve their problem.
      1. Dismissal is the last option. We are always looking for other options. If there is any doubt, we calculate the cost of replacing an employee.
      2. Standard solutions – another role in the project, another project, transfer to another department, business trip, work on internal projects.
5. More difficult – why not start a new Open Source project for a good person, which will give him the opportunity to realize himself, and in the future will attract attention to the development company?
6. Compliance of the used development methodology and project management tools with the specifics and degree of readiness of the project.
   1. Very unlikely at the moment, but still, what if Scrum was involved in a project where it is not really needed, since the requirements do not change and the team is not interchangeable?
   2. Or, perhaps, the project has moved to the support stage, but no one thought to put up a Kanban board?
7. No or small amount of technical debt.
   1. It makes sense to allocate sprints dedicated to solving accumulated technical problems. Show me a project that doesn’t have those…
8. Project support from IT, HR, and other company services.
   1. Are there exactly as many seniors working on the project as are included in the plan?
   2. Are there enough servers, RAM, and monitors?
   3. The office landlord’s work schedule matches yours
9. A clear understanding of the future fate of the project after its completion.
   1. Is the next iteration of development possible?
   2. Has everything been done to make it possible?
   3. Will the customer expect any unpleasant surprises after delivery?

And so on and so forth. These are just the first of the points that came to mind in response to a generally typical question, how to make a customer happy. It’s actually not difficult!🙂