Most IT projects that fail do not fail because the idea was bad or the technology was wrong. They fail in the gap between the plan and the build: requirements that never became specifications, schedules that ignored technical dependencies, and go-live dates set without anyone confirming the system could actually be operated. The IT project manager and the systems engineer are the two people who stand on either side of that gap.
One is accountable for scope, schedule, budget and stakeholders. The other is accountable for whether the system works, performs and can be supported. When they work as a pair, sharing decisions rather than passing documents over a wall, projects land. When they do not, the project manager reports green until the week before launch and the engineer finds out what was promised at the same time as the customer.
Two roles with different questions
The IT project manager asks: what are we delivering, for whom, by when, at what cost, and what could stop us? Their tools are the project charter, the plan, the risk register, the status report and the stakeholder conversation. Their job is to turn a business goal into a sequence of work that people can commit to, and to keep that commitment honest as reality changes.
The systems engineer asks: how does this actually work, what does it depend on, and what happens when something breaks? They design, configure and integrate servers, networks, cloud services, identity systems and applications. They think in interfaces, capacity, failure modes and maintenance, and they are usually the ones who will be called when the system misbehaves after launch.
Neither set of questions is enough on its own. A plan without engineering input is a wish list with dates. An engineering design without a plan is a science project with no finish line.
Where projects actually break
The same failure points appear across infrastructure upgrades, cloud migrations, ERP rollouts and security projects. Each one sits at the boundary between the two roles.
Estimates made without the builder. A timeline built from a vendor’s brochure or a manager’s instinct rarely accounts for data migration, integration testing, change windows or certificate renewals. When the systems engineer helps build the estimate, those tasks appear in the plan instead of in the overrun.
Missing non-functional requirements. Business stakeholders describe what a system should do. They rarely specify how fast, how available, how secure or how recoverable it must be. Those non-functional requirements drive most of the engineering cost, and if nobody writes them down, the engineer guesses and the project manager cannot defend the budget.
Change without control. A small scope change on paper can be a major redesign in practice. Without a shared change process, where every change request gets a technical impact assessment before it gets a yes, scope creep turns into schedule slip.
Go-live treated as the finish line. A project is not done when the system is switched on. It is done when the operations team can run it: monitoring configured, backups tested, runbooks written, access handed over and support contracts in place. Projects that skip operational acceptance transfer their unfinished work to the help desk.
Security bolted on at the end. When security review happens a week before launch, findings either delay the project or get waived. Both outcomes are worse than involving security during design. Our guide to scoping a secure cybersecurity roadmap covers how to build that review into the plan from the start.
A working model for the partnership
Good project manager and systems engineer pairs tend to share a few habits, regardless of whether the project runs on a traditional plan, an agile cadence or a hybrid of the two:
- Co-own the estimate. The project manager structures the work breakdown; the engineer sizes the technical tasks and names the dependencies. Both sign the result.
- Write non-functional requirements early. Agree on availability, performance, recovery time, data retention and security requirements before design starts, and get the business owner to approve them.
- Keep one risk register. Technical risks, such as an unsupported integration or a single point of failure, belong on the same list as budget and staffing risks, with owners and dates.
- Run every change through a technical impact check. The engineer assesses effort and risk; the project manager assesses schedule and cost; the sponsor decides.
- Plan the cutover as its own project. Rehearse migrations, define rollback criteria and timing, and schedule the change window with the people who will be affected.
- Define “done” as operable. Include monitoring, backups, documentation, access handover and a support model in the acceptance criteria.
- Hold a short weekly joint review. Fifteen minutes comparing the plan with technical reality catches drift while it is still cheap to fix.
What each role should learn from the other
The strongest project managers in technical environments understand enough engineering to ask good questions. They do not need to configure a firewall, but they should know why a change window matters, what a dependency on a legacy system implies, and when “it’s nearly done” means two more weeks of testing. Asking the engineer to explain a risk in business terms, and then carrying that explanation to the sponsor, is one of the most valuable things a project manager can do.
The strongest systems engineers understand enough project management to make their work visible. They break technical work into tasks that can be tracked, raise risks early instead of absorbing them silently, and translate technical trade-offs into cost, time and risk. An engineer who says “we can launch on the date, but without a tested failover, so an outage would last a day instead of an hour” has given the business a decision it can make.
For deliverable-level detail on security projects specifically, see our deliverable breakdown for 2025 cybersecurity projects.
When a small team cannot staff both roles
Many small and mid-sized businesses have one IT generalist who is expected to plan, build and run every project. That can work for small changes, but major initiatives, such as a cloud migration, a new line-of-business system or a compliance program, benefit from separating the roles, even temporarily. Options include bringing in a project manager for the duration of a major program, engaging an outside engineer for design and cutover, or using a fractional technology leader who can provide oversight across both. The trade-off is cost against the risk of a failed launch, and for projects that touch revenue or regulated data, the risk usually wins.
Frequently asked questions
What is the difference between a systems engineer and a systems administrator?
The titles overlap and vary by employer. In general, a systems engineer designs and builds systems and integrations, while a systems administrator focuses on running and maintaining them day to day. On a project, the engineer is typically responsible for the design and cutover, and the administrator is a key recipient of the handover.
Should an IT project manager be technical?
Technical literacy helps a great deal, but deep hands-on skill is not required. What matters is the ability to understand dependencies and risks well enough to plan around them, and the discipline to involve engineers in estimates and decisions.
Do agile teams still need a project manager?
Infrastructure and integration projects often have fixed external dependencies, such as hardware delivery, vendor cutover dates and contract renewals, that do not fit neatly into sprints. Someone still needs to coordinate those, manage stakeholders and track budget, whatever the title.
Deliver technology projects that land
Delana Technologies provides fractional CTO and expert technical consultants who can plan, architect and oversee complex IT initiatives, with security and compliance built in through our cybersecurity and compliance services. Call 239.414.5126 or contact us.
Sources: Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), Seventh Edition; INCOSE Systems Engineering Handbook; Delana Technologies project delivery experience.