What a project manager needs to know about ABAP

You do not need to read code. You need to be able to hear an estimate and know which of three questions to ask, because on an SAP programme the difference between a two-day change and a three-week change is almost never the code itself.

The three questions are: is this a released object or a modification, how many systems does it have to move through, and does it need a transport that anything else depends on. A developer who answers all three in a sentence has thought about it. A developer who cannot answer the second one is estimating the typing and not the delivery.

That is roughly the whole job. What follows is the background that makes those three questions land.

ABAP is SAP's own programming language, and unlike most enterprise languages it lives inside the system it extends rather than beside it. Custom code sits in the same runtime as the standard product, uses the same data dictionary, and is versioned by the same mechanism that moves configuration.

That coupling is the source of most of the behaviour that surprises people from other stacks. There is no separate repository by default. There is no build artefact you can hand to someone. The code and the system are the same object, which is why moving a change between environments works nothing like a deployment pipeline.

SAP now draws a hard line inside the language itself. Its documentation for the public cloud edition describes developer extensibility as a way to develop cloud-ready and upgrade-stable custom ABAP code, built on objects SAP has released for that purpose.

The two words to hold onto are released and upgrade-stable. They are the axis the rest of this article turns on.

Code does not get deployed on an SAP system. It gets transported, which is a different thing with different scheduling consequences. SAP documents the flow for a three-system landscape: an administrator imports the customizing requests, the software collection and the workbench request into the test tenant using the Import Collection app, then forwards them to the production tenant after successful testing.

Read the sequencing. Changes travel as bundles, in order, through a fixed chain of systems, and the order is not negotiable once things are in flight.

The practical consequence is dependency. If change A and change B touch the same object and A is sitting in the test system awaiting sign-off, B cannot reach production ahead of it. Your urgent fix is now behind somebody else's unfinished feature, and no amount of prioritisation in your tracker changes that, because the constraint lives in the transport chain rather than in your backlog.

So ask about transport sequencing at planning time, not at release time. The question that surfaces it is simple: what else is in flight that touches this. On a programme with several workstreams the honest answer is usually a list, and that list is a schedule risk you can now manage rather than discover.

SAP formalises this with stability contracts on its data model. Its documentation describes three contracts covering extensions (C0), system-internal use (C1) and remote API use (C2), and the point of the scheme is to tell you, in advance, what SAP promises not to break.

For a delivery lead this converts a vague technical worry into a checkable fact. When a developer proposes building on an object, the question is whether it carries a contract. If the answer is no, you are not making a technical trade-off, you are accepting an unbounded liability at every future release, and that belongs in the risk register with a name against it.

The bottom row of the table is the historical trap. Modifying the standard product was normal practice for years, it is quick, and it is the reason some organisations cannot upgrade without a six-month project. Every modification is a debt with an interest payment due at each upgrade, and the interest compounds because nobody remembers why the modification was made.

SAP names its two quality tools directly: ABAP Unit for dynamic tests and the ABAP Test Cockpit for static code analysis, with a check set aligned to the ABAP cloud coding rules.

You do not need to run them. You need to know they exist, because the answer to one question tells you a great deal about a custom estate you are inheriting. The question is: what does the static analysis report say today.

Three answers, three different programmes. If there is a current report with a trend, the team has a working engineering practice and your estimates can be believed. If a report exists but nobody has looked at it since 2019, there is a known and unquantified backlog. If nobody has ever run one, you do not have an estimate problem, you have a discovery problem, and the honest move is to buy two weeks of assessment before committing to anything.

That last case is not a criticism of the team. It is extremely common, and it is far cheaper to name it in week one than to absorb it as unexplained overrun in month four.

When a number arrives, decompose it into the four things that generate elapsed time on an SAP system: development, transport movement, testing in each system, and approval at each gate. A developer estimating in good faith usually gives you the first one only, because it is the only one they control.

So the arithmetic runs like this. Three days of development, plus a transport that moves on Tuesdays and Thursdays, plus two days of testing in the test system, plus a change approval board that meets weekly, is three days of work inside roughly two weeks of elapsed time. Neither number is wrong. Reporting only the first one is.

Keep the two columns separate in the plan and report both. It removes the most common and most corrosive conversation on these programmes, the one where a sponsor asks why a three-day change took a fortnight and there is no structured answer.

This is the general form of the estimation discipline: decompose until each line resembles something the team has actually done, and carve genuine unknowns into their own small phase rather than burying them in a buffer. Buffers get negotiated away. A named discovery phase does not.

None of this makes you a developer, and it is not meant to. It makes you able to run the conversation where a technical estimate meets a business commitment, which is the conversation on these programmes that most often goes unmanaged.

That is a specific job. Somebody has to hold sequencing across workstreams, translate between a development team and a steering committee, and keep a decision record that survives staff turnover. It is a delivery role that sits close enough to the technology to challenge it, and it is distinct from both the architect and the developer.

It also generalises past SAP. A clinical research organisation moving to version-controlled database change management had a development team that understood the target state perfectly and could not express it as something a sponsor could fund. Decomposing it into 159 tracked work items with acceptance criteria and explicit dependencies is what made the programme approvable, and the person who did that decomposition needed exactly this depth of technical literacy: enough to ask the right three questions, not enough to do the work.

If you are new to an SAP programme and want the two adjacent pieces, the deployment model decides most of what your developers are allowed to do, and the vendor release cadence decides when they are allowed to do it.