Complex projects have an uncomfortable paradox. A company can have excellent specialists, a clear strategy, an experienced technology team, strong marketing, a solid product and visible executive sponsorship. Each function can perform well on its own, yet the project still slows down. Decisions collide, timelines drift, and the final outcome becomes weaker than the sum of the effort invested in it. The instinct is usually to look for the problem inside the functions. Review IT. Change the process. Strengthen project management. Clarify KPIs. Add another layer of meetings. But sometimes the real problem sits somewhere else entirely.
It sits between functions. That is where strategy has to become product. Product has to fit the technology architecture. Technology has to account for customer behaviour. Marketing has to know what is actually going to market and when. Customer Service has to understand the journey users are about to experience. And the decisions of different departments have to form one system before each function starts optimising its own piece. After years of working on complex projects, I have come to see this space as a distinct professional discipline. I call it Strategic Project Architecture.
The more complex the project, the less its outcome belongs to any one function — and the more important the architecture of the connections between them becomes.
A mobile bank as a test of organisational architecture
I saw this particularly clearly in my work with Converse Bank. At first glance, the assignment sounded familiar enough: develop the mobile bank. But a mobile bank stopped being “just an IT product” a long time ago. For a bank, it is technology, a product channel, the customer interface, a sales tool, part of the brand, a communication environment and, increasingly, the primary point of daily contact between the customer and the institution.
Each of those dimensions belonged to different people and different functions. The technology team owned implementation and stability. Retail owned banking products and business logic. Marketing owned the proposition, communication and perception. UX owned user journeys. Information Security owned constraints and risk. Customer Service lived with the consequences of all those decisions in real conversations with customers. That is why the development of the mobile bank very quickly stopped being a development problem alone. At the beginning of 2023, the bank’s CEO proposed changing the way the direction was managed. I responded by proposing a CFT — a permanent cross-functional team organised around the product itself.
The model was supported, and the heads of Retail and mobile development became particularly deeply involved in making it work. For me, that decision became important far beyond one project. In effect, we changed the object of management. Previously, it was easy to think of the mobile bank as a sequence of tasks moving from business to IT, from IT to marketing, and onward through the organisational chain.
Under the new model, there was a common decision-making contour in which the product could be seen as a whole. That is a fundamentally different architecture.
The most expensive mistake is to manage one part of a system as if it were the whole system
Most companies are organised by function. That makes sense. Finance should be good at finance. IT at technology. Marketing at marketing. Retail at business. The problem begins when the company’s real outcome no longer fits neatly inside the boundaries of its organisational chart. Customers do not see departments.
They see one mobile bank. They do not care which team owned a particular screen, who approved the copy, who set the business rule or who handled the integration. If the application is difficult to use, the bank is difficult to use. If the communication promises one thing and the product behaves differently, the company has failed in the customer’s eyes.
Yet internally, the organisation may be made up of teams that have each, formally, done their job correctly. That is why one of the most important questions in any complex project is deceptively simple:
who owns the outcome that exists between functions?
There is rarely an obvious answer. The project manager owns movement. The product owner owns the product. Functional leaders own their domains. The CEO owns the business as a whole. But who designs the system of dependencies between those levels? That is where Strategic Project Architecture begins.
Strong specialists do not automatically create a strong system
Converse Mobile offered this lesson repeatedly. Take information security. Any serious security decision has a technical dimension. In a mobile bank, however, it almost inevitably has a customer dimension as well. Change a security rule and the login journey may change. Change the login journey and the explanation to the customer may need to change. That explanation then touches interface design, copy, Customer Service and sometimes marketing communication.
A technically correct decision has to travel through several professional languages before it becomes a good customer experience. The same was true of UX. You can conduct excellent user research. You can produce strong design. You can build elegant prototypes. But between research and a working product lies a long chain of decisions.
Which findings become product priorities? Which require changes in business logic? What is technically feasible? What belongs in the current development cycle? How will a new solution affect existing journeys? How should it be explained to the user? Research by itself does not change a product. Design by itself does not either. Value appears when different disciplines are connected through one coherent decision process.
Complex projects rarely fail because professionals are missing. More often, they lose speed and quality when decisions pass from one professional world to another.
The architectural gap
Over time, I began using the term architectural gap for these situations. It is the point at which the necessary components of a project all exist, but the mechanism that connects them is insufficiently defined. There is a strategy. There are teams. There is a budget. There is a roadmap. There is accountability inside each department. And still, critical questions fall through the spaces between them.
Who decides when business and technology offer two equally defensible options? Who determines sequencing when one team’s work depends on another team’s decision? When exactly should marketing receive information about an upcoming release? How does customer feedback become a product priority?
Who sees that a locally efficient decision in one department is creating a problem for the system as a whole? These are architectural questions. Another meeting rarely solves them. The problem is seldom that people do not communicate enough. Sometimes they communicate too much.
The problem is the absence of a structure that defines which decisions must be made jointly, where ownership sits, and how dependent decisions are converted into one forward movement of the project.
Why project management is not enough here
Good project management is enormously valuable. It keeps control of timelines, tasks, resources, dependencies and execution. But there is a level of work that comes before the task list. Imagine the following situation.
Business wants to launch a new product. Technology sees an architectural constraint. UX knows the initial customer journey will be difficult to use. Marketing is already building a market proposition around the product.
Management expects a specific commercial outcome from the launch. What exactly should go into the task tracker? First, the structure of the decision itself has to be defined. Perhaps the product needs to change.
Perhaps the development sequence needs to change. Perhaps the proposition needs to change. Perhaps expectations around timing need to change. Perhaps even the way success is measured needs to change.
Only then does the project become a manageable set of tasks again. This is where I draw an important distinction.
Project management organises the execution of a structure. Strategic Project Architecture helps create that structure.
What a Strategic Project Architect actually does
I use the term as a description of work, not as a fashionable job title. The first task of a Strategic Project Architect is to expand the object of management to its real size. When a company says, “we are building a new app”, the real project may include a product model, operating processes, technology, customer experience, marketing, support, data and changes in employee behaviour. If the organisation manages only the application, much of the actual project remains outside the common architecture.
The second task is to identify dependencies before they become problems. Which decision enables the next one? What cannot be done in parallel? Which functions have to agree before implementation begins? Where does a change in one part of the system automatically alter another? The third task is to design the decision architecture. In complex projects, it is not enough to define who does what.
It is more important to define who makes which decisions with whom, at what level, and on what questions. The fourth task is to create shared working artefacts. That may be a blueprint, a roadmap, a decision register, a matrix, a unified design system or another tool. The label matters less than the function. A good artefact does one essential thing: it gives several professional teams one version of reality to work from.
And the fifth task, perhaps the hardest, is to protect the overall outcome from local optimisation. Almost any department can demonstrate that it is acting rationally within its own frame of reference. That does not necessarily make the project better.
The CFT was not a way to hold more meetings
That is exactly what the cross-functional team meant to me in Converse Mobile. We were not trying to replace professional functions with one generalist team. Their expertise stayed where it belonged. What changed was the system of connections between them.
Retail brought the business logic and product understanding. Mobile development brought technological feasibility and constraints. Marketing brought the customer, the proposition and communication. Other functions joined when a decision required their expertise. There was now a common contour in which contradictions could be identified earlier and discussed as part of one product. Over time, research, UX, customer feedback, design and new product decisions became more deeply connected to the same system. I do not consider the most important result of that model to be any single release.
Something more fundamental changed. Inside the organisation, the mobile bank began to exist as one product, rather than as a collection of tasks distributed across several departments. That is a structural change.
A project is especially vulnerable when everyone is right
Some project problems are obvious. There are not enough resources. A team made a mistake. The technology does not work. The strategy is unclear. Those situations are painful, but relatively easy to diagnose. The harder project is the one in which everyone is right in their own terms.
IT is right to protect the architecture. Business is right to demand a commercial result. Marketing is right to think about the customer and the market. InfoSec is right to constrain risk.
UX is right to insist on usability. The management challenge begins when all those professionally correct positions have to become one decision. That is why today, when I enter a complex project, the task list is not the first thing I look at. I look at the connections.
Where does ownership of the result sit? Which decisions cross the boundaries of several functions? Where are different teams using different definitions of the same problem? Which dependencies does no one see in full?
At what point can a professionally correct decision by one team damage the overall outcome? Very often, the real problem of the project is there.
The architecture of the outcome
Over the past several years, my view of complex projects has changed substantially. I see them less and less as sequences of tasks and more and more as systems of interdependent decisions. Strategy shapes product. Product changes technology. Technology shapes customer experience. Customer experience affects communication and sales. Real customer behaviour returns to the product and changes strategic choices again. This system exists simultaneously in several professional worlds.
The person responsible for its integrity does not need to be the best programmer, the best marketer or the best product expert in the room. The job is different. They need to understand enough about each discipline to see the space between them. And they need to recognise the moment when a project stops being a collection of professional decisions and requires an architecture that can turn those decisions into one outcome.
That is what Strategic Project Architect means to me.
The strength of a complex project is determined not only by the quality of its parts, but by how well those parts can operate as one system.
Today, companies increasingly assemble that system from very different sources. A strong technology team can be brought in from the market. UX/UI can be entrusted to a specialist agency. Inside the company, Retail, Marketing, Finance, Compliance and Operations are already in place. The investor or owner brings the idea, the ambition, the budget and the deadline. The problem begins when all those strong participants have to become one project. Who connects the business vision to the technology architecture? Who ensures that product, customer experience, the operating model and communication develop in sync? Who sees the contradiction between two professionally correct decisions before it becomes an expensive rework? Who keeps the entire outcome in view — from the original ambition to the moment when the solution genuinely starts working for people?
Building every required capability inside one company for every major initiative is often too slow and too expensive. The modern market already knows how to buy excellent specialist expertise from outside. But the more of that expertise a project brings together, the more valuable its orchestration becomes. That understanding is why I founded USPACE. USPACE works with owners, investors and company leaders who are launching complex, integrated initiatives and want to move from ambition to a working result while keeping timing, investment and decisions under control. We can work alongside internal teams, technology partners, agencies, consultants and other external experts. Our role is to turn those strong components into one functioning project architecture and preserve its integrity as the project grows more complex.
Because in the end, what matters is not how many teams were involved, how many documents were produced, or even whether something was formally launched. What matters is something else.
Was the original vision actually realised? Did the project remain within a rational timeframe and investment logic? And, most importantly, did people — external customers or employees — receive a solution they genuinely use?
When that happens, the project is finished. Until then, the architecture of the outcome still needs to be managed.
