When Solar + BESS project delivery outgrows the operating model
The problem is not necessarily that your teams lack software. It is that engineering, procurement, construction and commissioning no longer operate from the same model.
As project volume grows, experienced people become the integration layer between engineering, procurement and construction. BoRo designs how the delivery organization should operate, then implements the systems that operating model requires.
Who does BoRo work with?
BoRo Studio works with growth-stage Solar and BESS project delivery companies: EPCs, developer-EPCs and integrated project-delivery organizations, typically 50 to 300 people, running several projects at once across engineering, procurement, construction and commissioning. The usual trigger is that the company grew faster than its operating model.
Written forCOO · VP Operations · Head of Project Delivery · VP Projects · Director of Operations · PMO and project controls leadership · founders and CEOs of growth-stage firms
The company grew faster than its operating model
Nothing broke on a particular day. Each project added a little more coordination than the last one, and the people absorbing it are the ones you can least afford to lose to it.
- More projects require disproportionately more coordination.
- Project managers spend a growing share of the week reconciling information.
- Project status lives in several systems, and none of them is the agreed one.
- Approved changes propagate inconsistently from one project to the next.
- Procurement works from engineering information that is already stale.
- Field execution discovers decisions late.
- Senior people resolve the same coordination failure again and again.
Where in the project lifecycle
BoRo works on operational execution after commercial award. We do not design origination, sales or commercial strategy.
- Upstream contextOpportunity / Award
- BoRo's focusPreconstruction
- BoRo's focusEngineering
- BoRo's focusProcurement
- BoRo's focusConstruction
- BoRo's focusCommissioning
- BoRo's focusHandover
Handoffs are where most of the work is: development and preconstruction into engineering, engineering into procurement, procurement into construction, construction into commissioning, and commissioning into handover.
Coordination Latency
The time between a decision or change being approved and every function operating from the same reality.
Engineering approves a change.
How long until each of these is operating from that same decision?
Procurement
Is the open purchase order revised, or was it already released against the old revision?
Project controls
Does the forecast carry the new scope, or does it change at the next reporting cycle?
Construction
Is the crew building to the current drawing, or to the one that reached site last week?
Commissioning
Does the test plan know, or does it find out at energization?
In most growing delivery organizations nobody can answer that with a number, because the propagation path was never designed. It happens when someone remembers.
Human Middleware
Project managers and senior staff become the manual integration layer. They carry context between teams, meetings, spreadsheets, emails and systems, because no defined handoff does it for them.
It works, which is why it is hard to see. It also does not scale: every additional project consumes more of the same few people, and what they know about the state of a project is not written anywhere a second person could read it.
- The real status of a project is whatever the project manager says in the weekly call.
- A change is only safe once a specific person has personally told procurement.
- Onboarding a new project manager takes months, because the process lives in people.
- When one senior person is out, several projects slow down at the same time.
Fragmented Operational State
Different teams and systems hold different versions of the state of the project. Individually good software can coexist with a broken operating model, because each tool is correct about its own part and nothing says which one is the record for the whole.
- Project management
- ERP and finance
- Procurement
- Document control
- Scheduling
- Field execution
Each of these can be the right tool for its function. The operation is still incoherent if none of them is the agreed record for where a project stands, and the reconciliation lives in a weekly meeting.
What usually sits underneath
The three patterns above are what leadership feels. These are the structural causes an architecture has to resolve.
Change propagation failure
An approved change does not reliably travel from engineering to procurement, project controls, construction and commissioning.
Handoff failures
Work changes hands between phases without an agreed definition of what is being handed over, or of what done means.
Undefined lifecycle ownership
Each function owns its phase. Nobody owns the state of the project across all of them.
System-of-record fragmentation
The same fact is kept in several systems and no rule says which one wins when they disagree.
Capacity ceiling
The company cannot add concurrent projects without adding disproportionate coordination overhead.
How the Architecture Sprint diagnoses it
About ten business days, working from what your projects already produced rather than from a questionnaire.
Lifecycle states
The states a project and its work packages actually move through, and what must be true to leave each one.
Ownership
Who owns each state, and who owns the project across functions.
Handoffs
What is handed over between phases, to whom, and how the receiver knows it is complete.
Change propagation
The path an approved change takes through every function that has to act on it.
Systems
Which system is the record for which fact, and which ones should only read it.
Exceptions
What people do when the normal path does not apply, and who is allowed to decide.
Decision rights
Who decides what, with which information, and who has to be told.
A sprint can conclude that no custom software should be built. That is a real outcome, and we deliver it.
Technology follows architecture
If the architecture identifies a systems gap, there are four ways to close it. Which one applies is an output of the sprint, not an opening position.
Connect
The systems are right but they do not talk. We build the integration and the state ownership rules between them.
Extend
The system of record is right but incomplete. We add the operational layer it is missing.
Replace
A system is actively holding the operating model back and has to go.
Transform
The operation needs a control layer that does not exist in any product you can buy.
Is this a fit?
Good fit
- Several concurrent projects
- Multiple specialized teams
- Several systems, each good at its own part
- Coordination load rising faster than project volume
- Experienced people acting as the integration layer
- Growth exposing weaknesses in the operating model
Not a fit
- One small team
- One simple workflow
- Standard software already solves the operation
- The main need is inexpensive development capacity
What we can and cannot show you
Solar + BESS project delivery is BoRo's current commercial focus. We do not publish client case studies from this sector and we will not imply any. What we can show is real work in other operations, and example architectures for project delivery that are labelled as examples.
Further reading on project delivery
- Human Middleware in Project DeliveryHow experienced people become the integration layer between engineering, procurement and construction.
- Coordination LatencyHow long does it take for one project decision to become operational reality?
- Engineering Change PropagationHow an approved change should move through engineering, procurement, project controls, construction and commissioning.
- Fragmented Operational StateWhy individually good systems can still produce an incoherent project operation.
- Project Delivery CapacityWhy adding more projects can create disproportionate coordination overhead.
Discuss an operational constraint
Tell us where coordination is costing you. If the answer is that you do not need to build anything, we will say so.
Discuss an operational constraint