Successfully reported this slideshow.

TAPUniversity Use Cases / RUP for Vendor Selection


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

TAPUniversity Use Cases / RUP for Vendor Selection

  1. 1. Fast-tracking acquisition with RUP: Completing a quot;buyquot; process during Inception in three steps Copyright IBM, 2005 Country/region [select] Terms of use All of dW Home Products Services & solutions Support & downloads My account developerWorks > Rational > Fast-tracking acquisition with RUP: Completing a quot;buyquot; process during Inception in three steps Level: Introductory Contents: Background: Project Refresh Step one: Evaluate vendor proposals in writing David Kohrell Step two: Evaluate onsite demonstrations in writing President, Technology As Promised, LLC Step three: Finalize discussions and sign a contract 15 Feb 2005 Conclusion References from The Rational Edge: The use cases that a software development team develops during the About the author Inception phase of the IBM Rational Unified Process, or RUP, can help speed the acquisition of third- Rate this article party vendor solutions. This article describes how to employ use cases to elicit and evaluate vendor proposals and then make a good purchasing decision. dW newsletters Subscriptions: dW Subscription The IBM Rational Unified Process,® or (CDs and downloads) RUP,® provides a nimble process for The Rational Edge moving projects forward -- from Inception through Elaboration, Construction, and Transition -- with guidance and accountability. Although RUP is a guide primarily for software development activities, it also provides essential material for an effective tools acquisition process. Based on my experiences with an actual government development project, this article describes and explores how to use the requirements you gather for a software development project to fast track the process of creating an RFP, evaluating bids, and selecting a vendor. It outlines three steps you can take to move a project quickly beyond Inception into Elaboration and Construction, with the confidence that you have made good choices. Background: Project Refresh Project Refresh, Nebraska's Workforce Development, Unemployment Insurance Benefit Payment System Modernization project, began in September of 2003. The project had adopted RUP, and I came aboard during the Inception phase to direct business modeling and requirements gathering activities. The basic aim was to create a better way of evaluating applications for unemployment insurance benefits. Within sixty days, we had created a validated set of requirements, forty-eight use cases with thirty-one actors, eighty-seven business rules, and 456 glossary definitions. Using RUP to guide us, we generated our use case models using the IBM Rational® RequisitePro® and IBM Rational® Rose XDE® Modeler products. RUP does not provide guidance for using use cases in an RFP, but that is what we did. We included them as functional requirements, with two priorities in mind: 1. First, and most important, to make our evaluation process as accurate as possible. In other words, to ensure that the vendor(s) most able to provide the product we wanted -- on time and within budget -- would get the highest scores, based on our evaluation. 2. Second, to devise an evaluation process that was quot;fireproof.quot; As this was a relatively lucrative contract, and in a space that is just beginning to open, we anticipated that a number of vendors would try to quot;claimquot; the space. We also expected a lot of scrutiny from those vendors we did not choose, so we needed a process that could withstand their examination. As we shall see below, our solution for the evaluation process included three major steps. Step one: Evaluate vendor proposals in writing
  2. 2. Fast-tracking acquisition with RUP: Completing a quot;buyquot; process during Inception in three steps Maintaining the aggressive schedule we had used to capture requirements throughout our vendor review and selection process yielded two enormous benefits: There was not enough time for our requirements to change significantly, and we were able to maintain strong executive support. With an extended schedule, that support might easily have eroded. After a thorough question-and-answer cycle, five vendors submitted their responses in mid-March of 2004. State personnel had by that time prepared their written and oral demonstration review material, required by State Purchasing before we opened the proposals. This was a significant quot;buyquot; decision, so as they rightly decided, we needed a consistent evaluation process. Our written proposal evaluation guide was composed of seven sections: q Executive Summary q Business Fit q Project Approach q Proven Solution q Technical Fit q Vendor / Staff Quality q Total Cost of Ownership The twelve evaluators included business and information technology professionals who helped shape the questions, scales, and weighting systems for each section. We wanted a large number of evaluators to ensure participation and ownership of the process throughout the organization. Figure 1 is an example from the Business Fit section that illustrates the four-point Lickert scale we used (one closed-ended response possible) to rate responses for priority items. Figure 1: Example from the Business Fit section of a proposal evaluation guide The thirty-seven benefit payment system use cases we had developed during Inception provided a context for elements that an evaluator might otherwise overlook or rush through. We assigned a weight to each one; those involving a core process were ranked the highest. Figure 2 shows the weight for the high- priority Initial Claim use case. Figure 2: Weight for Initial Claim use case The use case description explained the initial claim's purpose within a business context. This use case allows UI staff to file / create / accept an initial claim, including claimant and employer data. This use case receives data from Tax and Wage. This use case sends data to Wage (marks wages used). UI Staff identifies eligibility issues. Using such descriptions, just as we had captured them during the Inception phase, ensured that everyone could share and understand the context and meaning of each item. RUP does not really provide a way to incorporate non-functional or system specifications into a vendor review, so we did this via technical fit questions, as shown in Figure 3. We assigned each question a weight and point total.
  3. 3. Fast-tracking acquisition with RUP: Completing a quot;buyquot; process during Inception in three steps Figure 3: Technical fit questions that address non-functional specifications With the weighted questions in hand, the teams embarked on their review of hundreds of pages of RFP responses. Teams typically use one of two approaches when reviewing and scoring a vendor proposal: q Consensus scoring. The group gathers, discusses the proposal, and decides on a score. I have used this approach in previous public sector projects and consultations. Although it ensures more consistency in scoring, it can lead to group think or other undesirable social behaviors. Sometimes a person will alter his or her decision in order to be agreeable rather than because of a firm conviction. q Individual and group scoring. Each individual records a score, and the group meets to review these scores and compile an aggregate score. This was the approach we used for this project. For each method, the goal is to achieve a reasonable level of scoring consistency for individuals without inducing group think. In other words, you want intra validity -- each person should score each proposal consistently -- and also inter validity -- meaning that you hope to see a trend emerge from the scores of multiple people. At the conclusion of our written RFP response review, we could see that three of the five vendors had submitted proposals that met our stated need. Based on staffing resources, we decided to hold a two-day demonstration session. We invited the three vendors to prepare presentations for the RFP review team members, plus twenty-nine other business and technical subject matter experts. Step two: Evaluate onsite demonstrations in writing For both vendors and reviewers, few activities are as daunting as an onsite demonstration. Each side desires to go much deeper than a cursory sales demonstration, but the time allotted for each vendor often feels too short to accomplish this. Typically, customers want to see the technology's full capabilities, and vendors want to assure customers that their technology can accomplish everything they need -- without committing too much. In a public sector setting, the regulations and rules surrounding such demonstrations can feel suffocating, but they are needed to ensure equity in decision- making. As noted earlier, we crafted the outline and core content for onsite demonstrations concurrently with the proposal review guide. After our intense RFP review, which lasted twelve or thirteen days, we turned our attention to finalizing that review guide. We divided it into two parts -- business and technical -- which mirrored how we would spend the two days of the demonstration session. Day one -- Business review Together with the Nebraska Unemployment Insurance business team, we crafted a set of twelve business usage scenarios, based on the use cases we created during Inception, that we gave to the three vendors. The forty-one reviewers also received score sheets based on these scenarios. The first usage scenario focused on the primary business activity: completing an unemployment insurance claim. It cycled through seven use cases, as shown in Table 1. The other eleven usage scenarios were variations on this one. Our goal was to compare how the competing vendors would address this scenario. We asked each one to demonstrate how their system actually processed or could process each use case, rather than merely describing what their solution would do in a PowerPoint overview. Table 1: First usage scenario -- A typical claim Description from use case or additional Use case name Steps vendor will follow (goal = demonstrate each use case) enhancement (AE)
  4. 4. Fast-tracking acquisition with RUP: Completing a quot;buyquot; process during Inception in three steps Use cases: 1, 4, 13, 18, 11, 22, 24 D D 1. Initial Claim This use case allows UI staff to file/create/accept 1. Enter the claimant information as claimant data/initial claim. (business rule) an initial claim, including claimant and employer 2. Demonstrate system validation process(es). data. This use case receives data from Tax and 3. Enter associated employer data for the claimant. Wage. This use case sends data to Wage 4. Demonstrate system acceptance of the claim entry. (marks wages used). UI Staff identifies eligibility issues. 4. Modify Employer Data This use case allows UI staff/system to modify 5. Enter revised employer data. employer data and create an audit history trail. 6. Demonstrate system validation. This use case updates the wage system. This 7. Update system. use case retrieves and displays data from Tax 8. Demonstrate information generated for an updated employer(s). and Wage. This use case sends data to Wage 9. Add another employer. and marks the wages as used or not used. 18. Calculate Benefit Monetary This use case allows the system to calculate the 10. Show that no previous monetary has been created. initial monetary. The system determines the 11. Demonstrate how the system identifies base period. WBA and MBA. This use case generates an 12. Demonstrate how the system identifies qualifying wages. appealable monetary document, which is mailed 13. Demonstrate creation of potential monetary entitlement (MBA and WBA). The system to the claimant; fall away or copy goes to UI staff. completes the monetary and triggers the payment cycle. The system uses base period This use case receives data from Tax and Wage wages to calculate MBA. The system uses high quarter wages to calculate WBA. as noted in the initial claim use case. 14. Show the extent of individual employer liability 15. Show the sequence of charging. 13. Create Benefit Issue This use case allows the UI staff to establish an 16. Enter issue code into the system. active issue. This use case prevents payments on the claim. The system sets issues by RIC, SASI, or UI staff. 11. Determine Non-monetary This use case allows the UI staff and others to 17. Demonstrate nonmonetary determination from predetermined or free form template. Eligibility adjudicate when a nonmonetary issue has been 18. Show narrative stored and returned to user. detected or reported. The system reflects the 19. Show an appropriate resolution that allows or denies payment of Unemployment resolution of the issue. This use case sends an Insurance Benefits. **See special requirements for list of resolution/issues.** appealable determination to interested parties. 20. Print monetary and nonmonetary determinations (407 and 410). This use case receives data from Tax. 21. Enter program code and update program monetary. 22. Show audit history and workload tally count for adjudicators. 22. Pay Benefits This use case allows UI staff or Continued 23. Enter data for weekly benefit claim. Claims IVR export to pay unemployment 24. Show how an issue is established. insurance benefits. A payment is issued, and the 25. Demonstrate how system verifies and updates. system updates. 26. Show how the system determines that the week is payable (or credit Waiting Week). 27. Demonstrate the system calculating amount of weekly payment. 28. Show how the system issues a check and updates. 24. Process Benefit Charges This use case allows the system to assign 29. Show how the system tracks charging. charging. Data gets recorded daily, and the 30. Show how the data are gathered and grouped to produce UI Distribution of Charges system updates. (Data is sent to the TAX system reports. quarterly.) (special requirement) 31. Show what the daily UI Distribution of Charges reports could look like. Day two -- Technical review On the second day, we drilled in on the specifics of how each vendor would deliver on what the system was supposed to do. Although the discussion was technical (downright geeky, actually), it proved valuable to keep the business members of the RFP Review Team involved. However, the additional business- oriented subject matter experts did not participate in the second day because of competing duties, as well as a desire on our part to keep them focused on the what rather than the how for each solution. Each day, the RFP team that had set the day's agenda struggled with how to incorporate questions and answers that allowed reviewers to dig into specific issues. Ultimately, we decided that all forty-one reviewers should submit their questions in writing to a team member we designated as the emcee -- and that person then posed the questions to the vendors. The reviewers generated a wealth of questions: more than seventy on day one, and two per vendor. We logged each question and subsequent responses in a spreadsheet. In many ways, this formal approach forced us to do more careful deliberation. As one manager put it, quot;From a strategic view, the decision to screen and log questions required us to plan the process more carefully, and led the planning group to discuss / consider the types of questions that would be allowed in the oral environment. This improved the process because we identified, in advance, the types of questions that would aid in achieving our goals (best vendor / fireproof selection).quot; The negative was that quot;We likely missed out on some serendipitous connections and learning that might have occurred with no-holds- barred questioning.quot; Once the onsite demonstrations were completed, we tabulated the highly detailed score sheets. Not surprisingly, the vendor that scored highest in our initial
  5. 5. Fast-tracking acquisition with RUP: Completing a quot;buyquot; process during Inception in three steps RFP evaluation also came out on top for the onsite demonstration. That was TCS America. Now, five months into the development lifecycle, we still feel confident that we selected the best possible vendor through a fair, defensible process. Step three: Finalize discussions and sign a contract We notified TCS America in May 2004 that we wanted to negotiate a contract. This represented the end of the vendor selection portion of the BPS Modernization Project. Remember that the use cases were still at an Inception level. Although contract negotiations are not the right time for moving into the Elaboration phase, we needed more in-depth discussion about requirements, the RFP, the TCS proposal, and their on-site demonstration before signing an agreement. This required several weeks. Then, once we signed the contract, we could begin working in earnest on the development project, using RUP guidelines once again to move quickly into Elaboration and then Construction. We've made good progress, but there is still much to be done before we really have quot;that new system.quot; Conclusion On this project, RUP gave us two great assists. First, the time and attention we devoted to developing use cases according to RUP guidelines paid off handsomely. The use cases provided guidance to us during later tasks and ultimately saved us a lot of time -- in orchestrating what each vendor should demonstrate, for example. Second, using a standard process allowed us to give a large number of people exposure into the business and technical processes we were executing on a daily basis. In addition, the formal, written questions we prepared for the vendor proposal conference, based on the use cases, allowed us to elicit valuable information and demonstrations from each vendor and facilitated communication between vendors and review teams in the final stages of decision making. In my next article for The Rational Edge, which will be published in late spring 2005, I will review the release of our first set of use cases for the Initial Claim scenario, tracing events from Construction into Transition. References Fredrick Ferm describes an excellent approach for using RUP to manage the complexities of acquisition in the January 2004 Rational Edge (http://www-106. That article concludes a five-part series on procurement with RUP; I recommend a study of his approach. About the author David Kohrell is the president of Technology As Promised, LLC, ( and the primary professor of project management at Bellevue University in Omaha, Nebraska. A member of the IBM Scholars network, he has led, trained, and consulted on product development, software delivery, network infrastructure, and process engineering projects at several organizations. For the Nebraska Workforce Development project, he worked in partnership with Mitchell Ummel, president of UmmelGroup International, under a subcontract with plaNET Consulting / CSG's Unemployment Insurance Solutions Team. He holds an M.A. in MIS management, another M.A. in community and regional planning, and a B.S., all from the University of Nebraska. He has Microsoft Solutions Framework Practitioner (MSFP, 2003) and MS Project 2000 (MOS, 2002) certifications from Microsoft, as well as Project Management Professional (PMP, 2000) certification from the Project Management Institute. Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments? Submit feedback developerWorks > Rational >