Project management in practice: pitfalls, essential skills and sound advice

IT project managers work at the intersection of delivery, technology and people. They are responsible not for doing every task themselves, but for creating the conditions in which the team can complete the agreed outcome on time, within the relevant constraints and at an acceptable level of quality.

A capable project manager is therefore less a supervisor than a communicator, integrator and decision-maker. The role requires breadth: enough technical understanding to ask sound questions, enough commercial judgement to see cost and risk, and enough leadership maturity to keep responsibility clear without suffocating the team.

Technical and delivery skills that matter

A project manager does not have to be the strongest programmer in the room. They do need to understand the delivery process, system architecture, dependencies, quality controls and the language used by engineers. Without that foundation it is difficult to test an estimate, recognise a dangerous assumption or help the team make a decision when circumstances change.

The role also includes shaping a team that fits the work:

• assess each person’s current capability and the risks around critical knowledge;
• match skills and seniority to the complexity of the assignment;
• avoid both underqualification and a role so narrow that experienced people disengage;
• keep the end user and the intended business result visible;
• understand the cost, architecture and operating implications of the chosen solution.

Professional currency comes from several sources: books, engineering blogs, conferences, focused courses and, above all, regular conversations with specialists. A data scientist, architect, analyst or operations engineer can reveal constraints that no generic management framework will show.

Core capabilities of a project manager

• Communication: make context, decisions and expectations understandable to different audiences.
• Learning agility: keep pace with a changing technical and business environment.
• Composure: remain useful when pressure rises instead of passing anxiety into the team.
• Constructive creativity: generate alternatives without losing sight of constraints.
• Confidence and influence: argue from evidence, listen properly and build a workable agreement.
• Forward thinking: see dependencies and prepare options before a risk becomes an incident.
• Responsibility: own the manageability of the system and make ownership explicit across the team.

The project lifecycle

A practical lifecycle usually contains four connected stages:

1. Initiation: clarify the objective, stakeholders, constraints, expected result and initial team.
2. Planning: define scope, delivery approach, milestones, dependencies, resources, risks and decision rules.
3. Execution and control: organise work, test assumptions, monitor flow and quality, manage changes and communicate the actual state.
4. Acceptance and closure: verify the result, resolve outstanding issues, transfer knowledge, close commitments and record lessons.

The project manager does not merely “watch tasks”. The work is to keep the complete delivery system coherent as new information appears.

Scrum, Kanban and the choice of method

Scrum and Kanban are not competing labels to apply by habit. Scrum organises work around a product goal, a prioritised backlog and timeboxed iterations. Kanban focuses on the flow of work, explicit policies and limits on work in progress. Either approach can be useful; the choice depends on demand variability, release rhythm, team maturity, dependencies and the cost of interruption.

Use the smallest process that gives the work sufficient visibility and control. A framework should solve a delivery problem, not create ceremonies for their own sake.

Common project-management traps

• Ignoring changes on the customer side. A new sponsor, decision-maker or team can alter priorities and acceptance criteria. Reconfirm authority, expectations and decisions early.
• Staying out of presales. Delivery leaders and architects should test scope, estimates, assumptions and risks before commitments become contractual.
• Treating retention as a last-minute negotiation. Reduce key-person dependency, discuss problems early and maintain realistic transition plans.
• Overlooking stakeholders. The customer is not automatically right about every solution, but their interests and constraints must be understood. Resolve disagreements through evidence, options and explicit trade-offs.
• Confusing trust with the absence of boundaries. Warm relationships help; unclear standards and selective exceptions damage quality and authority.

Motivating the team

Pay matters, but money alone rarely creates commitment to difficult work. Stronger motivation comes from a fair environment, meaningful autonomy, visible progress, professional growth and recognition of contribution.

• Room to create: let specialists improve the solution within the project’s goals and constraints.
• Development: support certification, mentoring, conferences and work that expands capability.
• Context: explain why the result matters and how each role contributes to it.
• Trust with accountability: give people authority that matches their responsibility and maintain clear feedback.

Working with the team

A project manager can be approachable without becoming vague about standards. Agree communication rules, decision paths, response expectations and the meaning of “done”. Listen carefully, address conflict early and document decisions that affect scope, time, cost or quality.

Tools

Tools should support the operating model. Jira or another tracker can make work and dependencies visible; Confluence or a shared knowledge base can preserve context and decisions; chat and video tools support rapid coordination; shared documents and dashboards make plans, risks and status available to the people who need them. The name of the product matters less than disciplined use and one source of truth.

The strongest project managers remain part of the team while holding a wider view of the system. They create clarity, protect the conditions for delivery and accept responsibility for turning uncertainty into a controlled result.