Roles on the Contractor s Software Development Team


Roles on the Contractor's Software Development Team

This section describes the major roles on software development teams, their responsibilities, and the attributes of strong performers in each role. Figure 5-1 illustrates these roles. The roles described here are for software development teams ranging in size from 6 to 30 people. On the lower end of this range, the same person may perform more than one role. I do not pretend to believe that this is the only organization that works, or that these are the only roles needed. Your specific situation and organizational norms will dictate the exact staffing profile. That said, I have organized several teams around these roles and found them to be successful. In the absence of any guidelines from your organization, the roles described here are a good starting point upon which to build a successful software development team.

Figure 5-1. Roles on the contractor's software development team


The Project Manager Role

Certainly a common and well-recognized role, the project manager role has evolved in recent years. The project manager was once a role of authority. The project manager would identify the tasks, delegate the tasks to the staff, and apply pressure as needed to push the staff to work until the tasks were done on time. The project manager would seldom share much information with subordinates, other than what was necessary for them to get the job done. This type of project manager is rapidly becoming a relic.

Project Managers and Team Interaction

Today's project manager is more of an "enabler" of teams. The project manager still identifies and delegates many of the tasks, but equally important, this person shares the vision with the team. He collaborates more closely with the team. Here are some additional characteristics:

  • The project manager is focused on making sure that each team member has the resources needed for him to be successful in his role.

  • The project manager protects the team from distractions. Sometimes, these distractions come from within the company. For example, other projects, proposals, and working groups can siphon valuable time needed to meet the project's schedule. In these situations, the project manager negotiates with these other groups. Rather than making the project team member fend for himself, the project manager tries to determine how to best satisfy the needs of everyone involved.

  • Today's project manager shares a great amount of information with the team. The entire project schedule and the progress against that schedule are communicated to the team. In addition, many metrics can be produced by software tools (some examples are discussed in the next chapter). Teams like to know that their work is contributing to the accomplishment of a goal; sharing metrics is one way of communicating the progress. Finally, at many companies, project managers regularly participate in management activities outside their project. These activities give the project manager visibility to other projects and new business opportunities at the company. When conducting project team meetings, project managers should share this information with the team. When a project team is focused on a project, it is comforting to know that their project manager is keeping them informed. This increases their confidence, because they know someone is looking out for them.

  • Project managers should avoid dictating a solution to the team and shouldn't get involved in lower-level details. Instead, the project manager allows the team to explore their own solutions to the problems at hand. The project manager should, however, recognize when the team is stuck and is no longer making forward progress. When this happens, the project manager can act as a sounding board and gently guide the team toward alternative approaches to solving a problem.

  • Project managers should avoid putting excessive pressure on the team. Most software developers are proud of their work and want to produce quality work on time. (If you have team members who do not have this attitude, why are they on your team?) Excessive pressuring of the team seldom results in higher productivity.

Protecting a Team From Distractions

On one project, I remember a technical lead approached me regarding a company-level activity she was being asked to perform. The activity had nothing to do with the project, but the fact that she was invited to participate was indicative of her good reputation within the company. "Get me out of this!" she said. At first, I was a bit shocked that someone would turn down such an opportunity. But I quickly realized that her dedication to the project was taking precedence over everything else. I told the other group that she could not be spared from the project. After that, I realized that one of my functions as a project manager was to protect the team from distractions.


Qualifications Needed for the Project Manager Role

The project manager is perhaps the most complex role on a software development team. The reason is because of the diverse skill set required. To be successful, a project manager must be proficient in the following areas:

  • Software development technologies (such as languages, tools, and platforms). Detailed low-level knowledge is not necessary, but the project manager must have basic familiarity with the technologies involved.

  • Software development methodologies (RUP, Agile, and Waterfall). Familiarity and experience with the methodology used on your project is essential.

  • Financial skills. Your company is in business to make a profit. To effectively manage the company, your management will want forecasts and projections of the project's financial performance. Forecasts and projections are also important so that you know you will not exceed the amount specified in the contract for the project. If this situation does occur, the sooner you can identify this trend, the better. No customer wants to hear that it will have to spend additional funds beyond what was planned. But if you can provide several months' notice, it may be possible for the customer to find additional funds or change the project's scope to fit within the originally budgeted amount.

  • Negotiation skills. All projects involve some form of negotiating. Whether it's during the proposal phase, achieving a final price, or internal negotiations regarding company resources, good negotiation skills are essential.

  • General people management skills. Project management involves constant interaction with people who have a wide range of interests, motivations, and skill levels. The success of your project depends on your ability to effectively work with others.

Interfacing with Other Organizations

No project manager can work in a vacuum. You need to interface with a number of other departments within your company to be successful. Here are some examples of other groups within your company, along with the nature of the interaction you will have with them:

  • Human Resources (HR). As a project manager, depending on your company's policies, you may be required to conduct performance reviews on members of your staff. Your HR department can supply guidance, form templates, and so on for these reviews. In most companies, HR also performs many recruiting functions. You need to accurately describe your needs so that HR can recruit viable candidates. In addition, as members of your team complete their assignments, you need to inform HR in advance so that they can find other assignments for these people. Finally, HR can give you guidance in special situations, such as policies for handling troublesome employees.

  • Accounting. Most projects bill their clients monthly. You need to communicate the proper information to Accounting so that they can produce whatever invoices are needed. You also need to review these invoices for accuracy. I have seen otherwise flawless project performances marred by a failure to invoice the client accurately and in a timely manner. Don't let this happen to your project.

  • Contracts. If your company provides outsourcing services often, it probably has a dedicated person or group devoted to managing the contractual elements of projects. You will be working with this person closely during the proposal process. She is familiar with the legal aspects of outsourcing arrangements, types of contracts, and so on. It is a good idea to periodically touch base with this person to let her know how the project is going. That way, if you run into difficulty, she will be familiar with the project's progress to that point.

  • IT/Facilities. As a project starts, your company's IT department furnishes the necessary equipment, such as PCs, servers, software, and networking services. Nearly every IT organization I have worked with (regardless of the company) is typically overworked, understaffed, and underappreciated. They often do not hear from anyone unless there is a problem, and "everything" is an emergency. Being one of the easier clients to deal with may make the difference when you have a difficult problem to solve. I always make a point of notifying the IT department of any needs I anticipate as soon in advance as possible. That way, when you really do have an emergency, they will respond appropriately. When IT helps you by solving your problem quickly, make sure you mention this to the organization's manager. If you follow these practices, your IT department will be grateful, which will pay dividends later.

  • Upper management. Your company's upper management wants to be kept informed of client satisfaction issues, as well as opportunities for additional business with that client. If the project is going well and the client is satisfied, you may have nothing more than a 30-second summary explaining this. If there are issues requiring your management's attention, keep it short and to the point. If there are action items requiring management involvement, make these clear, with a specific time line.

Aspiring to the Project Manager Role

Most project managers come from either the development ranks or nontechnical ranks. Each has strengths and weaknesses.

A project manager coming from a development role already is acquainted with technologies and software development processes. You will be strongly tempted to get closely involved with coding, design, and other detailed activities. You need to resist this temptation. Remember the importance of other aspects of the project manager position, especially financial tracking and forecasting. Your ability to foster the relationship with your customer, and to work closely with the other departments in your company, is of paramount importance. Finally, team building, particularly for developers, is especially emphasized. For you to successfully resist the temptation to get involved with technical details, you need to have complete trust in the people who make the technical decisions on your team.

A project manager who comes from a nontechnical background might find managing a software development project to be a bit of a culture shock. For project managers in this situation, your selection of the technical lead role on your project is especially important. In fact, you may want to choose a technical lead who has experience managing projects. The technical lead will become a trusted advisor.

The most frequent frustration I hear from project managers in this situation is that software development in general seems very unpredictable. Seemingly small changes can have significant effects on cost and schedule. My advice to these project managers is not to commit to any changes without first consulting the project team. You need advisers you can trust, because you will encounter situations requiring judgment tempered by experiences you might not have. Another frustrating aspect is that measurable progress seems intangible. An iterative lifecycle process can help mitigate this. As executable releases are produced, some "hands-on" time with the releases can alleviate this frustration.

The Developer Role

Most projects have many developers. In contrast with the project manager role, the developer's role appears straightforward and simple: Apply technical skills toward implementing the project requirements, and solve related problems. However, it is not always that simple. The developer role is an interesting balancing act of creative problem solving versus conformity to requirements. It also involves adapting to changing situations while working to control change. Finally, it involves quickly cranking out code versus building in quality along the way through unit-level and some integration-level testing. The best developers balance these factors well.

Aside from the governing principles for team building in general, the specific skills needed for developers depend on the technologies used by your project, so we will not cover them here.

Another consideration is the type of process used on the project. A large project with lots of formality and ceremony may not be a good fit for developers who have experienced only small, unstructured projects with no formal process in place.

There is one caveat to observe with hiring developers. In addition to the usual skills with the languages and platforms used for software development, make sure that the developer is willing to use the tools provided as part of your software development infrastructure. In other words, tools such as configuration management, change management, visual modeling, and testing are important to the success of the team as a whole. I have seen a few otherwise excellent developers who are either reluctant to use these tools or who outright refuse to use them. If adherence to software process is important, make sure that the developer is on board with consistent use of these tools and adherence to the practices used by your team.

The Architect Role

Architects usually rise from the developer ranks. The typical architect is a senior developer rising in her career who eschews management roles in favor of "staying technical." This is an important role, because the architect identifies and develops the foundation or framework of the system being developed. Poor choices and decisions made in designing the architecture can lead to disaster later in the project. One of the underlying principles of the RUP and iterative development is that the architecture is the first priority in development and receives attention in the project's initial iterations. This makes sense, because the architecture is a major risk area, and the consequences of failure are high.

Qualifications Needed for the Architect Role

Qualifications for the architect role are similar to those of the developer role, but with some important additions:

  • The architect is one of the first people to join the team, along with the technical lead.

  • The role of architect involves an aspect of salesmanship. When a candidate architecture is identified, the architect must "sell" the idea to the rest of the development team. Accordingly, the architect must be someone who commands respect from the other developers on the team. The elements that the individual developers will use must be very clearly documented and communicated to the developers. The architect should also monitor the developers' work to ensure that the architectural decisions are being adhered to. In addition, the architect needs to be available to solve problems when issues arise.

  • Because of the importance of the system architecture, I recommend that the architect have prior experience with the same technologies on at least one other project. Ideally, the candidate architect has experience both as a developer using the technologies on the prior project and as an architect on a prior project with the same or similar technologies. This provides the best of all worlds. The architect will have an understanding of the developer concerns as a result of her experience, and your project will benefit from lessons learned on the architect's previous projects.

The Technical Lead Role

The technical lead is typically the most senior developer on the team. This person directs the dayto-day activities of the developers, testers, and analysts. He also mentors the more junior developers. He may also have some development tasks of his own.

The technical lead is often a senior developer who aspires to be a project manager. In fact, the technical lead performs many of the tasks normally associated with the project manager. However, being a developer, the technical lead works every day with the other developers on the team and can delegate tasks according to the developers' specific skills and talents. Put another way, the technical lead is more of a tactical leader, and the project manager role is a strategic one.

Qualifications Needed for the Technical Lead Role

The technical lead role qualifications are similar to those for the architect. The technical lead must be respected both as a competent developer and as a leader. In addition, the technical lead is the project manager's right-hand person. In other words, there should be complete trust between the project manager and the technical lead. They should have similar philosophies regarding managing and motivating people.

The Toolsmith Role

The toolsmith role is one I seldom see mentioned, but it is still important. On all software development projects, the software development team uses numerous tools, technologies, and processes. Most projects need to customize or tailor some of these tools to the project's specific needs. The toolsmith installs and configures the software development environment toolset and readies it for use. In addition, the complexity of the tools used means that, at some point, problems will be experienced, often at the worst possible time. Someone who is familiar with the tools needs to solve these problems fast to minimize the impact on the project schedule.

The qualifications to be a toolsmith are simple: knowledge of the tools, and the ability to customize them according to the organization's needs.

Who Pays for the Toolsmith?

Because this role is somewhat of a novelty, many customers do not understand this role and will question a bid that includes one. The customer clearly understands why a project manager, testers, and developers are needed, but a toolsmith sounds like a questionable item. Here are guidelines to follow:

  • If the customer dictates usage of specific tools your organization has not used extensively, bidding a toolsmith makes sense and can be justified.

  • Another scenario that occurs occasionally is that the customer pays to acquire the tools, which means that they must be installed and set up first. Bidding a toolsmith in this scenario is warranted as well.

  • If the customer wants the contractor to work on-site, be sure to ask who will customize and maintain the tools used for software development. If the customer has its own group to manage the environment, you will not be able to bid a toolsmith. However, to avoid the potential for misunderstanding later, ask what level of support you can expect later. You don't want to find out about this right before a deliverable is due when your configuration management system crashes.

  • Another possibility is to pay for the toolsmith through company overhead. The disadvantage of this is that the toolsmith may not be available immediately when you need him.

The Requirements Analyst Role

The requirements analyst role is unique in that the person in this role probably has the most contact with the customerpossibly even more than the project manager. The requirements analyst is responsible for translating the customer needs into specific requirements that are implementable, testable, and documented. This person also is consulted by the technical lead, developers, project manager, and testers whenever there is a question about the project requirements.

Qualifications Needed for the Requirements Analyst Role

The following are guidelines for the skills necessary in a requirements analyst:

  • Experience in the problem domain. For example, if the client is a bank and the application automates the processing of loans, some financial tracking experience is essential. The analyst's prior experience may not be with the exact same type of loan system. But in this example, the requirements analyst would need basic familiarity with terms such as simple interest, compound interest, amortization, and other terms commonly found in the problem domain. The reason is simple. In requirements elicitation meetings, the customer expects to come prepared to explain its functional requirements needs for the system. They do not expect to spend a significant amount of their time educating the analyst on basic terms of the problem domain.

  • The requirements analyst needs to be skilled in managing meetings. Requirements elicitation meetings can be challenging, because with some of the topics discussed, the participants in the meeting may not agree with each other. The requirements analyst needs to detect situations in which forward progress is no longer being made in the meeting and take steps to get it back on track again.

  • Because the requirements analyst works with people of widely varying backgrounds and personalities, he should nurture an open, friendly relationship with the customer representatives so that they will want to open up to him. The analyst also needs to be able to detect when stakeholders are uncomfortable with the proceedings and to take steps to meet with the stakeholder privately to determine the cause.

  • Finally, the requirements analyst needs to be very detail-oriented. He needs to create a complete audit trail linking each initial customer request with the final requirement that is delivered to the development team. He also needs to work closely with the tester (and possibly quality assurance) to ensure that each requirement is testable, succinct, and within the scope of the system to be built.

The Tester Role

The tester represents the last chance to catch problems before the system reaches the customer. Interestingly, the tester role has much in common with the requirements analyst role. Specifically, the tester needs detailed knowledge of the requirements.

As with the developer role, the tester role is not really simple and straightforward. With the increased complexity of software systems today, software testers must be increasingly technical themselves. Testers need knowledge of testing techniques, methods, and associated tools. They must be able to hold meaningful conversations with developers and be able to glean useful information from them. They must be meticulous and organized (much like the requirements analyst) to be able to thoroughly validate a system's requirements.

In the RUP, or any process involving iterative development, the tester needs to join the team much earlier than with projects that follow conventional Waterfall-based processes. The reason is that the development team will produce executable releases early in the project lifecycle, possibly as early as the Inception phase. Testing is covered in Chapter 11, "Testing."

The Configuration Management/QA Role

On small to medium-sized projects, the same person performs the configuration management (CM) role and the quality assurance role. As a team grows beyond 20 people or so, there is enough work for two people to perform these roles.

The Configuration Management Role

For the configuration management role, the primary responsibility is to be able to perform independent builds of the system without assistance from development. This person also works with the developers to document the build process. Another important responsibility is to know exactly which versions of files are needed to successfully perform the build. The CM engineer also needs to produce the exact versions of all the files that went into creating a release. The purpose is to make maintenance easier. When a problem with a software release is reported, the developers will have a much easier time reproducing the problem if they have the exact same version the problem was reported against. Finally, if an emergency bug fix is needed, the CM engineer must be able to re-create the exact source files used for a specific release so that she can correct the reported problem and deliver a patched release that has the exact same functionality as before but with the problem corrected. Finally, for each release produced by the development team, the CM engineer needs to be able to produce a report showing exactly what issues and problems were corrected with a given release, as well as which requirements were implemented.

To be effective, the person performing the CM role needs a configuration management tool and should be competent in its usage.

The Quality Assurance Role

Many organizations have a dedicated quality assurance engineer. Ideally, the person in the quality assurance role does not report to the project manager to ensure objectivity. The quality assurance engineer should not feel pressured to permit items affecting quality to pass.

Quality assurance personnel should be familiar with applicable standards, such as CMMI, various development processes (such as the RUP), and many other standards. This includes coding standards, user interface standards, configuration management, requirements management, and, in general, the entire software development process.

Quality assurance personnel have a tricky job. They must be able to focus attention on deviations from agreed-upon standards without invoking feelings of resentment among the project staff. Diplomacy is the key skill needed for these situations.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net