Considering boundaries in project management

In recent Systems Thinking Interest Network discussions, members were sharing their views on system boundaries and their relevance to delivering projects effectively. This blog article seeks to introduce the boundary concept to project professionals as an essential tool in maximising outcomes of benefit and managing risks related to scope, stakeholders and deployment.

What is a system? And a boundary?

Let’s start with the definition of a system first; this can be anything, tangible or intangible. Don’t think specifically “IT systems” although it may include one. As Donella Meadows expressed in her book “Thinking in Systems” (2008):

"A system is an interconnected set of elements that is coherently organized in a way that achieves something."

Meadows continues by noting three components: objects, interconnections (relationships) and a purpose.

Think of the full end-to-end process, for example, the payroll system. It’s a simple system – it’s just there to pay employees, right? But an alternative perspective is it’s to collect tax via PAYE. As an employee, it’s there to pay me but also to ensure I’m taxed correctly as an employee, obtain my payslips when I need them etc. The purpose depends on who you are. Although not defined in Meadows’ definition of a system above, an important aspect is understanding perspectives; the perspective of people shapes what is of relevance or not; by way of example, from the Finance Manager’s perspective the payroll system isn’t directly of “interest” but from their viewpoint, it’s valid because they need the figures and breakdowns each month to feed into the company accounts.

Already you can see that with a little thought within the system, suddenly it’s grown arms and legs but at the same time these all must be considered. Certain things may be connected as part of the system but so simply or tenuously that you decide that it’s unimportant to your focus. You draw a ‘virtual edge’ to exclude this. After all, everything is connected to everything else, so without excluding items that you deem irrelevant, you’re looking at literally the universe.

This virtual ‘edge’ is the boundary – a conscious decision as to your field of engagement at the outset and with an understanding that you’ve considered how everything ‘ticks’ within that field of view. You’ve looked at your project mandate or other project documentation, you’ve looked at how problems and systems are all interconnected, assessed the purpose of the systems effected (or ought to be affected) and you’ve decided what is relevant and what isn’t.

Everything outside of the boundary is now effectively the ‘fog of war’.

So, is a boundary the same as a project scope?

No. This is a common misconception; in some cases, they may be the same, but they don’t have to be. For example, you could see an organisation’s “problem” that your project aims to address as requiring a number of individual projects, all with discrete scopes. Also, the project scope refers to ‘depth’ (requirements, quality) as well as breadth across an organisation.

Why is it so important that the boundaries are appropriately judged and set?

If not, you may have one of two negative outcomes:

The boundaries are too broad

You're considering too much within the scope of the project. Much of this is likely to be irrelevant and needlessly contribute to project ‘noise’. This level of complexity reduces your project success; you may find that your project doesn’t ever get anywhere. The broader the boundaries, the more likely you have different stakeholders that need further effort to manage, all for limited reward. To quote an old colleague, “the ship mustn’t be so heavy that it never leaves port.”

Or more commonly…

The boundaries are too narrow (restrictive)

Your project is likely to trigger unintended consequences because you’ve failed to see the full impact(s) of a change –organisational Jenga where you’ve not looked at the full stack before pulling a piece out. Things may unexpectedly come out of the woodwork, increasing the chance of change requests. Early decisions may come back to haunt you when these changes are accepted and had you known this from the start, you’d have done things differently. You may miss obvious opportunities by delivering a larger project that encompasses more value. Remember when HR implemented their own IT system, but the organisation didn’t consider rolling this together with Payroll? You’ve now got two systems instead of one, or a late requirement to get the two to talk to each other to make the whole thing work afterwards.

Restrictively defined boundaries increases the chance that your project is not going to deliver the benefits expected; you hadn’t considered the full systemic effect of the change, so how are the benefits/disbenefits going to be accurate?

Key messages

Consider scope in line with the boundaries; resist the urge to do series of projects unless you understand the consequences with each one. The Butterfly Effect (the phenomenon and the 2004 film) and more recently The Flash (2023) explore this on a far grander scale!

Re-evaluate boundary decisions during the project lifecycle; learning as you go is normal.

Be conscious of bias – both of actors within the organisation, and your own!

Read the Systems Archetype works of Peter Senge, in particular “fixes that fail” as this further documents how ‘unintended consequences’ come about in an organisational setting.

Never lose sight of the purpose of a system, and that this purpose can vary depending on who you're – some of these purposes may also be in contention with each other.

In the words of Stafford Beer, “the purpose of a system is what it does” (POSIWID).

Consider delivering change against as much of the system (boundary) as possible, to reduce ‘unexpected consequences’ – but if you can’t, ensure the impact(s) of doing it piecemeal are known, appropriately managed (risk management), before conducting your ‘surgical strike’.