Simplifying Complex Operational Planning Across BP Sites

I had to understand the operating model

AIW supported work preparation from the 12-week schedule through 6-week and 2-week readiness stages into the 14-day execution schedule. The same activity could carry schedule dates, ownership, readiness, execution risk and Control of Work information. That context mattered because a seemingly small change to one row could affect how people interpreted whether work was ready, blocked or moving through the schedule.

The product structure, underlying systems and wider workflows were already established. I used that context to decide where my changes could add clarity without destabilising what users already relied on. The strongest parts of my contribution were therefore deliberately focused: status communication, readiness entry points and the expanded activity hierarchy.

Project context: AIW sat across work preparation, readiness and execution rather than a single isolated task.

Operational status had to be visible before users opened the activity.

Testing identified a specific need: users wanted to recognise new and rescheduled work at first glance. The activity list already contained dates, specialists, schedule gates, readiness and Control of Work information, so the answer could not be another large column or banner. The status treatment had to work inside the existing density.

I designed the coloured row markers and the placement of states such as Blocked, In Progress and Not Started, together with compact Rescheduled, New and SCW tags. I also designed the visible Update Readiness treatment in the row. The aim was to create a consistent visual layer that could be scanned quickly without competing with the operational content around it.

Full activity list context. The status language sits inside the existing AIW data density rather than replacing it.

The expanded state had to reveal more without becoming another page.

Expanding an activity exposed significantly more operational detail. The challenge was not deciding what could be deleted; users needed much of the information to understand the work. My task was to organise it so the activity remained recognisable while the additional detail became easier to scan and compare.

I structured the expanded layout around three levels: persistent activity context at the top, supporting SAP and operational detail in the middle, and related execution activity beneath it. Readiness, permits and isolations stayed attached to the work rather than being pushed into a separate screen, which allowed users to inspect more information without losing their place in the schedule.

Expanded activity layout showing the hierarchy I designed for the important operational data.

Bulk readiness needed a clear decision about what would be updated.

Readiness updates could affect more than one activity, which made the point of entry important. I designed the interaction that allowed users to choose the scope before entering the readiness process rather than discovering the scope after the action had begun.

The menu made two intents explicit: select all items on the current page and update readiness, or update only the items already selected. That distinction matters in an enterprise list because the same screen can contain several work scopes and a large number of records. The interaction gave users a clear boundary around the bulk action at the moment they initiated it.

Full AIW context showing the bulk readiness entry point inside the activity list.

The entry point had to connect cleanly into the wider readiness journey.

The bulk action did not exist in isolation. It handed users into the wider readiness sequence, which covered functional readiness, Management of Change, review and confirmation. Showing the full flow here matters because it makes the role of my interaction clear: the scope had to be defined before users entered a process that could update several activities.

Testing changed the detail, not the product direction.

The product already had an established direction, so the value of testing was in refining how the interaction worked inside real constraints. The clearest recorded finding from my phase was that users needed to identify new and rescheduled work at a glance. That finding directly shaped the status language rather than triggering a redesign of the wider product.

The same pattern applied across my work: preserve the operational model, identify where interpretation or action was unclear, and improve that point with the smallest change that still made the behaviour understandable. This is why the case study focuses on interaction detail, hierarchy and scope rather than presenting a generic end-to-end design process.

The result was a clearer interaction layer inside an established enterprise product.

My direct deliverables were focused but meaningful: a visual language for important activity states, clearer entry points for updating readiness, a bulk-action interaction that made selection scope explicit, and a structured expanded activity view for dense operational information. Together, they improved how users could interpret and act on work without requiring the wider AIW product to be rebuilt.

I did not remain on the project through go-live, so I would not attach later adoption or efficiency claims to my individual contribution. If I were taking the work forward today, I would instrument status-recognition accuracy, time to locate critical information in an expanded activity, bulk-selection errors and readiness-task completion. Those measures would give the next iteration a stronger behavioural evidence base.