Project organizations achieve their best performance when their needs are fully met. We can construct a model of the needs of the project organization by following the pattern of the hierarchy of human psychological needs developed by Abraham Maslow. This model offers insight into achieving peak performance in project teams.
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:
The Hierarchy of Needs for Project Organizations tells us what conditions must be present for these effects to work.
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.
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.
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.
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.
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?
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.
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. In
delivering a Canal, it invented or extended dozens of technologies. It deter-mined 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. rbreneTLHLhreKavZaiuOner@ChacOkSQmFGiXXdSxZBWoCanyon.comContact me.
Contact me to discuss your specific situation, by email at rbrenVTPoiCYdHDzdEuiUner@ChaccgwpchmqESjkztMAoCanyon.com or by telephone at (617) 491-6289, or toll-free at (866) 378-5470 in the continental US.