Project management for engineers
Published 22 September 2026
Nobody trains for this. You are good at the technical work, so you are handed the project, and every guide you find assumes a sponsor, a PMO, a business analyst and eight stakeholders. You have a manager who wants a weekly update and a change window on Saturday. Almost all of project management for engineers is working out which parts of the discipline survive that, and which are ceremony for an organisation you do not have.
What the training assumes, and what you have
| The methodology assumes | You actually have |
|---|---|
| A project sponsor who removes blockers | A manager who asks for status |
| A PMO holding the templates | A folder and a spreadsheet |
| A team you assign work to | You, and maybe one colleague |
| Requirements signed off up front | A vendor quote and a rough date |
| Change control boards | A change window and an approver |
This is not a complaint about the discipline. Those practices exist because large projects genuinely fail without them. But applying a process built for forty people to a job involving two produces documents nobody reads, which is worse than no process: it costs the time and gives false confidence that the work is under control.
The four documents that survive a change window
Everything below is what remains after you strip out the parts that need a department. Four documents, and each earns its place by preventing a specific, expensive failure.
1. A scope line: what is in, and what is explicitly out
Two lists, and the second is the one that matters. "Out of scope: anything touching the wireless controllers" is a sentence that costs thirty seconds to write and saves an argument in week four.
The failure this prevents does not usually arrive as a request to expand the project. It arrives as "while you're in there, could you just…", and each one is genuinely small. The problem is that nobody is counting them, and the date does not move. Writing down what is out gives you something to point at that is not your own reluctance.
2. A dependency you can name
Not a network diagram of the whole project. One sentence per blocker: what is waiting, on whom, and what date it becomes a problem.
Infrastructure work is almost entirely dependencies, and very few of them are technical. Circuit delivery dates, a vendor RMA, someone else's change freeze, a purchase order in approval, physical access to a site. The technical work is usually the short part: it is the waiting that sets the date, which is why estimates built from the engineering effort are wrong.
3. The change record you are actually going to run
The document you execute during the window: the steps, the verification, the rollback, and who approves the decision to back out. This is the one engineers already write and most tools ignore.
It is also the one most often the wrong document: a runbook used where a method of procedure belongs, with no rollback in it. Runbook, playbook or MOP covers which is which and why change approval bounces when they are confused.
4. A status line someone else can read
Three items, weekly: what moved, what is next, what is blocked and on whom. Written for someone who does not know what a VLAN is.
Most engineers treat reporting as overhead imposed from above. It is genuinely the cheapest insurance available. A manager who has read "blocked on the circuit delivery, chasing weekly" for three weeks does not arrive surprised when the date slips, and a manager who is surprised is the one who starts asking for daily updates, which costs far more than the weekly one would have.
The single habit worth more than all four documents: write down what changed and why, at the time.
Not afterwards. The reason a port moved, the reason a VLAN was renumbered mid-cutover, the reason that firewall rule is broader than the design said: all of it is obvious while you are doing it and unrecoverable three months later. The why is the part everybody drops and the part that matters when somebody, possibly you, has to change it again.
What to drop
Said plainly, because most advice will not:
- A full work breakdown structure. Decomposing a two-person job to the fourth level produces a document that is out of date before the first task closes.
- Earned value management. It needs a baselined budget and booked hours. If you do not have both, the numbers are invented.
- A stakeholder register, when the stakeholders are four people you speak to weekly.
- Daily stand-ups with yourself. This happens more than anyone admits.
- A RACI matrix for routine work. It earns its place on cross-team change windows and vendor-involved work; on a job where you are responsible, accountable and consulted, it is a form-filling exercise.
Why the estimate was wrong
Engineers underestimate infrastructure projects in a consistent direction, and it is not optimism about the technical work. It is that the technical work is not the project.
| What gets estimated | What actually consumes the time |
|---|---|
| The configuration | Getting the change approved |
| The cutover | Finding a window everyone accepts |
| The install | Procurement, delivery, and the RMA when it arrives faulty |
| The testing | Getting someone else to confirm their application still works |
| — | Documenting what you actually did |
A useful correction: estimate the engineering, then ask who has to say yes before it can happen, and how long each of them takes to answer. That second number is usually larger, and it is the one nobody writes down.
If you are consulting
Project management for consultants carries everything above plus three problems that do not exist when you have one employer.
- Scope is contractual, not social. "While you're in there" is unbilled work with an employer and a margin problem with a client. The out-of-scope list stops being a convenience and becomes the thing that decides whether the engagement is profitable.
- You are the context switch. Four clients means four sets of addressing, four change processes and four sets of credentials. Whatever you use has to survive being picked up cold after a fortnight. That is a documentation requirement, not a memory one.
- Reporting is the product, partly. A client who cannot see progress assumes there is none. The weekly three-line update is doing commercial work as well as project work.
Technical project manager, or engineer who runs projects?
Worth separating, because the titles get used interchangeably and the jobs are not the same. A technical project manager is a project manager who understands the domain well enough to challenge an estimate: the job is coordination, and they are not doing the implementation. An engineer who runs projects is doing both, and the project work is the part with no training attached.
If you are the second and want to become the first, the gap is rarely technical. It is the reporting, the dependency chasing and the stakeholder-handling that engineers are inclined to treat as somebody else's job.
When you genuinely need more process
The honest counterweight to all of the above. Add structure when:
- More than one team has to act in the same window. Coordination failure is the dominant risk and it is what the ceremony is actually for.
- The change is hard to reverse. Addressing changes, circuit migrations, anything with a physical component.
- Somebody outside will notice. The moment a change has an audience, who-gets-told becomes a real question.
- You are running more than about five at once. This is where memory stops working and it fails suddenly rather than gradually.
The tooling question
Most of this ends up in a spreadsheet, and a spreadsheet is a perfectly reasonable answer for one project. There's a free Excel project tracker built for infrastructure work. It stops working somewhere around the fifth, or the first time a vendor contract renews without anyone noticing.
When it does, the fix is rarely a bigger tool. It is keeping the dates, owners and vendors somewhere a second person can open, which is most of what IT vendor management comes down to.