Hierarchy of Needs

Juval Lowy, April 2014

In 1943 Abraham Maslow published the pivotal work on motivation, known ever since as Maslow Hierarchy of Needs. Maslow showed that what makes all people do the things they do, and why they do those things, can be ranked in a simple hierarchy often depicted as a pyramid as in Figure 1.

Figure 1: Maslow Pyramid of Needs (Image credit Wikipedia, 2014)

Maslow's Pyramid of Needs

As complex as human beings are, Maslow's straightforward model accurately captures what makes them tick. It is a testimony to Maslow's astute observation that we now take it for granted.

At the bottom of Maslow's pyramid are physical survival level requirements, such as air, food, and temperature control. Above it are personal and family safety, then friendship, self-esteem and achievements, and topping the pyramid is fulfilling ones' true potential. Not all needs are equally important, and only once a person has satisfied a lower need can that person develop interest in satisfying a higher-level need. Conversely, if a lower level is suddenly denied, people will lose interest at the higher level they were at and will aspire to satisfy the now missing lower need. For example, someoneing through a family crisis (a threat at level 3) will often experience a serious drop of productivity and interest at work (level 4).

Software Projects Pyramid of Needs

The same hierarchal approach can describe another type of complex beings - software project. Figure 2 shows such a software project pyramid of needs.

Figure 2: Software Project Pyramid of Needs

Using Maslow's terminology as much as possible the project needs can be classified into five levels: physical, safety, repeatability, engineering, and technology:

  • Physical. This is the lowest level in the project pyramid of needs, dealing with physical survival. Much as a person must have air, food and water, clothes and roof over his head, a project must have a workplace (even a virtual one) and a viable business model. The project must have computers to write and test the code, as well as people assigned to perform these tasks. The project must have the right legal protection. The project must not infringe on existing external IP while at the same time it must protect its own IP.

  • Safety. Once the physical needs are satisfied, the project must have adequate funding (often in the form of allocated resources), and enough time to complete the work. The work itself must be performed with acceptable risk, not too low (because low-risk projects are likely not worth doing) and not o high (because high risk projects will likely fail). In short, the project must be safe. Obviously, cost, schedule and risk vary with respect to each other. For example, more aggressive deadlines could be more expensive and risky. The project senior management must choose the exact combination of schedule, cost and risk after examining several viable options up-front. These project design options should offer some trade of cost, schedule and risk. This level in the pyramid of needs is exactly what IDesign's techniques for project design are about, assuring the survival of the project. Without it, satisfying the needs in the upper layers is futile.

  • Repeatability. Borrowing the term from the CMM, project repeatability is the foundation for control and execution. It assures that if you plan and commit for a certain schedule and cost, you will deliver on those commitments. Repeatability captures the credibility of the team and the project. To gain repeatability you must manage requirements, plan ahead, track your progress against the plan, employ quality control measures such as unit and system testing, have an effective configuration management system, and actively manage outsourced work. Note that it matters not how you about achieving repeatability- you can use an iterative process like SCRUM or a highly structured approach.

  • Engineering. Once the repeatability of the project effort is secured, the software project can for the first time turn its attention to the enticing aspects of software engineering. This would include activities from architecture and module detail design to quality assurance activities such as root cause analysis and correction (on a systemic level) and preventative work using harden operating procedures. For example, the IDesign Method for system decomposition operates at this level in the pyramid of needs. Collecting various metrics on your progress is just as important at the engineering level. Metrics allow you to control and even improve the environment. Good engineering involves conducting technical reviews not just of code but also of requirements, design and test plans, utilize the organization economy of scales and employ reuse program and standards, as well as train the technical staff to maintain their edge.

  • Technology. Finally, at this level we see the relevance of items such as development technology, tools, methodology, operating systems and related hard-core technical aspects. This is the very pinnacle of the pyramid of needs, and it can only express itself to its full potential once the lower requirements are fully addressed. This is where software developers can reach their self actualization, in perfect analogy to level five of Maslow's pyramid.

We constructed the pyramid by first listing all necessary ingredients for success of a typical software project, and then prioritizing and sorting them. We then grouped the elements of success into categories of similar criticality.

The sorting was done using a simple Ishikawa-like analysis based on common sense and experience. For example, in deciding if architecture is more or less important than technology, we considered two projects: the first with a tightly-coupled design, high cost of maintenance, low level of reuse, difficult extensibility, but with a team that uses the latest and greatest technology. The team has in fact mastered the technical domain and the related methodology. The second project has a decent (not even great) architecture, with relatively loosely-coupled components, a modular approach with layers and the right abstractions, the requirements volatility is encapsulated and there is some potential for reuse and extensibility across versions. However, the technology for that project is out of date, is not optimal for this project, there are new team members than are not familiar with the technology, and the tools leave much to be desired as far as productivity and automation. We asked ourselves: which project will have a faster time to market with a new feature? Which will have lower cost of ownership? Which will have higher quality? Which project will benefit from a lower staff turn over rate? Which projects will have the team members with higher motivation and effectiveness? Which projects we would like to be part of? The answer unequivocally is of course the second project, so architecture must therefore rank lower in the pyramid of needs compared with technology. Similarly there is no point in having a great architecture if the project is not given enough time and resources to build it (safety in the pyramid) or if there is no business model that will ensure viability of the business to keep the lights on (the first, physical level).

Conclusion

The analogy to a person hierarchy of needs is very appealing because it prioritizes various needs and prescribes how something as complex as a software project thrives or fails and why. Often projects fail in spite of heroic efforts of the team and the project leads. The reason is invariably a failure to satisfy a lower need (such as adequate funding or risk management), while spending the effort at a higher level such as mastering the technology. In fact, we see such inverted pyramids as the dominate cause of failure of software projects. Much like a person, there isn’t a single thing, or even a single area of needs that assures a project success. Common models describing how a project should behave (from CMM to Agile) fall short because they tend to be unidimensional, focusing on a single axis such as the process or the architecture. It is the proper intersection of multidimensional aspects that assures the project's success. It is up to the project leads to manage and execute all aspects from safety via project design to engineering excellence via architecture and then mastering the technology. What is perhaps now more evident is the relative importance of these elements, and therefore the time that should be spent perfecting and controlling the project hierarchy of needs.

IDesign's Architect's Master Class maps well to the top three layers in the project's pyramid of needs. The Master Class shows the architect how to take an active leadership role on the process, the design and the technology, as a continuum, since all three have to work in concert.