KT.Team Project Manager Grades: Levels, Evaluation, and IDP

The final output of a project manager consists of three things: projects that deliver maximum value to the client; growing, trust-based relationships with the client's people; and a team that works effectively and in step with the company.

That is why a manager's evaluation equals the evaluation of the state of their projects. The faster a project reaches real operation and the less micromanagement the team requires, the better that state is. We allow for the possibility that a project reached the manager already in poor condition, and this is reflected in the evaluation comments. We do not allow for the possibility that after long work on a project, its state still has not reached what we define as a good project.

If there are several projects, there are several scores as well: one per project. Any doubt is interpreted conservatively: if you are torn between a 2 and a 3, give a 2.

The client can hand the team an L30-level state, but that does not yet make the project an L30 project. The level is considered sustained only if the team itself defines the cases, readiness criteria, and checks, and brings the state into real use on its own.

Domain examples from the client do not lower the level: at L30, it is normal for the client to bring real cases, constraints, and feedback. What does lower it is a situation where the client regularly does the team's work: becomes an analyst, tester, or manager, brings obvious test cases, checks basic readiness themselves, and brings the team back to the meaning of the state.

If the client delegates at L30 and the team cannot sustain it, the manager has two honest options: grow the team to L30 or break the state down into a series of L20 tasks and not present the project as a sustained L30. One-off lower-level assignments inside an L30 project do not change anything; if they become the main way of working, the level is rounded down.

It is normal to start collaboration at the hands-on level. It is not normal to stay there for long: the manager's job is to build trust and increase our value in the project.

We consider only what people have started using to be delivered. Not what was deployed to production, not what was shown at a demo, and not what was accepted on paper, but what has become part of daily work, with proof in usage metrics or feedback from the business user and their manager.

Everything else is inventory. Unfinished work is not an asset, but the client's frozen money and delayed understanding of whether the solution was right at all. That is why the assessment looks at the maximum amount of such inventory: how much value is lying unused and for how long.

We round down here as well. If only a pilot group uses the value, not the full target audience, then there is still room to grow: it is done, but something is missing for everyone to use it. For a live service, the target time to adoption is up to one month.

These are two different tracks, and they diverge more often than it seems. A team can have an excellent relationship with the IT department and still never meet the person responsible for business results. The reverse also happens.

That is why the evaluation uses two questions with the same scale. Both need to grow: without business there is no understanding of value, without IT there is no access to the environment, data, and production.

Requirements change even in enterprise projects, even during migrations, even with a precise specification, and even in regulated work. This is not an exception but a normal property of software systems. Predictability comes not from heavy upfront planning or multi-layer approvals, but from short feedback cycles, team autonomy, and delivery of small, verifiable increments.

DORA has studied modern product teams since 2013, QSM has modeled industry data since 1978, and their key findings align: large batches are harmful, late feedback is expensive, phase-based thinking lengthens projects, and success does not depend on certainty at the start. Trying to freeze requirements increases both duration and cost.

We do not reject waterfall as a class of tools. It is appropriate for linear, regulatory, and infrastructure tasks where the cost of change is low. It is not suitable for managing change, products, or user value. In linear tasks, we manage execution; in nonlinear ones, we manage how the system learns, and we deliberately do not confuse the two.

We cannot change the client's org structure, and we are not going to argue about terminology. But we always distinguish between the formally appointed Product Owner and the owner of the business outcome, and we never confuse the two, even if the client calls them the same thing.

The manager must ensure a minimal direct loop between the team and the outcome owner. There are three working formats: regular business sessions every two to four weeks, where the team shows an increment on live data; demos with metrics, observations, and real usage cases, where questions are addressed directly to the outcome owner; and an asynchronous channel with short screen recordings and specific questions if meetings are not possible.

An assigned role is useful in this model: it structures requests, synchronizes stakeholders, and speeds up operational decisions. It stops being useful when it becomes a filter. If the team does not see the owner of the result for months, if decisions are made without usage data, if the discussion gets stuck at "we agreed on that before," and if there is no metric that anyone owns, the project risk is considered structural, and that is grounds for escalation.

Authority follows from the evaluation system, but we state it explicitly so the manager does not have to guess.

The manager has the right to stop work on tasks whose business value is unclear. The manager has the right to demand a meeting with the person responsible for the business outcome, bypassing intermediaries. The manager must remove from the team anyone who breaks working standards, after giving feedback and setting a deadline. The manager has the right to change processes that block production deployment, after aligning it internally before escalating to the client.