A technically flawless software delivery being rejected at an acceptance meeting is not an unusual scenario in the aviation sector. Consider a ground handling firm at Istanbul Ataturk Airport — a mid-to-large operation running apron services with a workforce of 412 — where an 11-month flight-based fuel tracking module was taken live, only for the operations director to label it ‘unusable’ within days. The engineering team had met every requirement item. Acceptance criteria had been satisfied on paper. Yet six weeks after go-live, the project had turned into a crisis meeting. The problem was not in the software; it was in how the requirements document had been written — in a way that meant three different things to three different groups of stakeholders.There is a persistent misconception about stakeholder management in aviation projects: that a competent project manager keeps the schedule, watches the budget and runs the meetings. This definition is accurate but incomplete — and the gap it leaves is precisely where the majority of projects stall. Aviation is one of the few sectors where engineering precision, operational pragmatism and management’s financial lens exist in continuous tension. In an MRO (Maintenance, Repair and Overhaul) software project, when an aircraft engineer says ‘the system must work correctly’, they mean compliance with international airworthiness standards. The operations planning manager sitting at the same table means uninterrupted data handover between shifts. The CFO means that labour cost per maintenance task is traceable. All three are right. All three mean different things. Making those differences visible — and collapsing them into a shared definition — is the project manager’s actual job.Requirements prioritisation becomes a critical instrument at this juncture, but when misapplied it produces the opposite result. The approach gaining traction across Turkey’s civil aviation sector is classifying requirements using MoSCoW (Must/Should/Could/Won’t). The method itself is sound; the problems emerge during execution. Engineering teams populate the ‘Must’ list with technical accuracy requirements, while the operations group places in the same category how data entry screens should behave during flight delay scenarios. Both carry the same priority label, but when resources are constrained, the disagreement over which is addressed first becomes inevitable. The solution is straightforward but routinely overlooked: the prioritisation meeting must not be a session that aggregates rankings each discipline produced independently — it must be a session that surfaces dependencies and conflicts between requirements. A priority list without a dependency map looks clean on paper and produces contradictions in practice.Change management carries a distinct challenge in aviation projects. When SHGM (Directorate General of Civil Aviation) regulations or EASA requirements are updated — and there were several notable EASA Part-145 revisions during 2011-2012 — technical documentation, software requirements and training materials must be updated simultaneously. Consider a representative scenario from an Ankara-based MRO firm with 321 employees holding military maintenance certification: a regulatory update was communicated to the technical team three weeks ahead of the effective date, but reached the software development team six weeks late. That six-week information asymmetry compressed all software changes needed to address the regulatory update into the final sprint, leaving virtually no time for quality assurance testing. Designing the change control process to cover not only software changes but regulatory updates and operational procedure revisions eliminates this risk structurally. Change boards built for a single domain make real cross-domain intersections invisible.How acceptance criteria are written determines project outcomes as much as the requirements document itself. A common error in aviation software projects is writing acceptance criteria as feature descriptions rather than testable behaviours. ‘The system shall display flight schedule changes in real time’ looks like an acceptance criterion — it is not, because ‘real time’ can mean 30 seconds to an engineer, 3 seconds to an operations controller, and 0 seconds to the manager responsible for passenger information displays. When the criterion reads ‘flight schedule changes shall be reflected on the operations control screen within 8 seconds of being recorded, and updated on passenger-facing terminals within 45 seconds’, the space for dispute disappears. That level of specificity does not signal a bloated specification; it signals a shared understanding of what project completion actually means. When an acceptance meeting is a verification session against criteria agreed in advance — rather than a judgment hearing — stakeholder tension drops measurably. Field observations from comparable projects suggest this reduction exceeds 57 percent in terms of post-delivery rework cycles.The practical path to aligning different disciplines’ languages is more concrete than commonly assumed. The first step is to ask each stakeholder group to write down, at the project’s outset, how they individually define ‘success’ — then compare those definitions. It is not the similarities but the contradictions that form the first draft of the project’s risk map. The second step is to include operational staff who live the requirements in their daily workflow in critical requirements sessions — not just the project team. A Sabiha Gokcen apron supervisor touching a requirements document resolves more ambiguity than five rounds of peer review. The third step is to make ‘which stakeholder group raised this’ and ‘which requirement does it affect’ mandatory fields when logging change requests; this small addition keeps the impact of each change from disappearing into blind spots.Defining the project manager’s role in aviation projects purely as a coordinator means structurally ignoring one of the most expensive sources of failure. Technical accuracy is necessary — it is not sufficient. Operational feasibility is necessary — it is not sufficient. Management approval is necessary — it is not sufficient. When a process is designed in which the three disciplines test each other, challenge each other and ultimately converge on a shared definition of completion, aviation software projects can achieve technical, operational and financial success simultaneously. The architect of that process is the project manager — not a schedule keeper, but a language translator between disciplines.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 10, 2012. The English edition has been reviewed and edited by the author.