• Research Team
  • Co-ordinators
  • - Hall, Jon
  • - Rapanotti, Lucia

G.F.C Rogers, in his book "The Nature of Engineering" (1983) defines engineering as: “[...] the practice of organising the design and construction of any artifice which transforms the physical world around us to meet some recognised need.”

Problem Oriented Engineering (POE) asks the fundamental question of how Rogers’ notion of engineering can be embedded in a theoretical framework in which engineering practice is conceived as a problem solving process, and explores the benefits and limitations of such an embedding in professional practice. 

At the heart of POE is the framing of a problem as a process of discovery of relevant knowledge pertaining to that problem’s elements, and from that synthesising knowledge of the solution to meet some requirements in a real world context. Engineering a solution is then a problem solving process in which interlocked steps of exploration and validation are repeatedly carried out: exploration is used for knowledge discovery and representation; validation is for quality assurance and risk management. POE recognises that situated nature of engineering problems allowing for the exploration of ecologies of problems.

The problem as a force for good

Problems have had a bad press, and the term is often used pejoratively: walking into an organisation that serves its stake-holders well and saying it has problems is not always welcome. Yet, problem solving is an integral part of much professional practice in organisational IT and an essential step towards artefacts that are fit-for-purpose and which meet their stake-holders’ needs.

POE focusses on problems as a crucial organisational concept by promoting the notion of problem as a force for good. Recognising and understanding organisational problems allow us to be purposeful and reasoned in our move to organisational solutions: after all, such a move is expensive both in time and money. It also allows us to work iteratively to increase our understanding: solutions are sometimes straw-men, allowing us to reflect on the problem to understand it better.


Above all, POE recognises that our endeavour revolves around those with problems that should be solved: the stake-holders that live in the environment into which the solution will be installed. They hold the bar over which we must jump, most often they will pay the costs and so deserve to be able to say that’s not right!

Back to first principles

POE isn't just another design and development method. There are already so many (too many?) to choose from, yet IT projects still fail at an alarming rate. Instead, POE goes back to first principles: whether you go Agile or follow a plan, it provides you with a lens through which you can look at your processes and practices and ask questions that may help you improve them. The variables in play are problems, solutions, resources and risks: gaining understanding of problems and solutions, and iterating between the two consume resources; communicating to, and reaching agreement with, stake-holders based on such an understanding reduce risks. Balancing their trade-offs is what POE brings to the table.


POE has been applied in real-world organisations to address real-world problems from safety systems engineering, to finanical IT, to a range of IT Governance issues and intitiatives.