Along with managing time and resources, systems analysts must also manage people. Management is accomplished primarily by communicating accurately to team members who have been selected for their competency and compatibility. Goals for project productivity must be set, and members of systems analysis teams must be motivated to achieve them.
Assembling a Team
Assembling a team is desirable. If a project manager has the opportunity to create a dream team of skilled people to develop a system, whom should he or she choose? In general, project managers need to look for others who share their values of teamwork guided by the desire to deliver a high-quality system on time and on budget. Other desirable team member characteristics include a good work ethic, honesty, competency; a readiness to take on leadership based on expertise; motivation, enthusiasm for the project, and trust of teammates. The project manager needs to know about business principles, but it doesn’t hurt to have at least one other person on the team who understands how a business operates. Perhaps this person should be a specialist in the same area as the system being developed. When developing an ecommerce site, teams can enlist the help of someone in marketing; those developing an inventory system can ask aperson versed in production and operations to provide expertise.
Assembling a Team
Assembling a team is desirable. If a project manager has the opportunity to create a dream team of skilled people to develop a system, whom should he or she choose? In general, project managers need to look for others who share their values of teamwork guided by the desire to deliver a high-quality system on time and on budget. Other desirable team member characteristics include a good work ethic, honesty, competency; a readiness to take on leadership based on expertise; motivation, enthusiasm for the project, and trust of teammates. The project manager needs to know about business principles, but it doesn’t hurt to have at least one other person on the team who understands how a business operates. Perhaps this person should be a specialist in the same area as the system being developed. When developing an ecommerce site, teams can enlist the help of someone in marketing; those developing an inventory system can ask aperson versed in production and operations to provide expertise.
A team ideally should have two systems analysts on it. They can help each other, check each other’s work, and shift their workloads accordingly. There is certainly a need to have people with programming skills on board. Coding is important, but people who know how to conduct walkthroughs, reviews, testing, and documenting systems are important as well. Some people are good at seeing the big picture, while others perform well when tasks are broken down into smaller ones for them. Every team should have both types of individuals.
Beyond the basics, a project manager should look for people with both experience and enthusiasm. Experience is especially important when trying to estimate the time required tocomplete a project. Experience in programming can mean code is developed five times faster than if it is developed by an inexperienced team. A usability expert is also a useful addition to the team.
The team must be motivated. One way to keep the team positively oriented throughout the entire process is to select good people at the outset. Look for enthusiasm, imagination, and an ability to communicate with different kinds of people. These basic attributes hold the potential for success. It also helps to hire superior writers and articulate speakers who can present proposals and work directly with customers. Trust is an important part of a team. All members of the project need to act responsibly and agree to do their best and complete their part of the project. People may have different work styles, but they all need to agree to work together toward a common goal.
Communication Strategies for Managing Teams
Teams have their own personalities, a result of combining each individual team member with every other in a way that creates a totally new network of interactions. A way to organize your thinking about teams is to visualize them as always seeking a balance between accomplishing the work at hand and maintaining the relationships among team members. In fact, teams will often have two leaders, not just one. Usually one person will emerge who leads members to accomplish tasks, and another person will emerge who is concerned with the social relationships among group members. Both are necessary for the team. These individuals have been labeled by other researchers as, respectively, task leader and socioemotional leader. Every team is subject to tensions that are an outgrowth of seeking a balance between accomplishing tasks and maintaining relationships among team members.
The team must be motivated. One way to keep the team positively oriented throughout the entire process is to select good people at the outset. Look for enthusiasm, imagination, and an ability to communicate with different kinds of people. These basic attributes hold the potential for success. It also helps to hire superior writers and articulate speakers who can present proposals and work directly with customers. Trust is an important part of a team. All members of the project need to act responsibly and agree to do their best and complete their part of the project. People may have different work styles, but they all need to agree to work together toward a common goal.
Communication Strategies for Managing Teams
Teams have their own personalities, a result of combining each individual team member with every other in a way that creates a totally new network of interactions. A way to organize your thinking about teams is to visualize them as always seeking a balance between accomplishing the work at hand and maintaining the relationships among team members. In fact, teams will often have two leaders, not just one. Usually one person will emerge who leads members to accomplish tasks, and another person will emerge who is concerned with the social relationships among group members. Both are necessary for the team. These individuals have been labeled by other researchers as, respectively, task leader and socioemotional leader. Every team is subject to tensions that are an outgrowth of seeking a balance between accomplishing tasks and maintaining relationships among team members.
For the team to continue its effectiveness, tensions must be continually resolved. Minimizing or ignoring tensions will lead to ineffectiveness and eventual disintegration of the team. Much of the tension release necessary can be gained through skillful use of feedback by all team members. All members, however, need to agree that the way they interact (i.e., process) is important enough to merit some time. Productivity goals for processes are discussed in a later section.
Securing agreement on appropriate member interaction involves creating explicit and implicit team norms (collective expectations, values, and ways of behaving) that guide members in their relationships. A team’s norms belong to it and will not necessarily transfer from one team to another. These norms change over time and are better thought of as a team process of interaction rather than a product. Norms can be functional or dysfunctional. Just because a particular behavior is a norm for a team does not mean it is helping the team to achieve its goals. For example, an expectation that junior team members should do all project scheduling may be a team norm. By adhering to this norm, the team is putting extreme pressure on new members and not taking full advantage of the experience of the team. It is a norm that, if continued, could make team members waste precious resources.
Team members need to make norms explicit and periodically assess whether norms are functional or dysfunctional in helping the team achieve its goals. The overriding expectation for your team must be that change is the norm. Ask yourself whether team norms are helping or hindering the team’s progress.
Setting Project Productivity Goals
When you have worked with your team members on various kinds of projects, you or your team leader will acquire acumen for projecting what the team can achieve in a specific amount of time. Using the hints discussed in the earlier section in this chapter on methods for estimating time required and coupling them with experience will enable the team to set worthwhile productivity goals.
Systems analysts are accustomed to thinking about productivity goals for employees who show tangible outputs, such as the number of blue jeans sewn per hour, the number of entries keyed in per minute, or the number of items scanned per second. As manufacturing productivity rises, however, it is becoming clear that managerial productivity must keep pace. It is with this aim in mind that productivity goals for the systems analysis team are set. Goals need to be formulated and agreed to by the team, and they should be based on team members’ expertise, former performance, and the nature of the specific project. Goals will vary somewhat for each project undertaken, because sometimes an entire system will be installed, whereas other projects might involve limited modifications to a portion of an existing system.
Motivating Project Team Members
Although motivation is an extremely complex topic, it is a good one to consider, even if briefly, at this point. To oversimplify, recall that people join organizations to provide for some of their basic needs such as food, clothing, and shelter. All humans, however, also have higher-level needs, which include affiliation, control, independence, and creativity. People are motivated to fulfill unmet needs on several levels. Team members can be motivated, at least partially, through participation in goal setting, as described in the previous section. The very act of setting a challenging but achievable goal and then periodically measuring performance against the goal seems to work in motivating people. Goals act almost as magnets in attracting people to achievement.
Part of the reason goal setting motivates people is that team members know prior to any performance review exactly what is expected of them. The success of goal setting for motivating can also be ascribed to it, affording each team member some autonomy in achieving the goals. Although a goal is predetermined, the means to achieve it may not be. In this instance team members are free to use their own expertise and experience to meet their goals. Setting goals can also motivate team members by clarifying for them and others what must be done to get results. Team members are also motivated by goals because goals define the level of achievement that is expected of them. This use of goals simplifies the working atmosphere, but it also electrifies it with the possibility that what is expected can indeed be done.
Managing Ecommerce Projects
Many of the approaches and techniques discussed earlier are transferable to ecommerce project management. You should be cautioned, however, that although there are many similarities, there are also many differences. One difference is that the data used by ecommerce systems are scattered all over the organization. Therefore, you are not just managing data in a self-contained department or even one solitary unit. Hence, many organizational politics can come into play, because units often feel protective of the data they generate and do not understand the need to share them across the organization.
Creating the Project Charter
Part of the planning process is to agree on what will be done and at what time. Analysts who are external consultants, as well as those who are organization members, need to specify what they will eventually deliver and when they will deliver it. This chapter has elaborated on ways to estimate the delivery date for the completed system and also how to identify organizational goals and assess the feasibility of the proposed system.
The project charter is a written narrative that clarifies the following questions:
Securing agreement on appropriate member interaction involves creating explicit and implicit team norms (collective expectations, values, and ways of behaving) that guide members in their relationships. A team’s norms belong to it and will not necessarily transfer from one team to another. These norms change over time and are better thought of as a team process of interaction rather than a product. Norms can be functional or dysfunctional. Just because a particular behavior is a norm for a team does not mean it is helping the team to achieve its goals. For example, an expectation that junior team members should do all project scheduling may be a team norm. By adhering to this norm, the team is putting extreme pressure on new members and not taking full advantage of the experience of the team. It is a norm that, if continued, could make team members waste precious resources.
Team members need to make norms explicit and periodically assess whether norms are functional or dysfunctional in helping the team achieve its goals. The overriding expectation for your team must be that change is the norm. Ask yourself whether team norms are helping or hindering the team’s progress.
Setting Project Productivity Goals
When you have worked with your team members on various kinds of projects, you or your team leader will acquire acumen for projecting what the team can achieve in a specific amount of time. Using the hints discussed in the earlier section in this chapter on methods for estimating time required and coupling them with experience will enable the team to set worthwhile productivity goals.
Systems analysts are accustomed to thinking about productivity goals for employees who show tangible outputs, such as the number of blue jeans sewn per hour, the number of entries keyed in per minute, or the number of items scanned per second. As manufacturing productivity rises, however, it is becoming clear that managerial productivity must keep pace. It is with this aim in mind that productivity goals for the systems analysis team are set. Goals need to be formulated and agreed to by the team, and they should be based on team members’ expertise, former performance, and the nature of the specific project. Goals will vary somewhat for each project undertaken, because sometimes an entire system will be installed, whereas other projects might involve limited modifications to a portion of an existing system.
Motivating Project Team Members
Although motivation is an extremely complex topic, it is a good one to consider, even if briefly, at this point. To oversimplify, recall that people join organizations to provide for some of their basic needs such as food, clothing, and shelter. All humans, however, also have higher-level needs, which include affiliation, control, independence, and creativity. People are motivated to fulfill unmet needs on several levels. Team members can be motivated, at least partially, through participation in goal setting, as described in the previous section. The very act of setting a challenging but achievable goal and then periodically measuring performance against the goal seems to work in motivating people. Goals act almost as magnets in attracting people to achievement.
Part of the reason goal setting motivates people is that team members know prior to any performance review exactly what is expected of them. The success of goal setting for motivating can also be ascribed to it, affording each team member some autonomy in achieving the goals. Although a goal is predetermined, the means to achieve it may not be. In this instance team members are free to use their own expertise and experience to meet their goals. Setting goals can also motivate team members by clarifying for them and others what must be done to get results. Team members are also motivated by goals because goals define the level of achievement that is expected of them. This use of goals simplifies the working atmosphere, but it also electrifies it with the possibility that what is expected can indeed be done.
Managing Ecommerce Projects
Many of the approaches and techniques discussed earlier are transferable to ecommerce project management. You should be cautioned, however, that although there are many similarities, there are also many differences. One difference is that the data used by ecommerce systems are scattered all over the organization. Therefore, you are not just managing data in a self-contained department or even one solitary unit. Hence, many organizational politics can come into play, because units often feel protective of the data they generate and do not understand the need to share them across the organization.
Creating the Project Charter
Part of the planning process is to agree on what will be done and at what time. Analysts who are external consultants, as well as those who are organization members, need to specify what they will eventually deliver and when they will deliver it. This chapter has elaborated on ways to estimate the delivery date for the completed system and also how to identify organizational goals and assess the feasibility of the proposed system.
The project charter is a written narrative that clarifies the following questions:
- What does the user expect of the project (what are the objectives)? What will the system do to meet the needs (achieve the objectives)?
- What is the scope (or what are the boundaries) of the project? (What does the user consider to be beyond the project’s reach?)
- What analysis methods will the analyst use to interact with users in gathering data, developing, and testing the system?
- Who are the key participants? How much time are users willing and able to commit to participating?
- What are the project deliverables? (What new or updated software, hardware, procedures, and documentation do the users expect to have available for interaction when the project isdone?)
- Who will evaluate the system and how will they evaluate it? What are the steps in the assessment process? How will the results be communicated and to whom
- What is the estimated project timeline? How often will analysts report project milestones?
- Who will train the users?
- Who will maintain the system?
The project charter describes in a written document the expected results of the systems project (deliverables) and the time frame for delivery. It essentially becomes a contract between the chief analyst (or project manager) and their analysis team with the organizational users requesting the new system.
Avoiding Project Failures
The early discussions you have with management and others requesting a project, along with the feasibility studies you do, are usually the best defenses possible against taking on projects that have a high probability of failure. Your training and experience will improve your ability to judge the worthiness of projects and the motivations that prompt others to request projects. If you are part of an in-house systems analysis team, you must keep current with the political climate of the organization as well as with financial and competitive situations. It is important, however, to note that systems projects can and do have serious problems. Those that are developed using agile methods are not immune to such troubles. In order to illustrate what can go wrong in a project, a systems analyst may want to draw a fishbone diagram (also called a cause-and-effect diagram or an Ishikawa diagram). When you examine Figure 3.23, you will see that it is called a fishbone diagram because it resembles the skeleton of a fish.
The value of fishbone diagrams is to systematically list all the possible problems that can occur. In the case of the agile approach, it is useful to organize the fishbone diagram by listing all the resource control variables on the top and all the activities on the bottom. Some problems such as schedule slips might be obvious, but others such as scope creep (the desire to add features after the analyst hears new stories) or developing features with little value are not as obvious. You can also learn from the wisdom gained by people involved in earlier project failures. When asked to reflect on why projects had failed, professional programmers cited the setting ofimpossible or unrealistic dates for completion by management, belief in the myth that simply adding more people to a project would expedite it (even though the original target date on the project was unrealistic), and management behaving unreasonably by forbidding the team to seek professional expertise from outside of the group to help solve specific problems.
Remember that you are not alone in the decision to begin a project. Although apprised of your team’s recommendations, management will have the final say about whether a proposed project is worthy of further study (that is, further investment of resources). The decision process of your team must be open and stand up to scrutiny from those outside of it. The team members should
consider that their reputation and standing in the organization are inseparable from the projects they accept
No comments:
Post a Comment