In the midst of the daily rush of delivering technological products and projects, we sometimes find ourselves questioning whether we are doing the right thing. Am I delivering what the project manager wants? Am I delivering what the user wants? Are they the same thing? How do I know the requirements are the right requirements? It’s helpful to have a model which can guide us through these questions.

Rimonov’s tower of activity

Rimonov’s tower of activity is such a model. It describes the path from initial observations to project activity, and thus enables us to check how our current activity relates to any other activity in and around a project — whether it’s a future, current or past project being reviewed. It’s loosely related to the ladder of inference and Maslow’s hierarchy of needs. Evgeny Rimonov was a professor of computer science who I’ve just made up off the top of my head because “Silver’s tower of activity” sounds too pompous.

The model tells us that from observable data we can infer needs; needs can be packaged and met by a product; a product can be expressed as a collection of requirements; and requirements can be packaged conveniently as projects.

A simplified example: cars are desirable but expensive, and mass production can reduce costs (observable data); people will value owning cars if the cost is lower, even if the product options are limited (needs); a mass-produced car will meet these needs (product); we have the design of the car and the factory (requirements); we will approach investors with this packaged proposal so that we can implement it and deliver returns to them within a given timeframe (project).

Each layer is smaller than the one below because it does not seek to address everything it might be based on. So: we observe lots of data, but filter out the the irrelevant data when deciding what needs we might address; users may have many needs, but they won’t be univerally met by the product; the product may be have a grand vision, but we will only capture what’s practical for now in the requirements; various projects will deliver the requirements, but inevitably some will be descoped.

Using the tower

Projects, then, are based on several foundational layers, and if any one of the lower layers is flawed, or found not to exist, or becomes detached from the others, then it undermines the validity of the higher layers.

If you find yourself working on project requirements that seem questionable then it’s worth testing the basis of those requirements. A quick question to the right person may reveal immediately the research the requirements were based on — maybe even a video showcase from one of the user experience team. Or maybe the underlying need is less clear, in which more difficult questions need to be asked.

Even an architecture can be considered a product: if it needs to support multiple projects in a shifting business environment, then explicit care needs to be taken over monitoring that shifting environment, identifying needs, and evolving the architecture so that it stays ahead of the projects’ needs. The person who does this may be (or be labelled as) an architect or a product manager.

But in any of these examples if the lowest (data) layer changes — e.g. updated data comes in contradicting earlier findings, or the business environment changes — then the project should be rethought and perhaps terminated.

It’s interesting to note that lean startups and agile development methodologies both aim to eliminate the risks that derive from the reliance of each layer on the one below it. They seek to dramatically tighten the feedback loop so that requirements are much more tightly linked to observable data.

Additionally, since the project layer is a often a form of packaging to satisfy budgeting, it’s possible to do away with that layer entirely and instead implement some kind of flow of continuous delivery.

Overall, the model is a useful way of quickly checking that any current or potential activity is based on the right foundation.