Captive Clients: The High Road To Customer Involvement This paper was presented at the 1996 CAUSE annual conference. It is part of the proceedings of that conference, "Broadening Our Horizons: Information, Services, Technology -- Proceedings of the 1996 CAUSE Annual Conference," page 2-3- 1+. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage. To copy or disseminate otherwise, or to republish in any form, requires written permission from the author and CAUSE. For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303-449-4430; e-mail info@cause.org. CAPTIVE CLIENTS: THE HIGH ROAD TO CUSTOMER INVOLVEMENT Diana C. Allen Architect/Modeler Phone: (317) 494-9852 dcallen@adpc.purdue.edu Harry D. Smith Business Analyst Phone: (317) 494-8764 hdsmith@adpc.purdue.edu Purdue University West Lafayette Indiana ABSTRACT The more involved customers are in the development, design, and testing of an information system, the better the resulting system. However, getting enough client involvement is usually difficult. Traditionally, the most valuable but least available resources on an information system project are the customers. The best, most knowledgeable customers should be available for a project, but these are exactly the people the business area cannot afford to spare. Management Information at Purdue has implemented a project staffing plan that provides unusual client involvement by introducing a new role into project team makeup. The new "Business Analyst" role is assigned full-time to a project and filled by people from the business areas. These staff bring an applied business perspective into the project team for analysis, design, and implementation issues. This paper describes the new role and explores how the Business Analysts were integral to implementing new client/server technologies, languages, tools, processes, and techniques used in a data warehouse implementation project. CAPTIVE CLIENTS: THE HIGH ROAD TO CUSTOMER INVOLVEMENT BACKGROUND Developers and customers agree that the best information systems result from high customer involvement. However, getting enough quality customer time is frequently difficult. Purdue, like many other organizations, is "doing more with less," and has less latitude these days to free up business staff from normal operational duties to participate in systems development projects. Staff are busier than ever. Now, there's more pressure for information systems to off load staff effort, but it's harder than ever to give up critical operational staff for the promised gains of a new information system. Purdue has found a way to do it that appears to be working, offers professional development opportunities for business area staff, and results in some unexpected benefits to the organization. In many information system shops, lead systems analysts in the IS organization are involved with business areas for years. They develop a high degree of business knowledge, and because of the depth of their understanding of business requirements and operations, they can reduce the amount of direct customer involvement required during development efforts. Years ago, Purdue's IS organization benefited from these kind of analysts, and the customers valued them greatly. But over time, Purdue's lead analysts lost some of their business affiliation. Information system maintenance pressures mounted, analysts were spread more thinly, some left, and others were promoted into management positions. Those who filled the vacancies were technically strong, but there were fewer of them, and they generally had less understanding of the business than the previous generation of lead systems analysts. Several years ago, to address mounting pressures to streamline and focus resources, and to find ways to leverage changes in the technological environment, Purdue developed a strategic plan for administrative computing. This plan identified the need for a different approach to systems development and a different model of customer involvement in development projects. Projects would be cross-functional. They would no longer be viewed as separate analysis, design, and implementation projects; they would be chartered and planned to cover all the phases of development effort with a single, focused project team. Purdue would view development projects not as IS projects, but rather as strategic projects which require business expertise as well as technical expertise. Projects would be staffed to provide dedicated business resources so the customer perspective could be adequately covered. The role of the "Business Analyst" was introduced. Development project teams now consist of a project manager and staff with the expertise necessary to complete the defined project. Project roles include the newly-identified Business Analyst who brings customer perspective to the project, technically-focused lead systems analysts (called Architect/Modelers), programmers (called Business System Developers), and data base administrators. The vision calls for customer areas to provide staff for the project manager and business analyst roles. Whenever possible, all project team members are dedicated to the project full-time. Business analysts, systems analysts, and programmers do not have other system responsibilities while on a development project. Most project managers are still found from within the IS staff ranks, but customer areas have provided business analysts for several projects. This paper focuses on the role of the Business Analyst, and explains the benefits Purdue has realized from the inclusion of these staff on development projects. (PROJECT TEAM ROLE CHART MISSING IN ASCII TEXT VERSION) STAFFING THE BUSINESS ANALYST ROLE The strategic plan asked for five vice presidents to identify one staff member from their business areas (Student Services, Business Services, Housing & Food Services, Development, and Physical Facilities) to provide coordination, focus, and management of administrative computing in the departmental areas. The plan also established which information system projects to launch first and identified the numbers and types of resources required by these projects. The three Management Information Directors and the newly-appointed Departmental Computing Managers developed and executed the process for identifying individuals to fill the first Business Analyst positions. They had several challenges to address. Allocation of the resource was a relatively easy commitment. Other, more difficult issues had to be resolved, such as how to handle functional and administrative reporting, salary administration, and day-to-day duty assignment. Since the vision was for Business Analysts to return to the business environment after 1-1/2 to 2 years, how to return them also became an issue. For a listing of administrative issues and Purdue's solutions, refer to the "Tricky Administrative Issues" inset on page 12. ************************************************************* FIGURE 2 QUESTIONS AND CONCERNS EXPRESSED BY POTENTIAL BUSINESS ANALYSTS * Specifically what will I spend my time doing? * What is the length of time I must be willing to commit? * Specifically who will I work for: MI or my home business area? Who sets my salary, evaluates my performance? * Where will this lead? How does this fit my career objectives? * Can I go back to my home business? If so, in what capacity? ************************************************************* To recruit staff for the Business Analyst positions, Management Information and the Departmental Computing Managers jointly announced the creation of these positions and held general information meetings. In those meetings, individuals interested in hearing more about the Business Analyst role heard a description of the position and had a chance to ask questions. Those meetings were heavily attended; more than 60 people came to learn more about the positions. Most staff expressing interest in the Business Analyst positions were staff from the business areas who already had substantial continuing systems experience or responsibility, the local system coordinator, or local systems support staff. Others had less direct or immediate responsibility, but expressed a desire to use the opportunity to change career paths or to simply widen experience and career alternatives. SELECTING THE BUSINESS ANALYSTS Appointment selections were handled differently for each Vice President's area. Some areas appointed staff, and others conducted informal searches among interested individuals. The most formal process was conducted by Business Services, the largest organizational area represented by a Departmental Computing Manager. The Vice President for Business Services, Ken Burns, sent out a memo to his administrative staff outlining expectations for the positions. (FIGURE 3 NOT AVAILABLE IN ASCII TEXT VERSION) Business Analysts should be able to serve as a conduit to interpret, document, and translate end-user information needs for the project team. They should focus on identifying process improvement recommendations. They should provide open, continuing communications with the business areas. ************************************************************* FIGURE 4 CRITERIA FOR SELECTION OF BUSINESS ANALYSTS * Keen business awareness and knowledge * Recognition of the possible benefits of applying technology to the business area * General level of comfort and experience with technology * Desire to increase involvement in technology * Analytical and problem-solving skills * Communication, facilitation, and presentation skills * Understanding of team-building concepts * Self sufficiency, independence, security, confidence * Ability to embrace and champion change ************************************************************* In all cases, the Departmental Computing Managers and Management Information Directors interviewed prospective Business Analysts and made the final hiring decision. As individuals were identified, decisions about how to handle their existing responsibilities and plan for their return were made. There was no single model for how this was handled. In some cases, individuals were promised their existing job when they returned, and others in the departmental area picked up their responsibilities while they were on temporary assignment. In other cases, the movement of people to these temporary assignments offered an opportunity to reorganize departmental areas, and the positions the Business Analysts held were drastically changed. Some Business Analysts became "employees without a home," with the promise of an unspecified position when their assignment was done. ************************************************************* FIGURE 5 BUSINESS ANALYST TRAINING COMPONENTS * Data Modeling techniques * Data Modeling tools * Basic office productivity and communication tools * Basic LAN tools and procedures * Project Planning and Time Reporting * Data Warehouse theory * Purdue's Data Warehouse vision and direction * Observation of projects in process ************************************************************* ORIENTATION AND TRAINING The Departmental Computing Managers and Management Information Directors scheduled an orientation and training period for the newly appointed Business Analysts which covered the first month of their new assignments. Training was accomplished through a combination of formal classroom instruction, computer based tutorials, and on-the-job training tasks. Experienced MI staff were assigned to mentor Business Analysts to provide ad hoc support and advice. THE DATA WAREHOUSE PROJECT The efforts of two Business Analysts working on Purdue's Data Warehouse implementation team illustrate how the role brought unexpected benefits to Purdue. The first subject area targeted for implementation in the Data Warehouse was financial data. Two Business Analysts were assigned to the team, specifically because of their strong financial background. Harry Smith had been a business manager for various academic departments and schools for 17 years. Charlie Klumpp had been a business manager for 4 years, worked for 2 years on the team which implemented the new financial system in 1987, and served as financial systems coordinator 9 years. The project's focus was to identify data maintained by legacy systems which was needed to support management decision- making. The two biggest challenges for the project team were figuring out what data was required, and implementing the technology to support information retrieval and reporting. The Business Analysts were expected to play a lead role in identifying required data, providing definitions for the data, and helping clients learn how to extract it from Oracle and present it in meaningful ways. We expected the Data Warehouse to provide opportunities for departmental staff to improve services. The Business Analysts were expected to help identify process improvements and encourage targeted users to change the way they did business. The DSS Team completed the project in three phases. The first phase was a prototype where they worked with an individual business manager to identify information needs and prove the technology (Ralph Kimball's Dimensional Modeling technique, Oracle, MS-Query, Excel). The second phase was a pilot project, where the user group expanded to six business managers. The DSS Team expanded the data, provided a set of standard queries, trained users how to retrieve the data they needed using MS-Query, and began putting metadata onto the World Wide Web. In the third phase, the DSS Team expanded the collected data to include employee-related financial data (payroll, budget), finalized the data design, implemented Brio Query as the end-user query tool, and created user- maintainable metadata which could be viewed as hypertext on the World Wide Web. The projects were a resounding success. The client community is pounding on our doors to get at the data faster than we can implement the infrastructure to support them. Client demand is due in no small way to the efforts of the Business Analysts. Here are some examples of what they brought to the project team: BUSINESS ANALYST CONTRIBUTIONS Credibility ThereÕs nothing quite as believable as someone who has "been there, done that." The DSS Business Analysts were viewed as clients working directly on the project team, not as information system analysts who were doing their best to figure out what clients need. When the Business Analysts said "I think this is a problem," or "This is really nifty-- you should check it out," our client group listened. Because the Business Analysts were on the team, the DSS Team experienced a much shorter than normal credibility-building period in the project. Communication The Business Analysts fostered open, continuous communication with the user community. There were very powerful informal communication channels working all the time to supplement normal project communication. Because of this free-flow of information, we were able to identify and head off developing problems before they became big ones. The Business Analysts were highly visible to the customers, and they spoke the same language. Business terminology was never a problem; the "business terminology" learning curve for the DSS project team was lessened, and the clients had to endure less technical terminology. Client Involvement and Knowledge Business Analysts provided two kinds of client involvement: their own expert business knowledge, and an active user client group. Because Business Analysts were part of the project team, they were available as the team worked out design issues and provided a high level of timely, expert input into discovery, design and testing processes. The Business Analysts were excellent testers, identifying not only obvious mistakes, but also subtle design changes which added benefit to the information. They also encouraged and demanded input from the clients, keeping them highly involved in the project. This excellent client involvement reduced the overall cost of the system by identifying problems before they were well-rooted in the system. Client Acceptance Because the Business Analysts kept the client group so highly involved, the clients have a high level of acceptance for the final system. This is not a system which IS went off and developed on their own and foisted off on clients who have to live with it. This is a system that clients helped develop and evolve with their own practical business applications in mind, and they understand many of its strengths and weaknesses. Enhanced Quality The availability of expert Business Analysts and highly- involved clients resulted in higher-quality deliverables. Just the sheer number of eyes checking things reduced mistakes. The project had the benefit not just of many eyes, but of many expert eyes. They constantly pushed the team to design beyond simple needs and include data which significantly improves the information they can generate. Useable Technology One of the more unexpected benefits the Business Analysts brought to the project was the acceptance of technology by the end-users. The DSS Team delivered this system in a technology environment which was completely new at Purdue. The Business Analysts were able to demystify the technology, demonstrate how to use it, and encourage experimentation by the users. The result is new technology which the clients are immediately ready to exploit. Organizational Change The strategic plan stressed that IS projects need to combine the entire systems development life cycle, need to involve clients in significant ways, and whenever possible, place control in the hands of the people most affected. The DSS system is a truly distributed system, and clients are accepting responsibility for their pieces of the system. This has required some significant organizational changes, starting from the paradigm shifts that enabled the Business Analyst role to be established, and continuing through turnover of various facets of DSS maintenance and support to the users themselves. From start to finish, the DSS project has been an exercise in shifting from traditional centralized management control to cross-functional management control. One executive commented that we know this cross-functional control is working when we cannot tell what organization an individual belongs to any more. The Business Analysts have been agents of change. REVIEW OF WHAT WE LEARNED Purdue has learned a great deal from its initial use of Business Analysts. There are several issues we still need to work out or improve: Executive Support Strong commitment at executive levels of business areas to the cross-functional development project approach is essential for getting funding for full time staff and covering duties left behind. Staffing levels are subject to the availability of resources from the business areas and the level of priority the business areas assign to the projects involved. Executive level staff need to be visibly supporting the process to ensure acceptance of the development projects and the Business Analyst roles by operational areas temporarily deprived of staff and to provide a measure of security for the Business Analysts. Clearly articulated benefits to the business area help develop this strong commitment. Business Area Support We have found that the more successful Business Analysts are highly involved with their business area, yet have no departmental responsibilities. Management makes the effort to communicate with them regularly, keep them informed of departmental issues, and provide guidance and counseling when necessary. Departmental management can also effectively "run interference" if problems develop on a project team. Salary Administration As we implement cross-functional project teams, job classifications and salary inequities across organizations become more of an issue. Purdue is in the process of addressing classification and salary for staff providing information system support across the University. Another salary-related issue is determination of the annual salary increase. The decision to leave salary administration issues for Business Analysts in their "originating" department meant that their annual increase amounts were determined by the departments. There is some concern that the Business Analysts who were temporarily relocated to project teams did not always receive fair consideration at budget time. There seemed to be an "out of sight, out of mind" issue. We need to make sure that the owning departments consider the contribution their Business Analysts are making to the University, recognize the additional skills, knowledge, and perspective they're developing, and compensate them equitably with staff they see each day. Business Analyst Professional Development Who takes responsibility for and funds continuing professional development is an issue. Purdue has a mixed model: departments have funded some project-related Business Analyst training, and the IS organization has funded some professional development for Business Analysts. There needs to be a concerted effort to make sure responsibilities are clear and that the Business Analyst's development does not suffer while on temporary assignment. No More Silos Business areas and IS must be committed to open, equal partnerships across organizational boundaries. Hidden agendas and a feeling of "mine vs. yours" will undermine the Business Analyst's effectiveness and increase risk for everyone involved. Clear Expectations Risk for the individual and for the organization is minimized in recruiting, selecting, and assigning Business Analysts expectations are specific and clear. See the "Tricky Administrative Issues" inset on page 12 for a listing of some of the issues which need to be resolved before hiring. Project Management Cross-functional development projects must be tightly run and must adhere to planned scope, resource, and time constraints. New Business Analysts may not be used to working on these kinds of projects and may require or expect wider latitude than the project managers can support. Understanding and supporting the project management approach is important for the Business Analyst. Team Building Purdue found it needs more focus on team skills in the selection process and Business Analyst training. While new Business Analysts have frequently participated in committee work, few have true cross-functional team experience. Developing strong, functioning project teams is a key factor to Purdue's project approach. Planning Process Planners must know what projects are coming up to effectively match Business Analyst knowledge and skills to project resource needs. Generating departmental enthusiasm and staffing commitments is easier for practical projects directly applicable to the business area. Knowing what projects are coming up allows the business areas time to prepare for resource shifts. Having the Project Manager identified before filling the Business Analyst role is also helpful. Applicants can have a better understanding of what the project will be like, and Project Managers can have an active voice in Business Analyst selection. Can I Come Home Now? The return of Business Analysts to a business area is essential if they are to maintain and refresh their working business knowledge. Unless they go back, their business expertise fades, and they become "only" excellent information system analysts. When the Business Analysts return, they take new skills, knowledge, and perspective back to the department. They build permanent relationships between the IS organization and business areas. There is some tendency to want to keep successful Business Analysts assigned to development projects to minimize turnover, provide continuity, and save on training and start-up. While there are positive short-term benefits to the development projects, there are serious negative long-term drawbacks, which include a permanent, unplanned reallocation of staffing levels from one organization to another. I Don't Want To Go Home!! Not everyone can or wants to go back to their originating department. Some Business Analysts are interested in changing their career path. Departmental management needs to understand the potential Business Analyst's career goals and provide the appropriate opportunities for growth while balancing the organizations need for building a pool of experienced Business Analysts. I Wanna Go Home -- But There Is No Home!! In some cases, "originating" departments took the opportunity to reorganize or realign duties to cover the responsibilities of staff appointed as Business Analysts. In these cases, there is no job to which the Business Analyst can return. Therefore, one of the selection criteria should be business experience and skills and adaptability suitable for a wide variety of positions. Senior Systems Analyst Development The corollary to developing the technical/project experiences of Business Analysts is to provide opportunities for senior systems analysts to develop business expertise by temporarily performing work in the operational business. This approach, coupled with the Business Analyst approach, would build a group of business-savvy analysts in both areas. Some argue, however, that this kind of development dilutes the technical skills of information systems analysts. Who Is it Harder To Train? Some feel that Business Analysts can probably learn the surface technical skills required for their project contribution more easily and faster than IS staff can develop enough business expertise. The truth is that development projects require both highly-developed business knowledge and highly-developed technical skills. Staffing a development project with both can be achieved by balancing the expertise of available staff. CONCLUSIONS The Business Analyst role had strongly positive effects on the Data Warehouse implementation project. Below is a graphic which summarizes impact of the Business Analyst role on key factors. Information was obtained by surveying the Project Manager, Business Services Computing Manager, IS Directors, participating clients, and project team members. (FIGURES 6 AND 7 NOT AVAILABLE IN ASCII TEXT VERSION) Based on our experiences with the Data Warehouse implementation project and the involvement of Business Analysts in other strategic project initiatives, we enthusiastically recommend incorporation of this role in information system development projects. Gartner Group recommends that organizations search for "best of class" employees who have a balance of business knowledge, technical knowledge, and leadership skills. Project teams which have a balanced set of these skills produce the best results. Our experience proves that including Business Analysts on our information system development projects provided a better balance of those skills, and moved our project team closer to the "ideal" mix. (FIGURE 8 NOT AVAILABLE IN ASCII TEXT VERSION)