Maslow's Hierarchy of Needs for Project Organizations

Some projects are disasters from the start; some are joyful expressions of human achievement. What determines whether a project will be a nightmare or a dream come true? If we knew what it took to create wonderful, memorable, productive projects, we would enjoy work so much more, and we would produce wonderful things that make a real difference in the world. All of us want to participate in such projects. Why are they so rare? What does it take to create them?

The knee-jerk answer — to "throw money" at the project — just doesn't work. We all know about projects that failed miserably, yet had only to think about requesting some additional resource, and it was theirs. Such projects are usually so well connected that they can even declare themselves successful, despite failing to meet any of their original goals.

So if money isn't the only requirement, what makes excellent projects?

Projects are like people. They can be stubborn or cooperative, miserable or fun. Like people, they have needs. Unmet needs affect the project's behavior. In Motivation and Personality (1954), Abraham Maslow [Maslow 1987] described human motivation as a search to meet basic needs, which he organized hierarchically. In this hierarchy, the lowest level unmet need determines motivation. Once we secure gratification of a need, the next higher unmet need dominates, and the search for its gratification organizes our behavior.

This model raises two important questions about managing projects. First, can we construct an analogous Needs Hierarchy for projects? Second, how well does that hierarchy explain project behavior? Answers to these questions could provide guidance to managers of troubled projects. The key concept is to focus management effort on the lowest level unmet need, since it dominates project behavior. When we do, we discover a simple way of understanding what a project team must have before it can produce high quality deliverables in a timely fashion, for predictable costs.

To understand this model of project needs, we must first understand Maslow's model of human needs. Once that's available, we can map that model from the space of human psychology into the space of project dynamics, to derive the hierarchy of needs for project organizations. This exercise is more than a mere curiosity — it leads us to these insights:

• Reducing resources depresses performance
• Organizational turmoil depresses performance
• Team building efforts can help — maybe
• Recognition and rewards drive delivery
• Projects that are aligned with business objectives are more likely to succeed

The Hierarchy of Needs for Project Organizations tells us what conditions must be present for these effects to work.

Maslow's Hierarchy of Needs

Let's begin by reviewing Maslow's model. The levels of Maslow's Hierarchy of Needs range from the lowest level physiological needs to the highest, called self-actualization.

Self-actualization Our need to actualize our potential as humans. Because each of us is unique, this need expresses itself uniquely for each individual. Esteem Our needs for achievement, adequacy, recognition, status, appreciation, and mastery. Belongingness and love Our needs to give and receive affection, to relate to other people, family, and friends. Safety Our needs for security, stability, and freedom from fear and anxiety. Physiological Our fundamental needs for food, water, sleep, touch, shelter, sex, and exercise.

A Needs Hierarchy for projects

By analogy with the Hierarchy of Needs for people, we can conjecture a hierarchy of needs for projects. For example, the concept corresponding to "Belongingness" is an alignment between the project goals and the business purpose of the overall organization.

Delivery actualization The need to deliver as promised, on time, and on budget; to deliver unexpected but necessary and welcome results at no additional cost. Esteem The need to be planned and executed well; to be novel and challenging; to have prestige and status. Business purpose The need to satisfy a significant business purpose; to be interdependent with other projects. Stability The need for stable requirements, stable and secure resources, stable process, stable team structure, and freedom from reorganizations. Resources Needs for equipment, budget, people, and time.

Reducing resources depresses performance

Resources are the lowest level need of the Project Hierarchy of Needs. If a project lacks basic resources it needs to achieve its objective, then resource issues capture the attention of the people on the project. All other concerns become secondary. Issues of safety, quality, efficiency, even requirements receive less attention than they need. People adopt strategies that are designed to resolve the resource issues, and these strategies become their primary concern.

For example, in an environment where copier paper is rationed, you'll likely find that people have small hoards of copier paper in their offices. If "bodies" are unavailable for project work, then you can expect to find an unwillingness to release people already allocated to projects, even if their work is completed. You might hear something like this: "We don't know whether we'll be able to get her back, so find something else for her to do for two weeks."

Tightening resource supplies below the level needed actually reduces efficiency, and warps behavior, resulting in increased waste, delay, and even fraud.

Organizational turmoil depresses performance

Projects need organizational stability to thrive. When resources are constantly threatened, or when the project's survival is in doubt, the team tends to focus on creating stability.

For instance, to ensure access to equipment, projects might retain items they don't actually use, because "we might need them later" or "we'll need them again soon." Meanwhile, the equipment itself is idle. If reorganizations happen too frequently, people focus on them, and might adjust the order of task execution because "you never know if we'll be able to do it later."

These and similar effects move the project away from achieving its stated objectives. In effect, the project adopts an unstated objective: to compensate for the organization's internal turmoil. This additional task was never in the project plan. The cost of executing this task was never included in budget projections. It distorts project activities and can be a significant source of schedule slip and budget overrun.

Team building efforts can help — maybe

Since team building is an activity that builds on Stability, which occurs higher in the Needs Hierarchy than Resources, team-building efforts are a waste of time when the project is resource-starved. People can't focus on each other when they lack basic equipment, space, or staff to get the job done. It might be true that morale is low when resources are short, but you can't raise morale until you raise the resources.

Sometimes we think that if we bring in a trainer to straighten things out, we can get by with less equipment or fewer people. Perhaps. But when we try this, we risk appearing irrelevant and disconnected. What's the point of trying to do team building when a third of the people in the training are working on their resumes?

Recognition and rewards drive delivery

Delivery is often a stretch. To deliver on time, under budget, and at or above expectations requires passion and drive. Since Delivery Actualization is above Esteem in the Needs Hierarchy, we have to build Esteem to achieve Delivery Actualization. So why do we hand out awards only after the project is finished? It's too late then for the recognition to do any good. If we can find a way to build Esteem before Delivery, the project is much more likely to succeed.

Create honors and recognition opportunities all through the life of the project. Don't wait for the end. If someone does a fine job facilitating the requirements process (something that should happen very early in the project) make sure everyone knows about it. And honor such people with respect and with more challenging work, not cash.

Align project and business objectives

Unless the project's objectives are in line with the business objectives, expect the project to be assaulted from many directions. One project I recall was resource-starved. For years, we missed milestones in misery while the rest of the company ignored us. One day, resources arrived. Since we already had stability, our business purpose became a hot issue. Political attacks on our project intensified, because our vision wasn't integrated with that of the company. This seems to be well explained by a Needs Hierarchy.

Sometimes we have to undertake projects that — if successful — will redirect the business. For a long time, we've known that the best way to run business redirection projects is the "skunk works" — a secure, often remote environment in which the project is protected from the rest of the organization. The Needs Hierarchy explains why this is so: the project cannot focus on Esteem or Delivery Actualization, because the Business Purpose cannot be met. When the project is housed in the organization proper, the organization works to align the project objectives with the business purpose, which subverts the objectives of business redirection projects.

The Panama Canal was a project that satisfied its need for Delivery Actualization [McCullough 1978]. In delivering a Canal, it invented or extended dozens of technologies. It determined how yellow fever spreads; it invented earth-moving technologies; it pioneered central electrical control systems; it was the largest concrete structure ever built, and would remain so for more than 20 years. Remarkable for a project of seven years duration, it opened six months ahead of schedule, and it was 3.5% under budget. Just before completion, a delegation from the U.S. Commission of Fine Arts, sent to investigate improving the Canal's appearance, recommended that nothing be changed. Not only had the project delivered a canal, it had delivered a thing of art, "impressive from its scale and simplicity and directness." If any project ever has, the Canal achieved Delivery Actualization.     Top

How does this model fit projects you've worked on? Can you remember a time when using this model might have helped the project? Hurt the project? Share your stories, and I'll publish the results of this "study" right here. rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.comContact me.

References

Maslow 1987

Maslow, Abraham, Robert Frager, James Fadiman. Motivation and Personality. 3rd edition. Boston: Addison-Wesley Publishing Co., 1987. Order from Amazon.com

McCullough 1978

McCullough, David. Path Between the Seas: The creation of the Panama Canal, 1870-1914. New York: Simon and Schuster, 1978. Order from Amazon.com

Contact me

Contact me to discuss your specific situation, by email at rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.com or by telephone at (650) 787-6475, or toll-free at (866) 378-5470 in the continental US.

Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info