Management activities and cultural elements that reduce the effectiveness of teams
Introduction
Motivators in business have long been a topic of conversation at conferences and in the halls of management consulting practices. Lately these management motivation methods have been called into question for the unseen impacts they have on business (Blanchard, 1994). This concern not only focuses on the formal motivators like salary, pay-for-performance bonuses and public recognition, but it also includes the quieter and more subtle incentives. One common act is rewarding individuals for heroically going “beyond the call-of-duty” to rescue a project or solve a problem. What does this special treatment encourage and what does silence show?
There have been multitudes of books written on the psychology of motivation. This work will concentrate specifically on how flawed motivators work to reduce the effectiveness of teams. Effectively building teams in an organization requires more that just one person. It requires the entire organization. The right culture in an organization builds effective teams (Jackson). It is the premise of this work that “team friendly” cultures start with “team friendly” motivators. Too often in business we demand team work but encourage individualism. Our incentives are to the individual but deep down we understand that we can accomplish more through teamwork.
In many cases managers that reward non-“team friendly” behavior and encourage individualism over teamwork are unaware of their follies. They use management practices common to a past era, which focused on controlling behavior not empowering teams. For teamwork to flourish these flawed motivators must be dismissed and new ones learned.
10 Flawed motivators
Over the course of many years in industry and consulting, the author has encountered several frequently occurring flawed motivators. Each of these focuses on the individual or the department instead of the organization and the team. To follow is a list of the top 10 flawed motivators. It includes a description of each motivator and the common consequences that result from its use in the workplace. The list is ordered according to the frequency with which these motivators are found in the workplace. Obviously organizational culture and other factors can influence the extent to which these consequences affect teamwork. In some cases very little consequence to teamwork is seen because the greater organizational culture is “team friendly”. Conversely, organizations with poor team cultures will see much more extensive consequences.
Flawed Motivator #1 -- Focus on individual tasks
Description: The workplace has seen dramatic increases in competitive pressures and stress levels over the past decade. Employees are pushed harder than ever before to deliver quality results in shorter timeframes. To achieve these results many project and functional managers have seen success driving team members to deliver on individual tasks.
Common Consequences: In some circles this motivator is seen as necessary and encouraged as good management practice. Nevertheless, driving to individual tasks can have dire consequences for teams (Kendall & Rollins, 2003). A project is made up of a chain of tasks that together allow a team to finish a project at a specified date for a specified cost. Each task in that chain has a certain probability of finishing on time. Many tasks will finish late and, statistically speaking, about the same number of tasks should finish early. Driving individuals to complete individual tasks on time causes them to lose site of the team goals and teamwork necessary for project success. Team members must work closely together as they traverse this project chain, but instead they are motivated to look out for themselves first. Such individualism thwarts the effectiveness of teams.
Flawed Motivator #2 -- Reward individual heroic efforts
Description: As the pace of business increases, managers seek better methods to increase the velocity of work. One trap that managers often fall into with this goal in mind is to reward individual heroes for individual effort.
Common Consequences: Certainly there are times when rewarding individuals is appropriate, but in many cases such rewards circumvent larger team and organizational goals (Blann, 1999), (Reich, 1987). Individual heroism often exists in situations where planning or process has been poorly executed or dismissed altogether and individuals must step up and bailout the organization. Openly rewarding bailout efforts tends to legitimize the lack of planning or process and encourage individual effort. The importance of repeatable process is lessened within the organization and teamwork is diminished.
Flawed Motivator #3 -- Reward individual knowledge
Description: Similar to rewarding the heroism of individuals, managers often reward individual knowledge. This is not to say that having intelligent, knowledgeable individuals is not important, but these rewards should happen within a team environment.
Common Consequences: While this motivator is similar to the previous one, the consequences are quite different. Rewarding the knowledge of individuals for knowledge sake occurs at a terrible cost (KCS). Employees who are knowledgeable and frequently rewarded for their knowledge tend to be very hard to work with in a team environment because they see themselves as being above the intelligence of the rest of the team. Additionally, such employees have a tendency to become “knowledge empire builders”, hording information to improve their standing with management and to promote their own job security. All of these actions undermine teamwork and longer-term organizational goals.
Flawed Motivators #4 – Setting arbitrary due dates on projects
Description: A common practice in organizations, especially those with controlling cultures, is for project sponsors or other high-ranking stakeholders to set arbitrary project completion dates without feedback from the team in determining what it would take to complete the effort.
Common Consequences: Underlying any action of this nature that circumvents the knowledge and experience of the team is a subtle, often hidden premise that the team is not capable of making important decisions on its own. In the case of this particular motivator, the manager setting the date is in essence telling the team that they are not competent to establish the necessary checks and balances and velocity required for the project to succeed. It suggests that those closest to the effort, chosen for their expertise in completing similar work, are unqualified to make such decisions on their own. A lack of trust in the team from organizational management does nothing but stifle the effectiveness of teams.
Flawed Motivator #5 -- Functional managers stepping in to “rescue” projects
Description: When troubles arise within a team, a functional manager, usually a sponsor or related manager, engages the team with the purpose of rescuing them and leading the team back on track.
Common Consequences: Similar to the previous motivator, this one calls into question the abilities of the team. The functional manager is telling the team, usually in not so many words, that the team does not have the skills and ability to solve their own problems and to be successful. This motivator often exists in organizations with strong departmental silos. Because of the culture such organizations promote, the functional manager sees his or her department as a failure when there is a team setback. Regardless of the reasons, such actions can have dire effects on teams, especially cross-functional ones.
Flawed Motivator #6 – Organizations and cultures with strong and competing silos
Description: Many organizations are set up, whether by design or as a by-product of other cultural elements, with strong department silos. In these organizations departments are pitted against each other to compete for monies, people, and the ear of higher management.
Common Consequences: Organizations structured in this manner tend to create cultures that minimize the value of teamwork (Albreicht, 2002). When cross-functional teams exist in this environment, different and often competing goals and objectives can pit team members against each other to meet their own needs. The idea of a “team” becomes a delusion. These contentious teams are saying, in essence, that individual department’s goals are more important than the team and organizational ones. Organizations of this nature usually exhibit many of the other flawed motivators because functional managers attempt to minimize the accountability of the team members from their department and shift blame, when problems arise, to team members from other departments.
Flawed Motivator #7 -- Constantly changing teams
Description: Changing priorities and resourcing needs often results in teams with constantly changing memberships.
Common Consequences: When team members are dropped into a team without an understanding of the team’s goals and objectives, they struggle to see its value and understand their part. They become an individual working with a team, not a member of the team. When a new team member enters a team in mid-stream, time must be taken to educate the member regarding the history of the team and the decisions that have been made. The new team member must understand that the team is moving forward and is not required to review and rehash prior decisions.
Each time the members of a team change, the team dynamics change. The team must reestablish itself and move on. Teams go through 5 main stages of development: forming, storming, norming, performing, and adjourning. When the team changes it must begin these stages anew (DeJanasz, 2002). Constantly changing teams mean that the group will never reach the performing stage of development and its greatest effectiveness.
Flawed Motivator #8 -- Viewing teams as group of interchangeable parts
Description: Since early in the industrial revolution, some managers have viewed employees as interchangeable resources used to complete a task.
Common Consequences: While it is not advised to reward individual effort for individual actions, it is vital to the success of teams that managers do not fall into the trap of viewing a team as pieces that can be removed and replaced at will. Tom Peters made this point when he said that the “real trick in building a team is to have 25 individual stars on it” (Peters, 1994). Tom was not suggesting that the “individual stars” should work independently, but that teams should be built based on skills and expertise as well as their ability to work as a cohesive group. Each member of the team is critical to its success. Any view or action that undermines this will undermine the effectiveness of the team.
Flawed Motivator #9 -- Holding individuals accountable to managers rather than team
Description: A common practice in strongly siloed organizations is functional managers that view team failure or setbacks as a failure within their own department. A result of this view is managers that think they must hold their own people, working on teams, individually accountable.
Common Consequences: While on the surface this motivator doesn’t seem to have negative consequences, in reality it reduces the effectiveness of teams. Like focusing on individual tasks, this motivator causes individuals to consider themselves before their team. The result is a cat-and-mouse game where individuals try to keep both the functional and team manager’s happy, even when there are competing goals in the mix. Such actions circumvent the duties of team management and ultimately the ability of the team to govern itself effectively.
Flawed Motivator #10 -- Teams without ownership of problem being solved
Description: Because of the velocity of business coupled with a lack of required resources, whole teams or members of teams are added after the research and planning of an effort have been completed.
Common Consequences: To be effective, team members must own the problem the team is solving. For teams to have ownership they must have members that feel real pain from the problems being solved and a stake in the solution (Javitch, 2003). Additionally, each team member must understand and value the goals and objectives of the team. Without ownership of the problem, individual team members or the entire team will struggle to appreciate the work being done and may become cynical of its purposes. These consequences demoralize the team and reduce its effectiveness.
Making the change
These 10 flawed motivators will consistently undermine the work of teams and the goals of organizations to build and nurture teamwork. Culture and management style are a common thread in organizations that encounter these motivators (Heathfield). Because of this, change will take time. Cultural change and management training must commence and teams must learn how to be effective. In many organizations trust has been lost and political barriers have been established. Removing the barriers and reestablishing trust will not happen overnight.
In any event, managers must begin to view teams as a mechanism to meet department and organizational goals and take steps to encourage their effectiveness. Cultures that empower teams to take initiative and use their skills and expertise to execute and make critical decisions will reap the rewards of improved efficiency and better quality products and services.
References
Albreicht, K. (2002). The Power of Minds at Work: Organizational Intelligence in Action, AMA
Blanchard, K. (1994, January 1994). Punished by poor management. Incentive
Blann, D.R. The Manufacturing Gale, Marshall Institute, Inc.
DeJanasz, S.C. Dowd, K.O., & Schneider, B.Z. (2001). Interpersonal Skills in Organizations. New York: McGraw-Hill. Pg. 315
Heathfield, S. How to Build a Teamwork Culture: Do the Hard Stuff. About.com
Jackson, I. The Communicating Executive. Executive Management Solutions. Pg. 2
Javitch, D.G. (2003, May 2003). How to Foster Effective Teamwork. Entrepreneur.com
Kendall, G. L., Rollins, S. C. (2003). Advanced Project Portfolio Management and the PMO. J. Ross Publishing. Pg. 274
Knowledge Centered Support, Version 3 (KCS). Consortium For Service Innovation. Pg. 8
Peters, Tom. (1994). The Pursuit of WOW. Vintage Books, USA
Reich, R. (1987, May-June 1987). Entrepreneurship Reconsidered, The Team as Hero. The Harvard Business Review
Thursday, September 30, 2004
Tuesday, April 13, 2004
The Problem With Requirements
Introduction
According to the Standish Group’s Chaos Report (2001) more than 70% of software projects fail. In addition to this overall statistic, the report lists the most frequent reasons projects fail. Similar studies were conducted by the International Council of Systems Engineers (2000) and the IT consulting firm Keane (Munson, 2002) with startlingly similar results. All three studies focus project failure on requirements. The top three reasons for project failure follow.
The Problem with Requirements
While there are several reasons these studies point the finger at requirements, the problem may actually stem from the way humans learn and think. To explain my point, imagine you have never been to nor seen any pictures of China, and are asked to provide a description of the place to an artist who wishes to draw a picture of the Chinese people and their country. Would you be capable of describing China? Perhaps you could discuss China at a high level, based on information you had read or heard, but you would find it impossible to accurately provide the details the artist needs.
Requirements are quite similar. We ask people all the time to define requirements for software that they have never seen, touched, or experienced before. To develop software, requirements must have a level of detail similar to what an artist needs to draw.
This leads us to Requirements Myth #1:
A customer doesn’t know what he wants until he has experience with the software. He may be able to provide some high-level requirements, but will surely fall short when asked for the details. Its no wonder so many projects fall short on requirements. Steve McConnell wrestled with this issue in his work Software Project Survival Guide, when he wrote, “The most difficult part of requirements gathering is . . . the exploratory, developmental activity of helping users figure out what they want.” (1998) In addition to not knowing the specifics, there are other problems with requirements. Going back to the China example, even if you had seen pictures of China, you still would struggle with providing the details on paper. Translating something abstract like the abundant colors and fast-pace of an urban Chinese market is difficult even for the most experienced writer. So, Requirements Myth #2 is:
Requirements are often very abstract. If you attempted to describe the look and feel of a new piece of software, having never before seen it, you would find it frustrating describing the requirements in the necessary detail.
We as humans struggle with details. One example of this struggle is a fact stated repeatedly by police detectives investigating crime. Investigators say that one of the biggest problems eyewitnesses to a crime have is recalling specific details. We aren’t programmed to recall the specifics. Gathering the specific details for requirements is no different.
Types of Requirements
The degree of difficulty customers have in identifying and capturing requirements is dependent on the type of requirements they are working with.
There are three basic types of requirements that the customer is asked to specify: business requirements, user requirements, and functional requirements (Wiegers, 1999). Business requirements describe the underlying business problem in need of software. This type of requirement poses little problem for the average customer. They understand the problem because they are experiencing it themselves. Business requirements are usually captured at a high level, thus they don’t have the details customers consistently struggle with.
User requirements are more detailed and abstract than business requirements, but usually can be captured by the customer. User requirements focus on the tasks the customer would like to perform with software. With some thought and a lot of patience, these requirements can be documented to the required detail. This isn’t to suggest that user requirements are easy to gather, but the tasks and processes defined in the user requirements are available if the customer is willing to spend the time identifying and collecting them.
It is really the functional requirements that cause the most problems for customers. Functional requirements are the solution to the business problem from a customer perspective. They define the software that will be created to meet the customer’s needs. Unlike the user requirements, the functional requirements are very often new. That is, they aren’t available for the simple gathering because the solution is a new one even if the problem is the same. Functional requirements must be defined in excruciating detail so that they can be passed on to the development staff for designed. Holes in the functional requirements will be filled by the creative minds of the developers. It is these holes or more often than not, these craters in the functional requirements that create the disconnection between the needs of the customer and the good-intentioned ideas of the development staff.
Our discussion to this point doesn’t suggest that functional requirements are impossible to obtain, and certainly doesn’t infer that they should be avoided. Functional requirements must be gathered, and they must be gathered in great detail. A little change in thinking is what is needed to mitigate the requirements problem.
Looking Back
To change our thinking we must look back at the way software projects have been managed for the last 40 years. More than 80% of software projects use some form of the Waterfall Methodology. The Waterfall Method is a sequential process that a project team goes through to develop a software product. The process begins with defining requirements and proceeds through design, development, and ultimately to delivery of the software. While this approach is very methodical and easy to manage, it magnifies the inherent problems with requirements and disregards the way that we learn.
A New Method
New methods of managing projects have been developed to counteract the inherent requirements weaknesses of the Waterfall Method. These methods are grouped under the heading Agile Methodologies. Agile Methods operate under a very different set of principles than the Waterfall Method. With the Agile Method, a project begins the effort with a set of requirements that encompass “What we know today.” The software continues through the standard stages of design, development, and delivery, but when the software is delivered, it becomes the input to a whole new iteration of the same process. This circular process continues until the software meets the customer’s needs.
While on the surface, such an approach seems redundant and even lengthier than the Waterfall Method, in reality it is faster. Many of the advantages of this approach are directly related to the way it manages requirements.
The Agile Method is not perfect. Many find it harder to manage and more chaotic than the Waterfall Method. In an environment where structure and discipline are lacking, the Agile Method requires meticulous management of iterations and changing requirements. This detailed managed is required because of the second natural law.
Experienced software managers must know where to cut off the current release or phase and begin the planning of future efforts. While the Agile Method has its shortcomings, the advantages largely outweigh the problems.
Conclusion
While software failure is a consistent problem today, solutions like the Agile Method exist to turn the tide. To make this substantial change we must recognize our misconceptions about how requirements are identified and captured as exposed in the discussed myths and natural laws of software. As we take what is known about human nature and learning and apply it to better methods and approaches to gathering and managing requirements, we are sure to see the trend turn to more software project success in the future.
References
International Council of Systems Engineers. 2000 Report
McConnell, Steve (1996). Rapid Development (pp. 137 - 138). Microsoft Press
McConnell, Steve (1998). Software Project Survival Guide (pp. 117). Microsoft Press
Munson, Bill (2002). Keane, LTD, UK
The Standish Group International, Inc. CHAOS Research. 2001
Wiegers, Karl E. (1999). Software Requirements (pp. 7 – 8). Microsoft Press
According to the Standish Group’s Chaos Report (2001) more than 70% of software projects fail. In addition to this overall statistic, the report lists the most frequent reasons projects fail. Similar studies were conducted by the International Council of Systems Engineers (2000) and the IT consulting firm Keane (Munson, 2002) with startlingly similar results. All three studies focus project failure on requirements. The top three reasons for project failure follow.
- incomplete requirements
- lack of customer involvement in defining requirements
- poor management of changing requirements
The Problem with Requirements
While there are several reasons these studies point the finger at requirements, the problem may actually stem from the way humans learn and think. To explain my point, imagine you have never been to nor seen any pictures of China, and are asked to provide a description of the place to an artist who wishes to draw a picture of the Chinese people and their country. Would you be capable of describing China? Perhaps you could discuss China at a high level, based on information you had read or heard, but you would find it impossible to accurately provide the details the artist needs.
Requirements are quite similar. We ask people all the time to define requirements for software that they have never seen, touched, or experienced before. To develop software, requirements must have a level of detail similar to what an artist needs to draw.
This leads us to Requirements Myth #1:
Requirements Myth #1 – “The customer knows the requirements.”
A customer doesn’t know what he wants until he has experience with the software. He may be able to provide some high-level requirements, but will surely fall short when asked for the details. Its no wonder so many projects fall short on requirements. Steve McConnell wrestled with this issue in his work Software Project Survival Guide, when he wrote, “The most difficult part of requirements gathering is . . . the exploratory, developmental activity of helping users figure out what they want.” (1998) In addition to not knowing the specifics, there are other problems with requirements. Going back to the China example, even if you had seen pictures of China, you still would struggle with providing the details on paper. Translating something abstract like the abundant colors and fast-pace of an urban Chinese market is difficult even for the most experienced writer. So, Requirements Myth #2 is:
Requirements Myth #2 – “The customer can easily capture the requirements.”
Requirements are often very abstract. If you attempted to describe the look and feel of a new piece of software, having never before seen it, you would find it frustrating describing the requirements in the necessary detail.
We as humans struggle with details. One example of this struggle is a fact stated repeatedly by police detectives investigating crime. Investigators say that one of the biggest problems eyewitnesses to a crime have is recalling specific details. We aren’t programmed to recall the specifics. Gathering the specific details for requirements is no different.
Types of Requirements
The degree of difficulty customers have in identifying and capturing requirements is dependent on the type of requirements they are working with.
There are three basic types of requirements that the customer is asked to specify: business requirements, user requirements, and functional requirements (Wiegers, 1999). Business requirements describe the underlying business problem in need of software. This type of requirement poses little problem for the average customer. They understand the problem because they are experiencing it themselves. Business requirements are usually captured at a high level, thus they don’t have the details customers consistently struggle with.
User requirements are more detailed and abstract than business requirements, but usually can be captured by the customer. User requirements focus on the tasks the customer would like to perform with software. With some thought and a lot of patience, these requirements can be documented to the required detail. This isn’t to suggest that user requirements are easy to gather, but the tasks and processes defined in the user requirements are available if the customer is willing to spend the time identifying and collecting them.
It is really the functional requirements that cause the most problems for customers. Functional requirements are the solution to the business problem from a customer perspective. They define the software that will be created to meet the customer’s needs. Unlike the user requirements, the functional requirements are very often new. That is, they aren’t available for the simple gathering because the solution is a new one even if the problem is the same. Functional requirements must be defined in excruciating detail so that they can be passed on to the development staff for designed. Holes in the functional requirements will be filled by the creative minds of the developers. It is these holes or more often than not, these craters in the functional requirements that create the disconnection between the needs of the customer and the good-intentioned ideas of the development staff.
Our discussion to this point doesn’t suggest that functional requirements are impossible to obtain, and certainly doesn’t infer that they should be avoided. Functional requirements must be gathered, and they must be gathered in great detail. A little change in thinking is what is needed to mitigate the requirements problem.
Looking Back
To change our thinking we must look back at the way software projects have been managed for the last 40 years. More than 80% of software projects use some form of the Waterfall Methodology. The Waterfall Method is a sequential process that a project team goes through to develop a software product. The process begins with defining requirements and proceeds through design, development, and ultimately to delivery of the software. While this approach is very methodical and easy to manage, it magnifies the inherent problems with requirements and disregards the way that we learn.
- The first problem with the Waterfall Method is that it mandates all requirements be defined at the beginning of the effort. While this may seem like a sensible request, we often find ourselves describing China without any experience, pictures, or words. This is, in essence, a form of the chicken and the egg mantra—how can you describe something that’s never been built, and how can you build something you can’t describe (McConnell, 1996, pp. 137)?
- Another important drawback of the Waterfall Method is its inability to adapt to change. This problem provides the chance to introduce you to Natural Law of Software # 1.
Natural Law of Software # 1– “In successful software, the requirements are constantly changing.”
If during development, a new feature is identified, the team has only two choices with the Waterfall Method—start the process over or push the feature to the next release. While this may be a good idea in some settings, building innovative products requires more room for change (McConnell, 1996, pp. 138).
- The third problem with the Waterfall Method is that the product is delivered at the end of the project. As explained earlier, customers learn requirements through experience. With the Waterfall Method customers don’t see and use the software until it’s too late.
A New Method
New methods of managing projects have been developed to counteract the inherent requirements weaknesses of the Waterfall Method. These methods are grouped under the heading Agile Methodologies. Agile Methods operate under a very different set of principles than the Waterfall Method. With the Agile Method, a project begins the effort with a set of requirements that encompass “What we know today.” The software continues through the standard stages of design, development, and delivery, but when the software is delivered, it becomes the input to a whole new iteration of the same process. This circular process continues until the software meets the customer’s needs.
While on the surface, such an approach seems redundant and even lengthier than the Waterfall Method, in reality it is faster. Many of the advantages of this approach are directly related to the way it manages requirements.
- The first advantage of the Agile Method is that it doesn’t mandate we know all the requirements at the start. We aren’t being asked to describe China without the necessary experience. Instead, we begin a journey to that end. Because of the quickness of the iterations, we rapidly gain the necessary experience to determine all the requirements.
- The second important benefit is how the Agile Method adapts to change. Because the stage for defining requirements (Define) occurs with every iteration, new requirements can be quickly gathered and applied. The faster the iterations, the better the project’s ability to adapt to a changing landscape.
- The third improvement over the Waterfall Method is how quickly the team sees results. It typically only takes a few iterations and the team and customer begin to catch a glimpse at what the software will look like, how it will interact with the customer, and how it will perform. This knowledge provides the customer the experience to identify course corrections and additional features and functions that will make the software useful and effective. Over time, the requirements and the software evolve as experience is accrued, and the software is developed. The picture of China will gain the necessary details the artist requires.
The Agile Method is not perfect. Many find it harder to manage and more chaotic than the Waterfall Method. In an environment where structure and discipline are lacking, the Agile Method requires meticulous management of iterations and changing requirements. This detailed managed is required because of the second natural law.
Natural Law of Software # 2 – “Successful software is never complete.”
Conclusion
While software failure is a consistent problem today, solutions like the Agile Method exist to turn the tide. To make this substantial change we must recognize our misconceptions about how requirements are identified and captured as exposed in the discussed myths and natural laws of software. As we take what is known about human nature and learning and apply it to better methods and approaches to gathering and managing requirements, we are sure to see the trend turn to more software project success in the future.
References
International Council of Systems Engineers. 2000 Report
McConnell, Steve (1996). Rapid Development (pp. 137 - 138). Microsoft Press
McConnell, Steve (1998). Software Project Survival Guide (pp. 117). Microsoft Press
Munson, Bill (2002). Keane, LTD, UK
The Standish Group International, Inc. CHAOS Research. 2001
Wiegers, Karl E. (1999). Software Requirements (pp. 7 – 8). Microsoft Press
Subscribe to:
Posts (Atom)
