| Successful requirements management efforts on outsourced projects consistently have three main attributes: The contractor has easy access to the proper set of stakeholders in the outsourcing organization A strong working relationship with the stakeholders Proper collection, dissemination, and leveraging of information obtained from the stakeholders
Let's take a look at each of these attributes to determine who influences them and how they are established. Attribute 1: The Contractor Has Easy Access to the Proper Set of Stakeholders in the Outsourcing Organization A common complaint from contractor teams is that it's difficult to obtain answers about the problem domain, the business process, and user needs in general. Often, the obstacles leading to this difficulty are in place and can't be changed by the time the contractor analysts start their work. Therefore, the first step toward a successful requirements management effort begins during the contractual process, and during the writing of the Statement of Work and other contractual documents. The key influencer of this process is the procurement specialist or contracts specialist in the outsourcing organization. Tasks for Procurement and Contracting Professionals for the Outsourcing Organization The contractor needs to meet frequently with a core group of the end users of the system to be developed. The contract and Statement of Work should include statements to this effect. These meetings require a significant investment of time on behalf of the end users. In addition, the contracting team needs the end users to participate in meetings and reviews of artifacts produced by the contractor. If travel is involved, cost is an issue that must be addressed in the contract. The number and length of meetings required can only be a guess before the work begins. How quickly the contractor can gain an understanding of the system requirements is, in large part, determined by how quickly he can communicate with the stakeholders and users in your organization. Therefore, effort should be made to reduce or prevent any barriers or contractual issues that would slow down access to these stakeholders. In addition to meetings with stakeholders, the contractor needs access to (preferably, physical possession of) documents that detail the organization's business process, business mission, organization charts, phone lists, requirements documents, and potentially other artifacts that describe how the organization conducts business and who its key contacts are. Therefore, any contractual documents such as nondisclosure agreements and security clearances need to be in place before the contractor begins work. Finally, if the system to be developed will replace a legacy system, it is also important for the contractor to view how the users utilize the current system. |
Attribute 2: Establishing a Strong Working Relationship with Stakeholders After any contractual issues have been resolved to enable contact with the end users, the management of both the outsourcing organization and the contractor should encourage and promote activities to strengthen the working relationship between the system's stakeholders and the contractor's analysts. The key influencers of this process are the project managersfor both the outsourcing organization and the contractor. In some cases, additional management in the outsourcing organization is involved. Managing Stakeholders in the Outsourcing Organization If you are a project manager in the outsourcing organization, this note is for you. The most important aspect of the relationship you have with the development organization is between the user community and the analysts of the development organization. You should encourage contact between the two organizations. The stakeholders identified for this project need to invest significant time on this project. This involvement consists of attending and participating in meetings concerning requirements, requirements workshops, milestone reviews, and so on. They will also need time to review and comment on artifacts such as use cases and activity diagrams. This requires some relief from or relaxation of their current job responsibilities, creating some temporary hardship in your organization. The return on investment of their time is the ability to influence the product's development. The better the development organization understands the user community and the business processes, the more likely the elicited requirements will capture your organization's true needs. Depending on the relationship between the project management office in the outsourcing organization and the user community, this goal may be difficult to attain. For example, in many large organizations, you may have no direct managerial control over the end users. If this is the situation, you will have greater difficulty establishing those communications. It is not enough to simply ask the appropriate manager to make certain users available for a few hours. This sort of attempt will be less than successful. This kind of request is likely to result in the users being given this assignment in addition to their normal workload. This means that the users may be less than motivated to attend these important meetings and go the extra mile. Or participation will always be preempted by some "urgent" situation that arises. To solve this problem, set up a meeting for all the managers involved. Explain that the user's time is needed, and also make them aware that the amount of effort may necessitate reduction in the participant's normal duties. To determine the amount of time these people will be needed, consult with the project manager of the contracting organization. It's easier if the end users report to the outsourcing organization's project management office. Not only can you select the best people to represent the user community, but you also can have them participate fully by rearranging their normal duties if necessary. Extensive involvement of stakeholders in the requirements elicitation process yields many benefits. If there is any disadvantage to involving stakeholders, it is the fact that their investment of time is long-term. The benefits are not realized until near the end of product development, or perhaps when the product is released. These benefits are as follows: Involving stakeholders means that the end product is more likely to meet their needs and make their jobs easier. Involving stakeholders gives the contractor greater confidence that the product being built is what the customer actually needs. This reduces uncertainty and makes planning (and, therefore, predictability) better. When stakeholders are actively involved in shaping the product, they are more likely to accept it when it is ready for use; they take ownership of the product. The stakeholders feeling ownership can make training the users easier. They have seen "early releases" of the system and already have some familiarity with it when it is released. These selected stakeholders can potentially become the "experts" in their respective departments on how the new product works. This elevates their status among their peers. Users can help identify risks that would not be discovered from any other source.
|
Attribute 3: Collecting and Disseminating Information Obtained from Stakeholders One side effect of establishing a strong working relationship with stakeholders is obtaining a flood of information about requested features, functional requirements, needs, wants, and so on. Successful teams leverage this information to their advantage. Storing this information in a tool for tracking purposes is important. Chapter 6, "Establishing the Software Development Environment," covers the best practices for establishing the software development environment. IBM Rational offers Requisite Pro and ClearQuest to manage requirements. This section makes no assumptions about which tools are being used, so it covers the capabilities needed to manage information rather than tool-specific features. Essential Needs Information that would be considered essential includes the following: A list of the stakeholders in the outsourcing organization. Include all contact information, such as name, address, phone number, and e-mail. Also indicate who the person reports to in the organization and who reports to her. Finally, indicate her job title and role in the organization. For each feature or requirement request, indicate which stakeholders from the list of stakeholders made the request. Include the date and time the request was made and the circumstances under which it was collected. In other words, was the request made in an e-mail, phone call, or meeting? If it was a meeting, when was the meeting, where did it occur, and who else was there? Rate each feature or requirement request with a simple priority of importance from the stakeholders' perspective. It is important to do this when the request is made. I prefer a simple High, Medium, and Low scale. Anything more complicated results in too much time wasted trying to determine which rating fits best. Remember that this priority may change over time. At this point, you simply want a general priority rating. For every meeting that occurs with stakeholders to discuss requirements, be sure that someone takes detailed meeting minutes. This will pay dividends later. Some sort of "audit trail" is important so that details are available indicating who changed the requirement each time a change is made.
Needs That Are Useful But Not Essential Some information from stakeholders, while not essential or required, can still prove very helpful. Such information includes the following: It is useful to be able to create charts or graphs that indicate counts of requirement requests against stakeholders. This is useful to share with management of the outsourcing organization. It also identifies users who have not made significant numbers of requests. Sometimes, in group meetings, one or two users monopolize the meeting. Other users may not feel comfortable speaking in group settings. The counts will help you identify users you may consider approaching outside the group to gain additional input. Another useful capability is a graph plotting new features obtained over time. After you have met with all the users a few times, it is reasonable to expect the number of new requests to decrease over time. Similarly, it is useful to track requested changes to requirement requests over time. If both new requests and changes decrease, this is a sign that the requirements are stabilizing.
There are many benefits to storing requirements and associated information in an automated tool. The key is to store information that normally resides in the project analysts' memory in the tool instead. The benefits are as follows: Requirements information can be searched, and each member of the project team can obtain answers to questions about the requirements without depending on asking someone. This reduces dependency on one person. Development progress can be measured against the requirements, with each requirement "checked off" as it passes testing. This provides a clear measurement of progress toward completion. New members of the project team can use this "storehouse of knowledge" to become familiar with the project requirements. The project is less affected by personnel turnover, because more information is kept in the tools instead of in someone's head. When planning iterations, it is easier to group requirements so that they can be sorted by the iteration in which they will be implemented. Dependencies between different types of requirements can be established and tracked. When managing issues related to scope, it is easier to investigate what-if scenarios for planning purposes by examining and manipulating dependencies between requirements.
Meeting with Stakeholders You've made sure no contractual barriers exist to interacting with the stakeholders. You've had an initial meeting with the stakeholders, and you convinced them of the value of investing their time. Great! But keep in mind the following points: Not all stakeholders who participate in the meetings will be enthusiastic about doing so. In fact, some may prefer not to be involved but were told by their managers that they must be. Other stakeholders will be very enthusiastic about spending time with you. They may try to monopolize your time. Preventing this from derailing full participation by everyone requires a great deal of tact and careful customer management. Show respect for the stakeholders' time by giving them advance notice of meetings, and indicate the main topics to be discussed. This sets their expectations and allows them to collect their thoughts and any needed artifacts so that they can come to the meeting prepared. After each meeting, prepare detailed meeting minutes, summarizing any decisions and topics discussed. Circulate them to all meeting attendees. This gives the stake-holders an opportunity to review the topics discussed and clarify their position. It is not uncommon for disagreements to occur among the stakeholders when discussing issues of business process. Honest disagreement and lively discussion are useful, but personal attacks are not welcome. If you see this happening, you must defuse the situation, or the meeting will cease to be useful. Consider tabling the current issue and moving on to the next. Not everyone is comfortable expressing her opinion in meetings. If one participant seems very quiet, consider approaching her after the meeting. You may find that she opens up with a lot of useful information. Or perhaps she is not the right attendee for the topic being discussed. Either way, you will have learned an important piece of information, and the person will respect the fact that you valued her opinion enough to approach her specifically. Employ best practices for meetings discussing business process and requirements. In particular, ensure that the attendees are appropriate for the topics being discussed. Keep the meeting to three to five attendees. Refer to Leffingwell and Widrig's book (see the bibliography) for comprehensive information on these best practices. I have found that it works well to have two attendees from the contractor. One asks the questions and manages the discussion, and the other writes minutes, helps clarify and summarize the discussions, and records future action items.
|
Refer to the bibliography for excellent references on best practices for conducting business process and requirements elicitation meetings. A Short Story of Two Extremes On one project, I managed a group that was to develop an enterprise-based system for workflow management. The product was heavily involved with the organization's business processes. Accordingly, we asked the project manager of the outsourcing organization to set up meetings with representatives of their user community. At the first meeting, only one person showed up. At the second meeting, no one showed up! I then explained to the project manager the importance of these meetings and why they were vital to getting a good result. Apparently, this discussion made an impression. At the next meeting, over 30 people showed up, far too many for a business process discussion! Eventually, we were able to get proper representation of the user community with only three or four users. |
|
