Why Build BNS PIS?

Connecting field facts, work schedules and people—without adding work for the system.

By Edward Kim | BuildNextSphere

A schedule can change without the people doing the work receiving a usable change. A report can say “complete” while the next activity is still unable to start. These gaps are not solved simply by collecting more information. The information has to reach the right person, in time, with enough context to support action.

That is the starting point for BNS Project Intelligence Sphere Platform—BNS PIS. Its direction grows out of my field-management experience and a work-management system developed and operated on a UAE underground storage project. It is not a claim that a general-purpose platform is already complete. It is an explanation of what I want to preserve, what needs to change, and why the first useful connection matters.

01. When personal effort reaches its limit

On an underground storage project in India, I encountered a basic but consequential difference: reported completion was not always the same as actual readiness. After excavated rock had been removed and loose rock scaled, material still had to be cleared from the floor near the excavation face. Water made that condition difficult to judge from a distance. If the area was not properly cleared, the following drilling operation could be disrupted and further rework could follow.

The coordination problem grew as more workfronts operated together. A machine needed in one tunnel might already be committed elsewhere. A late report of a breakdown could delay support. Revising one activity required knowing the condition of other workfronts, recalculating linked work and communicating the change. Walking farther and making more calls could not indefinitely compensate for a missing shared picture.

In that earlier setting, our responses included work records, an Excel-based schedule database, flexible vehicle dispatch, training and recognition of good performance. Those experiences shaped my thinking; they were not features of the later UAE system at that time. The lesson was to support cooperation with a dependable operating structure, rather than depend entirely on individual diligence.

02. A system should give time back

My concern can be stated simply: I do not want to add new documents and new work merely to serve a system. Paper, spreadsheets and telephone calls are not inherently the problem. The burden appears when the same status must be collected, rewritten, reconciled and redistributed repeatedly, while the people responsible for the work have less time to examine the work itself.

The design question is therefore not “What else can we ask the site to enter?” It is “Which necessary record can help more than one part of the work?” A field update should contribute to coordination, a revised forecast or a relevant notification—not become another isolated report that somebody must manually copy into a different format.

This does not mean that adoption requires no effort. People need clear responsibilities, training and support. The test is whether the total burden across roles becomes more useful and manageable. Saving time for a manager by moving excessive entry work to a supervisor would not satisfy the principle.

03. Connect the update to the next action

In the later UAE project, the work-management and mobile communication system connected work programmes, field status and communication. Mobile functions supported activity starts, finishes, pauses and time changes. The work programme connected activities and resources, while the operating centre and field teams had complementary roles in maintaining and using the information.

The important idea was the operating connection: update the condition where the work happens, reflect the relevant change in linked schedules, and communicate what affected people need to know. A colourful dashboard was not the purpose. The purpose was to help the next action reflect the current situation.

Verification still mattered. I have kept the principle that critical conditions must be checked directly. This does not require a PM to inspect everything personally; it requires the important check and its responsibility to remain visible. A reported finish, a received message and permission to begin the next activity are different facts. A system should not quietly merge them into one green status.

04. Calculation is not the same as changing the logic

When an activity takes longer than expected, a scheduling engine can recalculate connected dates using the established relationships between activities. This is ordinary logic-based calculation; it does not require us to label every calculation “AI”. The result also depends on the quality of the input and the relationships already defined.

A different question arises when those relationships should change. Could work be resequenced? Is a different resource arrangement feasible? What would that mean for access, safety, quality and other activities? For the future BNS platform, AI could help formulate and compare possible logic changes. Authorised people would decide which, if any, to adopt. This is a development direction, not a description of AI operating in the earlier system.

The same boundary applies to major resource decisions and work methods. A calculated forecast is not an approved baseline change. An AI suggestion is not an instruction, and a notification is not an authorisation. Keeping those distinctions visible is part of the product philosophy, not an administrative detail to add later.

05. Carry the principle, adapt the system

A system built around one underground project cannot become a general-purpose product merely by changing its name or simplifying its screens. Work structures, communication conditions, responsibilities and approval rules differ. What I want to carry forward is the connection between scheduling, mobile communication and review of planned versus actual work. Other functions must earn their place in the operating context.

Electronic work permits illustrate this point. They were not in the original scope. The paper approval process and the working hours of approvers did not fit the needs of a continuously operating site. A location-linked electronic permit function was subsequently developed and operated. It addressed a real operating need, but permit administration also carried a substantial burden. Actual use does not make it a compulsory feature for every future project. Choosing whether to include the software function does not make applicable safety procedures or work-permit requirements optional.

Location information can likewise support coordination without proving completion or safe conditions on its own. For BNS, office-based web access and field-based mobile participation are the intended foundation. Connectivity, fallback arrangements and role-specific access still need design. The past implementation provides experience to learn from; a reusable BNS product requires redevelopment and testing.

06. Start with value a site team can feel

The first intended users are construction managers and project managers. The first value I want them to experience is efficient work management: less separation between the schedule, actual work and communication. A familiar pattern is to prepare a spreadsheet, collect updates by phone or message, revise it, redistribute it and assemble the information again for a meeting. The goal is to reduce that repeated reconstruction of the same operating picture.

BNS Task Coordination Sphere is the first module direction. It should connect the next task, its conditions, the people involved and unresolved issues to a responsible decision and a checked result. That does not require every platform ambition to be available on day one. A bounded workflow should first show whether people can update information, understand a change and resolve a missing condition with an acceptable amount of effort.

Useful tests would consider entry and review effort, unresolved conditions found before work starts, decision waiting time and missed or unnecessary notifications. Those are proposed ways to learn, not published results. User feedback must shape the workflow before a broad platform story is treated as a product promise.

07. From field coordination to project intelligence

The longer-term ambition is broader: from field execution to executive intelligence. This means connecting what happens in the work to the project and organisational decisions needed to support it—and returning those decisions to execution. It does not mean sending every issue to senior management. The connection should follow the impact of the problem and the authority needed to address it.

The platform direction contains eight related capability areas. They describe a long-term map, not eight completed products or a fixed release sequence.

Work Execution Intelligence: Connect planning, assignment, communication, execution and confirmation.

Resource & Productivity Intelligence: Relate availability, allocation, waiting and utilisation to the work being performed.

Project Controls Intelligence: Connect field progress with schedule, cost and forecast review.

Procurement & Supply Intelligence: Relate work demand and required dates to supply, delivery and logistics alternatives.

Risk & Early Warning Intelligence: Bring unresolved conditions and signals into evidence-based impact and priority review.

Contract & Commercial Intelligence: Connect field events and records to appropriate contract and commercial review.

Document & Knowledge Intelligence: Make relevant records, communication, evidence and lessons available at the point of need.

Management & Recovery Intelligence: Support cross-project decisions on assistance, resources and recovery alternatives.

Consider an illustrative—not implemented—connection. A field team records a constraint. The responsible people examine the affected work, resource availability and schedule implications. If supply or a contractual issue is involved, the relevant specialists review it. A person with the necessary authority decides the response; the site receives the action and checks the result. Only the relevant areas participate. The record should retain its source, time, uncertainty and decision history as it moves between them.

Task Coordination is the first focus. BNS Contract & Claim Sphere is a named follow-on direction, intended to connect field events with records and specialist review—not automate legal conclusions or unauthorised notices. Shared records, permissions, communication and human responsibility are the foundation across the wider map. AI assistance belongs on that foundation; not every connection or calculation is an AI function.

BNS is not initially intended to replace every scheduling, enterprise, document or BIM system. Integration, data ownership and detailed interfaces remain design work. The business direction is to establish useful workflows, learn from users and expand where there is evidence of value. Reader interest is valuable feedback, but it is not proof of demand or performance.

Which piece of information on your project fails to reach the next decision or action? That is a useful place to begin. Through the following articles and the development process, I want to make those connections more concrete—without losing the people, conditions and responsibilities that give the information meaning.

Sources

Edward Kim’s first-hand project-management account, author-provided historical work-management material and follow-up clarifications of 1 October 2026. Internal records are not offered as public reference links.

Basis of This Article

The India management experience, the later UAE implementation and the proposed BNS platform are distinct. Edward holds quantitative field-management records but does not disclose them here. Improvement rates or independent effects are not inferred. Historical material contains different development stages; subsequent electronic-permit operation is confirmed by Edward. The capability map is a development direction, not evidence of a released product.

Read the PDF

Read or download the complete article (PDF)

Related Reading

Explore more from BuildNextSphere:

• When Projects Don’t Go to Plan: What Are We Missing?
• Smart Construction, More Tools—Why Is the Site Still So Busy?
• BIM vs Digital Twin
• Why Doesn’t Better Technology Always Deliver Better Construction Results?

BuildNextSphere

BuildNextSphere connects Development, Technology & Project Intelligence through practical, experience-informed content.

About the Author

Edward Kim is the Founder of BuildNextSphere. He draws on his experience with overseas construction projects to share practical insights from field operations, project delivery, and IT-enabled working systems. Through BuildNextSphere, he explores how people, technology, and real project conditions can help turn plans into action and support better project outcomes.

Content & IP Notice

This article and related materials are prepared by BuildNextSphere. Unless otherwise stated, the original structure, wording, diagrams and visual materials are the intellectual property of BuildNextSphere and Edward Kim. BuildNextSphere, its logo, tagline and brand assets are part of the BuildNextSphere brand identity. Unauthorised reproduction, modification, redistribution or commercial use is not permitted without prior written consent. Third-party names, technologies and references remain the property of their respective owners. General management principles are not claimed as proprietary inventions.

The illustrations are AI-generated concepts informed by historical work-management material and the proposed BNS direction, with layout and editorial direction by Edward Kim. Rights in historical source material remain separate from the new editorial composition. These are not current BNS product screenshots or operating instructions.