September, 2007
by Chris Greco
Chris Greco is currently an IT specialist with the Federal Government and has worked as a civilian for the Federal Government for the past 5 years. Before that, he worked for private industry as a PC Support Specialist and an Information Systems Manager, supervising a small staff of both mid-range and PC support specialists. Mr Greco is a retired Air Force Intelligence Officer that spent more than 20 years in the Air Force working in Europe and the United States on intelligence related matters. Also as an Air Force officer, he has help various academic posts at such institutions as the University of Pittsburgh, Carnegie-Mellon University and Wilkes University, all in Pennsylvania. He takes what he has learned as an IT technician and combines it with what he has learned from managing and leading to present this very unique article on applying Maslow's Hierarchy of Needs to the more technical environment. Mr Greco has presented accepted papers at both the 2005 and 2006 CMG conferences. In 2006, he presented his first approach to the Maslow concept. He lives in Baltimore with his wife Kathy and has two daughters, Kate and Sara.
About the Author
Chris Greco
This is the follow-on article from last year's submission on adapting the Maslow Hierarchy of Needs Model to computer technology. This paper addresses the need for requirements delineation without the scope creep that occurs when project managers pass the original mandate (and deadline). By adapting the Maslow Hierarchy of Needs to the requirements process, the project is divided into smaller snippets of resources, continually satisfying requirements as the project manager simultaneously keeps the original mandate on track and costs within the boundaries of that project.
There was a meeting of a weekly club whose sole purpose was to socialize and play cards. The president of the club called the meeting to order, so as to get through the formalities before socializing.
"We have any old business? No. Any new business? No. Let's play cards."
All of a sudden, there is a hand that goes up in the back of the room.
"George, what do you want?" The president says, somewhat annoyed.
"I want to contribute to new business." George says confidently.
"Fine, what do you want?" The president is losing his patience.
"I want a new chandelier in here." George says.
"Great, George. Anyone second the motion?" The president says.
"I do." Another voice in the back.
"Thanks a lot Fred." The president says in disgust as he recognizes the hand.
"The motion is passed. Let's have a vote."
The vote passes.
"Ok, let's play cards." The president says, relieved.
Next week, there is another meeting of the same social group. The president asks if there is any old or new business. A hand rises.
"George, what do you want?" The president asks.
"I want to know about my motion for a new chandelier." George asks with a shaky voice.
The president puts down his gavel and points a finger in George's direction.
"I'll tell you about your motion." The president says accusingly.
"First, no one can spell chandelier, so we can't put it in the minutes. Second, I asked everyone in the club and no one knows how to play the chandelier. Finally, we are not going to do anything until we get some new lights in this place."
The story about illustrates what happens when the requirements get lost in the translation. If the knowledge of the requirement is not clearly defined, and then acted upon, the requirements are never satisfied. In some cases, the requirements are never concretely put into a technical language and thus, stay in limbo status or, worse yet, are implemented incorrectly, costing the company money with no result. What would have been even more poignant is if the president would have stated that, along with new lights, they were getting new paneling to show off those new lights. After all, they were spending money anyway. In essence, the light never comes on.
This paper takes another look at the Maslow Hierarchy of Needs and its usefulness to the computer industry. Last year's CMG paper on this subject outlined the Maslow Hierarchy of Needs and associated each part of the concept with computers, computer technicians, and computer concepts (such as ITIL). Adapting a psychological concept to computers and computer technology was neither easy nor accepted as a viable method to reconcile requirements or solve many of the problems that we as IT specialists face daily. This paper will first take each part of the Maslow Hierarchy of Needs, relate it again to the computer field and show that it can be used to solve one of our biggest problems - the project process. To reiterate the context from the last paper, below is a recap of last year's explanation of the Hierarchy of Needs as it applies to the psychological arena.
Figure 1
Last year's submission showed that the Maslow model could be used in the technology arena focusing on computer hardware and software, and the areas of availability management and monitoring. The major tenets of Maslow's model were explained, but also adapted to the peculiarities of computers and technology in general. The Maslow model (as depicted in Figure 1) is a pyramid that describes the basic needs that humans must satisfy before being able to achieve self-actualization. These needs can be translated into needs that computers and technologists must attain before doing "what they were born to do" or self-actualization. Last year's submission raised examples of how cooling and power needs were essential in order for computers to operate properly and how those needs were comparable to the "physiological needs" that Maslow espoused. The analogy continued through the rest of the Maslow model, pointing out that "security needs" could be compared to application virus protection, or that "belonging needs" were the network parity that must exist in order to computers to communicate. The next level of needs or "self-esteem needs," which in computers meant a "grade" of computer (otherwise known as the best in class), was synonymous to esteem. Finally, the "self-actualization" would be based upon the computer doing what it was "born to do." That means that if a computer was designed to do multi-media, then it would perform that function well.
This paper adapts the Maslow model to computer projects, using it to better track requirements that either get lost in the translation or become much larger than the original project. By using the model, the requirements definition will be tracked through the needs pyramid and be kept at a manageable level. In addition, the pyramid can be used to show "scope creep" as it occurs.
Every project has a beginning where a requirement is levied to satisfy a need. These requirements then are fragmented to determine component which are then evaluated and melded into a time line for project completion. If those determinations were made in conjunction with the Maslow model, such as what power or cooling capability (physiological) to what type of network interface (sense of belonging) is needed, then the Maslow model could help the project become completed in a relatively structured fashion. After last year's presentation on the Hierarchy of Needs as it applied to computer technology and the computer technologist, one individual who attended the CMG 2006 conference said that she would attempt to apply the Maslow concept to certain projects. After several months, we conducted a feedback session on how that process was proceeding and they stated they had some immediate problems with adapting the Maslow model to their specific computer project. The primary problem that arose almost immediately was the name of the concept, which is somewhat recognizable by most people in our industry as a psychological concept. As such, the concept was not accepted as a possible alternative to technical requirements solution or to any technical application.
One problem with associating the Maslow model to the "hard facts" of computer technology was that many technologists scoffed at the inference that a psychological concept could be used as a tool for a technological project. I also found that view in my technical environment. The fact that a psychological tool would be associated with a non-psychological reality was incomprehensible to many of my colleagues. Besides the obvious jokes (such as "don't try to perform therapy on MY computer!"), the Maslow concept did not receive any credence for use with computers. In this writer's opinion, there is a reasonable (actually cultural) skepticism that goes along with the outward disdain for trying to take a non-technical concept and attempting to relate it to the real technical hardware. Technicians have to deal with real technology daily, with troubleshooting and operator error (usually from users that know little about a computer). The frequent interface with "unbelievers" in technology takes a toll on the technology specialist. It is usually the human that causes the problem with the computer. How could a human-developed concept for humans possibly be used to attempt to explain a technical concept? That is the root of this conceptual conflict. It is almost automatically assumed that the Maslow Hierarchy of Needs applies only to humans and human environment. Is not technology so much a part of the human environment that it actually intermingles with the daily human experience? Why would we NOT take Maslow into consideration?
In order to make the Maslow model more palatable to the technician and the technologist, one might simply rename the concept to fit the need. The acronym that came to mind for this renaming was Technology Requirements Interface Pyramid or TRIP. By changing it into a noun/verb, there are many ways you can use the concept in relation to the actual application. For instance, one could say that one is "taking a requirements TRIP to arrive at the destination." One could say that one does not want to be "TRIPped up while determining technology requirements." In any case, the renaming of the concept presents it in another light and eliminates the awful realization that you are using what some people might consider "psychobabble" to determine technology requirements.
Now that the naming of the model is completed, there needs to be an adaptation of the model to more fully comply with technology requirements. Specifically, we want to use the TRIP to determine how to satisfy user and customer requirements.. In order to do that, the original model must be "adjusted" or manipulated to fit the overall look of the requirements satisfaction model. The current look of the Maslow model will not do that, since the self-actualization of the human is placed at the top of the pyramid. This is a non-starter, since the requirement is really the first item to be considered (although in some cases it may actually be the last item, which makes it that much more imperative to establish a model to channel these requirements through a process). So, how do you incorporate a requirements section on a pyramid that already begins with the physiological needs as the lowest portion of that pyramid? The solution is to use the 3-D effect of the pyramid to constantly feedback each step to the requirement (see Figure 2). Otherwise, you experience "scope creep," that incipient and pervasive concept where new requirements are added, necessitating larger programmatic efforts. If scope creep is too pervasive, your project can in fact fail without realizing the benefit of satisfying the requirement (GURL2003).
Figure 2
At this point, after the model is named with a more "technology friendly" handle, and the requirements generation process is provided, then we apply the model (or process) to actual or impending projects. To see an example of this in use, one only has to describe a process as it pertains to a project of interest in probably most of our areas - dashboard development.
Dashboard creation, although probably not as pervasive as several years ago, is still a project to be reckoned with in all its complexities. When an executive says that they need a dashboard, the technicians put their heads in their hands and wonder how they will ever provide the information that their boss wants to his or her satisfaction. This is where TRIP can be of assistance in determining requirements, keeping the project on track, and preventing scope creep.
The first step is determining what information should be in the dashboard - the underlying requirement. Getting this information may be the hardest step in the whole process, but the main reason for gathering it now is to prevent it from changing during the project process. In essence, the requirement is the architectural drawing for the house, the outline of the book, the skeleton behind the body. Once the underlying requirement is uncovered, the rest of the TRIP can be implemented, using the concepts presented in the Maslow model, and properly adapted to technology. As an example, the executive states that he wants to keep track of servers in several states to ensure that they are operational during any part of the day. He wants a report on his PC every morning by 0800 showing that these servers are up and operational. He also want reports at different times throughout the day on the servers' status and different reporting levels (red, yellow, and green) to denote at a glance how those servers are working.
Applying the TRIP model to the above example, you would first use the general requirements as a background for the different "levels" of more specific requirements. The underlying requirements can be separated into different categories explained in the TRIP model starting with the physiological needs (the computer systems).
In this case, the first area of concern is the servers. One can split this into the hardware component or the actual server types, the location of the servers and the power and cooling needed for these servers. However, along with those very clear needs, the other category that must be addressed is the data component. Some of those questions might be "what type of data would be needed to feed the dashboard system that the requirement calls for and what type of dashboard system will be needed?" This is the "food" of the requirement, the subsistence to keep it alive, to maintain the requirement through its life. If one was to take the requirement above, the data that would be needed would be that information that would gauge the "life" of the server, including if it was powered, connected, and "alive" through pings or other source information. In addition, once the physical life was ascertained, the "service" life of the operating system would need to be addressed. Are all the services up and running for the application(s)? Do any of these services need restarted?
Once the "physiological needs" are assured, then come the "security needs." These requirements would include server security (under lock and key, BIOS password, or other external and internal security measures). In addition to the server security, data security must be addressed to properly assure that the data will be seen only by those that need and use it. The part of the security requirement should be automatically included in the database application, but it should also be a part of the "checklist" of items that are stated as part of this requirement. So, the security will mean external physical security, internal software security and data security. If all these are considered, the user security element should fall into place. After all, you do not want the executive to receive any additional information that might make it hard to see the macro level view that they desire.
The next requirement is network planning.. Although this would include the physical network connection and the subsequent inclusion of the database servers to the executive dashboard, it may not be obvious that it also includes the connections between the monitoring server and the monitored servers. All these connections must be considered when trying to satisfy the general requirements. Once the monitored machines are connected, the questions then would be more esoteric such as: What time zone are the monitored servers in currently? Are they compatible with the monitoring database? Can the monitored servers connect and send data to that database or monitor application? Without this sense of belonging, the monitoring process breaks down and the information will not get to the user.
This part of the model has always been extremely hard to translate from the psychological to technological. Self-Esteem is a very human concept because it incorporates "feeling" which is hard to adapt to a piece of technology. In this case, the adaptation might be more straightforward if we relate the self-esteem to the alienation of a computer should it not meet the various requirements for the monitoring process. In other words, if the baseline is violated, then the self-esteem would falter. Service Level Agreements (SLAs) might be a translation for this part of the requirements process. If the SLA is the overall baseline for a successful server operation and the server does not meet that operation through outages and capacity problems, then the SLA is not met and the server must be evaluated. If a server does not meet the requirements of the belonging above, then it is isolated as part of the monitoring. This can lead to either isolating the server for more specific troubleshooting, in other words detection by its absence. This is similar to the psychological sense of self-esteem where one source stated that a lack of self-esteem can lead to isolation and depression or a lack of motivation or progress. In psychological terms it can lead to a regressive personality and negative feelings [ORCH2007]. In the same way, by not correcting the problems with a server, it can deteriorate to the point of being removed and replaced, or the hard drive being reformatted, possibly losing data or corrupting the entire network of servers. In this way, the monitoring process can prevent this deterioration or "alienation" of the server and the requirements can be fulfilled for the project, as well as meet or exceed the SLA.
Now is the moment of truth in the TRIP process. If the specific requirements are satisfied throughout the project process (in this case monitoring to provide data for the dashboard), then the data can be transmitted to a dashboard application and finally be accessed by the user (in this case, the executive). This is the point when the original requirement will be satisfied, or possibly not. It is at this point that the self-actualization of the project is accomplished. In other words, the self-actualization stage is the confirmation of the original requirements, the same requirements that form an interface between all the other stages in the TRIP model.
The inimitable checklist is probably the final way to translate this concept into something that will be placed on the desk of the technician. The checklist would look something like Figure 3, with all the trappings of the technical form, including radio buttons or check boxes if one wants to make it web-based. In essence, it is imperative that the checklist match the TRIP model, but not become too obtuse, otherwise, in my opinion, the technician will not use it. Another mandate is that the senior executives require technicians to use the checklist for each project; otherwise the usefulness will fall by the wayside. The distinct advantage to this checklist is that the project can be $100 or $100,000. The size of the project will not matter, since every requirement will be addressed and, as such, the project will have the correct tracking to make it a success.
If you have a user who wants to know if servers are operational or not, the fact that you can do that with an e-mail from monitoring software to the user's desktop may not be enough for you as a project manager, but it may more than suffice for that user. In one case, there was a user that wanted just that and it looks as if the TRIP process could have been used to satisfy this requirement. The solution consisted of the monitoring application and then sending an e-mail to the user's desktop with the words "Site X is Up and Operational" if all components (hardware and software) in that server were operational. The user knew that there were 8 sites and where they were, so he came in and checked the e-mails. If all sites were up, then he could report that at his morning meeting. It was only later that there were dashboards with maps and green lights and the whole eye candy that goes along with letting this user know that the site was operational. The "Site X is Up and Operational" was used for several years with no problems and no complaints from that user. The project took no time at all to complete and satisfied the requirement of that user, without an excessive amount of programming or testing required. The TRIP process would help to eliminate excessive planning for such a small endeavor. It would also allow the planner to act in accordance with all the requisite planning skills, but not the time intensive planning that needs to go into something that may be relatively simple.
How can this possibly help managing a project? Other than the obvious advantage of keeping the project on track and on target, the management advantage is being able to keep personnel focused. No one likes to be told about an ad hoc requirement while trying to already satisfy the one that was originally levied. If the TRIP model is somehow helpful in establishing a process to make the project more palatable, then the dashboard will be more useful to the executive, and the overall project should be more sanely developed and implemented.
How do you keep the requirement on track? Feedback is the constant comparison of the generic requirement to the specific TRIP process. In other words, the project manager would be constantly comparing the user requirement to the hardware requirement or network requirement to ensure that the requirement flow is constant. Without that feedback feature, the project could still result in scope creep and cost much more than actually warranted. Keeping it about reality is what the TRIP process is based upon. Without that, this is just another "throw away" model.
Many times in the evolution of a project, the ideas and innovation that accompany the project process are put to the side, with the main focus on just completing the project and going on to the next project. It is vital that the creativity and innovation that resides in all individuals also is in focus, otherwise the project gets completed in a mechanical fashion with no reasonable look at the possibilities within that project. The TRIP process allows this creativity to shine through. By looking at the sample checklist (Figure 3), one can see that there is a lot of flexibility in the completion of this project. The type of hardware is not specified, this will be dependent on the project needs or requirements. The database may or may not exist at all, although with monitoring and capacity planning, the database would be the key to the dashboard development and thereby be a key ingredient in the completion of the project. But even the database is not specified, again increasing the flexibility that exists within this concept. If there is one thing that is evident within the technology community it is a freedom of expression, the ability of technicians to ponder, think, and then act on a specific problem. The fact that there is a generic requirement, and then a checklist that is "technician-centric" helps this free thinking to satisfy that requirement, and establishes the TRIP (Maslow model) as a concept that is both available and adaptable to the technical world.
Probably an area that was glossed over in this paper was the "pile on" effect. In essence, if managers see that something is working they will pile on their requirements, hoping that the application will also satisfy their needs. This pile on effect can be reduced with the use of TRIP since the requirements for satisfaction are what the sub-requirements are based upon. It is this idea of focused requirements that will prevent others from piling on their requirements. By using the TRIP process, there is a constant reference to the requirement, which will keep the original need in place and visible for all concerned. It is this constant requirement "reminder" that will keep the project on track.
The use of the TRIP process in determining requirements satisfaction is not a new concept. The project managers have at their disposal many tools and applications for making their project run on time and on budget. The TRIP process provides another tool for this requirement satisfaction. It does not need expensive applications surrounding it, nor does it need an extensive learning curve to use it. It is a sequential, straightforward tool that can be applied to projects with no regard to the type of project it entails. The tool has been used in projects without really knowing we were using it. The fact that projects are segmented into different components and those components are evaluated as to suitability for satisfying requirements shows that the TRIP process is something that can take that segmentation and organize it without complex project management process. The use of this process in determining dashboard development is something that this writer did without really knowing the TRIP model. By actually having a process to determine "sub-requirements," the prospect of completing a dashboard that will in fact be what the boss wants is something that must be considered. Otherwise, the project will get out of hand, scope creep will occur and costs will start to exceed expected amounts. .
Figure 3
[BREN2007] Brenner, Rick, "The Hierarchy of Needs for Project Organizations," Chaco Canyon Consulting, 2007.
http://www.chacocanyon.com/essays/hierarchyofneeds.shtml
[GREC2006] Greco, Christopher F., "Monitoring, Availability and ... Maslow?!!," CMG Proceedings, 2006.
http://www.cmg.org/conference/cmg2006/published.html
[GROV2007] Grover, Neha, "Requirement Traceability - A Tester's Approach," Technology Evaluation Centers, April 30, 2007.
http://www.technologyevaluation.com/Research/ResearchHighlights/PLM/2007/04/research_notes/TU_PL_XNG_04_30_07_1.asp?
[GURL2003] Gurlen, Stephanie, "Scope Creep," University of Missouri/St Louis, December 2, 2003.
http://www.umsl.edu/~sauter/analysis/6840_f03_papers/gurlen/
[ORCH2007] Orchard, Brian, "Low Self Esteem," Vision: Insights and New Horizons, 2007.
http://vision.org/visionmedia/article.aspx?id=1146