From “BPM” to “DM”: We’re Changing the Role Name Starting September 1

Starting September 1, 2026, we will change the position name used in quotations, proposals, and contracts from BPM (Bridge Project Manager) to DM (Delivery Manager).

There will be no changes to pricing or contract terms. The people assigned to existing projects will not be replaced. What will change is the name of the role and the scope of responsibility that comes with it.

Our Third Change in Position Naming

This is the third time we have changed the name of this position.

The first was in 2008, when VFA was founded. At the time, several people stood between our Japanese customers and the development team in Vietnam: bridge SEs, IT communicators, testers, and developers. Roles were finely divided by process, with a different person assigned to each one. Eighteen years ago, this was a standard way of running outsourced software development.

Division of labor has advantages. Because each person has a narrower scope of responsibility, hiring and training are easier. However, the more people there are in between, the less clear it becomes who owns each decision. When specifications are interpreted differently, it takes time to determine whether the issue comes from translation or design. More importantly, the only person responsible for the overall project outcome was often on the customer side.

VFA therefore consolidated the intermediary roles into one. The second name for that role was BPM.

“Bridge Project Manager” is not a standard job title. It is a name VFA created internally. We wanted someone who was responsible not only for “bridging” translation and coordination, but for the progress of the project itself. That was the intent behind the name.

Now, we are retiring BPM.

Why Change It Again?

The biggest reason is that the way customers decide “what to build” has changed.

Software development used to be organized around the assumption that the correct answer existed from the beginning. The customer finalized the requirements and handed them over as specifications. We built them quickly and without bugs. The goal did not move. In that environment, the main job of the person in the middle was to “communicate accurately.”

That assumption no longer holds.

There is no single reason. Markets move faster, and business plans themselves have shorter lifespans. During the several months it takes to build something, competitors, regulations, and the customer’s internal organization can all change. In-house development has become a realistic option for customers. Technologies surrounding software development, including AI, are also changing on a scale of months. None of these factors alone is decisive, but together they have made it increasingly difficult to succeed with any approach other than finding the right answer while building.

More projects now seem to begin before anyone has fully decided what should be built. Given that the business plan itself is still moving, this is only natural. A situation that might once have been treated as a delay in requirements definition is no longer unusual as the starting point.

If the goal moves, the job of the person in the middle must also change. Translation, meeting minutes, and relaying progress can now be replaced to a significant extent by tools. Two responsibilities have become more important instead: deciding what not to build, and making sure that what has been decided is delivered all the way through.

The word “bridge” assumes that the right answer already exists on the other side and only needs to be passed across. Once that assumption disappears, the name no longer describes the role.

What Does a DM Do?

A bridge role carries information. A DM owns the outcome.

DMs have three core responsibilities.

The first is prioritization. Together with the customer, the DM decides what to build within the available time and what to defer.

The second is delivery completion. The responsibility is not merely to finish building according to the specifications, but to get the product released and into actual use.

The third is early risk escalation. Problems should be raised with the customer while they are still small. We have incorporated “not delaying bad news” into the evaluation criteria for DMs.

This does not mean that our previous BPMs only performed relay work. We already have many members who deeply understand specifications, consider the customer’s business, and lead development accordingly. DM is not the invention of a new kind of work. It is a new name for making that way of working the organizational standard.

We are changing the name because we want to stop relying on the discretion of a few exceptional individuals.

From PM to COE

DM is the only title that is changing. However, we have reviewed the definition of every position.

• PM: Responsible for the 0-to-1 phase. PMs work directly with customers, identify the real problem that needs to be solved, and make proposals.
• DM: Responsible for the 1-to-10 phase. DMs run the cycle of release and improvement and ensure delivery is completed.
• Developer: Not a role limited to implementation. Developers understand why something is being built, work with AI, and make the judgment required to inspect and accept what is produced.
• PMO: Checks whether standards are being followed across projects and uses data to detect early signs of trouble.
• COE: Builds the technical foundation for productivity and quality assurance and distributes it across all teams. COE also takes ownership of highly difficult technical problems that cannot be fully resolved within an individual project.

The first three roles are the layer that moves projects forward. The latter two support them.

Both PMs and DMs work directly with customers. The model is not one where the DM stays inside the company and communicates only through the PM.

Estimation and How We Work

VFA previously took an approach of identifying all functions and estimating them together in one batch. We would include not only the functions customers said they needed, but also things we thought “would be better to have” or “should really be included.” We did this with good intentions, but in some cases it likely made our estimates appear higher than those of other companies.

We now divide the process into three stages.

1. PoC: We build a prototype and determine what should actually be created.
2. MVP: We narrow the scope to the minimum functionality required for the product to work and release it first.
3. Iteration: We continue improving the product while reprioritizing every two weeks to one month.

This does not add another phase to the work. We have simply split what used to be bundled into one release into three stages. Building the same thing does not take longer or cost more simply because of this structure. In fact, once we can look at something that actually works before deciding the rest, some functions may turn out not to be necessary at all.

Because we no longer try to lock everything down at the beginning, the time to the first release has become significantly shorter than before. We still provide the schedule and cost for the initial release based on the requirements available at that point. Customers need that information to make a purchasing decision, so we do not leave it vague.

VFA’s estimates are not simply a sum of initial development costs. We estimate one delivery structure that covers the PoC, the MVP release, and the subsequent maintenance and improvement. That includes how we continue responding to requests that emerge after people in the field and end users begin using the product.

This means the scope differs from an estimate that covers only the initial development.

Priorities will always change. There is no guarantee that the list of functions decided at kickoff will still be optimal six months later. An estimate that fixes everything to be built in advance cannot incorporate that change. That is why our standard approach allows the order of priorities to be rearranged along the way.

The objective is not to increase the number of functions. If we add one thing, can we remove another?

Thinking through that together is part of the DM’s job.

The Tension Between Speed and Quality

Shipping quickly and avoiding breakage naturally conflict with one another. Move faster and quality tends to fall. Protect quality too aggressively and delivery slows down. If we try to reconcile the two only through extra effort from people on the ground, the system will eventually break somewhere. People get tired, and they get overloaded.

VFA therefore decided to address this through the system itself. Internally, we call this foundation AI Foundation.

In practice, it consists of VFA-specific plugins and rule sets that are loaded into the IDE used by developers from the beginning. It incorporates mechanisms for controlling AI agents, virtualizing and isolating environments, and conducting security audits. Where risk is low, teams can move at full speed. Where risk is high, the system automatically applies the brakes.

That is essentially what it does.

Rules written only in documents eventually stop being read. We therefore embedded the rules into the execution environment itself so that the safe way of working becomes the default.

The foundation consists of four layers, from Layer 1 to Layer 4, and is applied at four levels depending on the risk carried by the project. It covers the safety of environments that handle confidential information, reviews of generated code for quality and vulnerabilities, and regression prevention through automated testing. The closer software gets to the market, the stricter the required level becomes.

Auditing is not performed manually in Excel. It is automated on GitHub, and reports show which projects are operating at which level.

Testing has also changed over the past few years. In the past, many projects had to give up writing as much test code as we wanted because of time and budget constraints. Now that AI can be used, we can implement that volume of testing. Whether software can continue to be changed without breaking depends heavily on this.

This system is not finished yet. We are still improving it as we operate it.

What This Means for Customers

• Change in terminology: Starting with quotations, proposals, and contracts issued on or after September 1, 2026, the term BPM will be replaced with DM.
• Pricing and contract terms: No change.
• Assigned members: The people assigned to existing projects will not change. Only the title changes.
• How projects are run: Workflow adjustments based on the new role definitions will be discussed individually for each project. Everything will not suddenly switch all at once on September 1.

Finally

Changing a name is easy. The difficult part is developing people who can actually work in a way that matches the name.

Even so, we decided to start by changing the title because names define the outline of a job.

As long as someone is called a “bridge,” both that person and the people around them tend to treat them as a passageway for information. Sometimes customers do too. In reality, many of our people are capable of stepping much further into the project, but the name itself was holding them back.

The title DM is intended to remove that constraint.

For every project you entrust to us, there will be one accountable person with a name and a face who owns the outcome. That will not change.

If you have any questions, please feel free to contact your sales representative or PMO.

Frequently Asked Questions

Q. Will the price change?
A. No. We will not revise pricing as a result of the title change.

Q. Will the person currently assigned to my project change?
A. No. The members who have been responsible as BPMs will continue in the same projects as DMs.

Q. Do we need to sign our contract again?
A. No. We will not ask customers to re-execute existing contracts solely because of the title change. Documents newly created on or after September 1 will be updated gradually.

Q. Will the way projects are run suddenly change in September?
A. No. The role definitions will officially change on September 1, but the actual way of working will transition in consultation with each project.

Q. Does this mean VFA is no longer doing offshore development?
A. No. Our development base remains in Vietnam. What is changing is the way we work: from receiving the “right answer” and building it, to finding the right answer together.