Rules of engagement--leveraging technology to define project business requirements
As we forge ahead into the 21st Century, technology is rapidly permeating the financial services sector:
• Computer imaging replaces microfiche
• PC programs replace manual paper processes
• ATM‘s replace branch tellers
• Internet web sites replace brick and mortar.
The obsolescence of such banking relics as the abacus, paper retention warehouses, and ledger books brings a new set of challenges. As technology drives us into a more efficient and effective era, it is quickly becoming a critical component of virtually any bank's operations. Consequently, technology development is the most common type of project implemented within today's financial services institutions.
This evolvement of technology raises old questions to new and more critical levels: What does the client expect from the end deliverable? What are the client's business requirements that define the planning and implementation stages of this project? In other words, what is the real scope of the project?
This paper describes how Comerica turned technology upon itself, creating an innovative intranet application that facilitates the comprehensive collection and effective communication of business requirements for technology development projects within financial services.
As with many banks, Comerica has spent several years and significant effort in defining processes that would ensure an accurate and complete understanding of client business requirements by the Information Services (I.S.) liaison. These requirements form the infrastructure for estimating project effort/cost and later, become the foundation for detailed requirements and design. However, picking the brain of a business client can be a difficult process. Often, a technical professional cannot fully understand the intricacies of the client's business and the needs of their external customers. Similarly, the client may have difficulties putting their “vision” into clearly understood, technical business requirements. The end result can be a project that falls short of fulfilling the client's needs:
• Work estimates and expenses are underestimated
• Project scope is incomplete
• Project deliverables are insufficient
• Rework is often necessary.
Consequently, all three sides of the traditional project management triangle (scope, budget, quality) are negatively impacted. Frequently, the project fails to meet client expectations.
To attack this problem directly, Comerica's Business Technology Services area initiated a “Rules of Engagement” process in 1998. The overall goals of the process were:
• To improve project management efficiency and effectiveness
• To ensure consistent expectations between business units and technical professionals
• To improve the quality of the business requirements and design deliverables.
The objective of this effort was a revised technology development lifecycle that encompassed a “Joint Requirements Analysis” phase (see Exhibit 1), where the Project Manager, Core Team and Business Client Representatives follow a set of preestablished steps to produce and validate business requirements. This process was promoted across Comerica.
The successful adoption of the Rules of Engagement (R.O.E.) process fostered I.S. management to perform further analysis to increase the effectiveness of the Joint Requirements Analysis component. As a result, a project was initiated to create the R.O.E. template, outlining key questions that were necessary to gather comprehensive business requirements for technology development projects.
The R.O.E. questions template has proven effective and thus, became the foundation for an intranet tool to automate and standardize the collection and sharing of the business requirements. Consequently, the R.O.E. system was introduced in early 2000.
The R.O.E. System Vision
The Rules of Engagement System was created to standardize and automate the business requirements collection and approval process for technology development projects. Using Lotus Notes technology, a common component on Comerica workstations, the R.O.E. system was designed to accomplish multiple objectives:
• Provide project participants with a standard and well-understood tool for articulating business requirements
• Provide easily accessible templates for business requirements collection
• Automate the process for collecting business requirements, yielding project efficiencies
• Automate the approval processes for the Joint Requirements Analysis phase, expediting project planning efforts
• Generate consistent documentation across projects
• Create a permanent record of business requirements documentation
• Reduce rework/revisions to business requirement documentation.
Overall, the R.O.E. System facilitates the complete and thorough collection of business requirements, yielding benefits in all project management knowledge areas:
• Scope Management: Ensures thorough scope definition, reducing potential scope changes.
• Time Management: Allows for accurate estimation of work effort and thus, improves schedule precision.
• Cost Management: Allows for creation of more accurate budgets through better understanding of work effort and other required technology expenditures.
• Quality Management: Facilitates the creation of quality standards needed for quality planning processes.
• Human Resource Management: Involves critical project team members in the early stages of the planning process, facilitating more effective organizational planning and staff acquisition/training.
• Communications Management: Yields valuable information associated with identifying project communications requirements.
• Risk Management: Assists in the early identification of project risks.
• Procurement Management: Provides information needed to accurately and thoroughly document product requirements for the solicitation planning process.
• Integration Management: Improves accuracy of the overall project plan.
Consequently, the R.O.E. System directly contributes to the successful completion of technology development projects within Comerica.
Components of the R.O.E. System
The R.O.E. System consists of three core components that are necessary to support the business requirements collection effort: Questions Repository, Project Database and Project Archive.
The Questions Repository is an electronic library of questions designed to simplify the creation of business requirements. This component forms the cornerstone of the R.O.E. System, providing a template that promotes consistency and thoroughness in the requirements collection process. There are three types of questions included in the repository:
• Required: Questions which are mandatory for inclusion within the business requirements. These are automatically assigned to new projects.
• Optional: Miscellaneous questions which are common within projects, but not necessarily required for every project. These must be individually retrieved by the Project Manager if desired.
• Group: Questions that apply to certain types of projects and are retrieved by the Project Manager via keywords. For example, searching for the keyword “Internet” would retrieve numerous questions that are specific to several current technology development efforts within Comerica. Other question groups may be centered around business lines, such as Demand Deposit Accounting.
Questions are also categorized according to their focus, expediting retrieval and forming an infrastructure for the final business requirements documentation. As demonstrated in Exhibit 2, current categories include background, scope, product, organizational and operational impact, government/regulatory, delivery channels, delivery channel—interfaces, infrastructure/security, testing, training, help desk and project estimate. These categories will likely change over time.
Questions within this repository must be applicable to multiple projects and thus, are reviewed by a Questions Committee before being approved for inclusion. This Committee will validate questions for appropriateness, prohibit redundancy and ensure wording consistencies. The addendum at the end of this paper outlines some of the key questions within the repository.
The Project Database serves as the activity center of the R.O.E. System, housing all open projects and providing the necessary functionality to initiate and organize requirements collection efforts. Key activities performed within this database include the following:
• Project Maintenance: Provides the ability to add, copy or delete projects. New projects are automatically populated with required questions from the Questions Repository.
• Questions/Response Maintenance: Allows Project Managers to control the questions and response process for each project. Optional and/or Group Questions may be obtained from the Questions Repository. Also, new questions that are not included in the questions repository may be created for the specific project. Once questions are obtained/created, they may be electronically assigned to project staff via automatic email notification; each question may be assigned to one to nine individuals. Finally, once responses are received and reviewed for approval, answers may be accepted by the Project Manager.
• Business Requirements Maintenance: Provides for automatic creation, review and approval of the final Business Requirements documentation. After the Business Requirements document is successfully approved, the Project Manager marks the Business Requirements document as completed. At this point, the business requirements are frozen and no more changes may be made to the document.
Comprehensive navigational tools provide various views to access and monitor open projects within the database. As displayed in Exhibit 3, buttons along the left side of the screen offer views according to the role the user performs within the project. A toolbar across the top of the screen allows the user to access help screens or perform maintenance functions for the project, questions/responses, or business requirements final documents.
Project Archive Database
After a Business Requirements document has been approved and completed for three months, it is automatically moved to the Archive Database. Currently, Comerica retains these project files indefinitely. In addition to serving as a permanent record of the project's business requirements, this database provides a source of completed projects that may be copied and modified for similar initiatives in the future.
R.O.E. System Development Challenges
Several challenges were confronted during the R.O.E. System development process. Many of these issues were incurred because of the relative newness of Project Management methodology within Comerica initiatives. Given that financial services institutions tend to be reasonably immature users of Project Management practices, these types of issues are likely to be experienced in similar efforts at other banks, insurance companies and brokerage firms.
Defining “Business Requirements”
Given the vast quantity and types of projects initiated and managed within Comerica, obtaining consensus among the R.O.E. Management Team concerning the scope of this project was difficult. It was finally agreed that the “Business Requirements” collected within the initial launch of the R.O.E. System would be limited to technology development issues. Other categories of requirements could be represented in later enhancements of the tool.
Project Management Process Changes
As with most financial services companies, Project Management is gaining recognition and acceptance across Comerica. Consequently, related processes and policies have become moving targets. For example, managing the scope of the R.O.E. System Development in this transforming environment was a significant challenge. Although some scope changes were deemed necessary, others were targeted to be considered as future enhancements. Similarly, controlling congruence and timing of the tool within the changing processes often impacted key components within the R.O.E. such as question design.
Questions Repository Content and Organization
Maintaining appropriateness and applicability of the questions in the repository, especially during periods of change within Project Management Processes, proved to be one of the most challenging aspects of the R.O.E. tool development. While populating the repository, the project team struggled to represent the appropriate language and detail within the questions. Similarly, distinguishing between mandatory and optional questions was difficult. Mandatory questions, which are automatically added to a new project, can add structure and consistency to the business requirements. Conversely, too many mandatory questions can be burdensome and excessively time consuming to answer. Questions Development Guidelines ensure the proper balance of content and organization. Additionally, “group” questions may be more directly applicable and thus, useful, to various types of projects.
Corporate Acceptance and Understanding
By far the most challenging aspect of the R.O.E. System Development was attaining the acceptance of both I.S. and client users of the product. Product training was designed to ensure users understood what the product could accomplish, how it worked, who should use it, and when it should be used in the project lifecycle. Additionally, the R.O.E. System Development project had to entertain a marketing effort to explain why the product should be inculcated into future technology development projects. For many clients who did not fully understand the benefits of comprehensive project planning, this tool was considered a significant demand of time and resources with questionable end value. Thus, an ongoing education process is needed to demonstrate the value of compiling complete and accurate business requirements in the planning phases of technology development projects.
The Future R.O.E. System of Comerica
Several enhancements are planned for the R.O.E. System in the next few years. Some are cosmetic in nature, while others focus on improved functionality and application. Examples include the following:
• Create additional filters on database views.
• Expand functions that improve the efficiencies of collecting business requirements. For example, develop a tool that allows multiple questions to be answered with the same response.
• Extend usage to other phases in the technology development life cycle. For example, once business requirements are collected and approved, this information could be electronically applied to create the detailed requirements and design.
• Enhance the scope of the product to collect other, nontechnical business requirements such as real estate standards and support staff training needs.
Other future changes may be demanded by environmental and cultural shifts as Comerica gains acceptance and utilization of Project Management standards. Generally, R.O.E. System enhancements will be an ever-greening process that will reflect the ongoing needs and expectations of the Project Management community.
The R.O.E. System has brought consistency and accuracy to the process of collecting and approving business requirements for technology development projects. It reflects the willingness and desire of Project Managers within Comerica to embrace and implement the Process of Project Management in its entirety and thus, represents another step up the rung toward Project Management maturity within the financial services sector.
Listed below are some of the questions that were included in the questions repository.
Examples of Questions Typically Answered by the Business Client
• Who (i.e., division/department/region) is sponsoring the project?
• What is the potential benefit from this project? Cost reduction? Cost protection? Revenue generation?
• Will this increase or reduce staff? Note position(s), how many, and where. Is this a single project in a multi-phase program? If so, can you describe the program objective?
• Describe the deliverables for this project. Is there an existing project/product similar to this request?
• What's most important: quality of the function, time to market, or cost?
• Is there a deadline for this project? What is driving it? What is the date? Supply background information.
• What is the forecasted growth (customers, accounts, and/or transactions) over the next three years? This may be indicated as percent of growth over current volume.
• Will the overall project be managed through a client area or IS?
• Are there potential vendor solutions identified? If so, what is your familiarity or confidence with the vendors? Has a functional and/or technical product review been conducted? Has contract negotiation occurred? If yes, please supply supporting documentation.
• Describe and quantify the business objective.
• Will this project create a new function or process?
• Will this project replace or enhance an existing system or function?
• Will this project replace a current manual process?
• What changes, if any, are there to policies or procedures which require IS support?
• What kind of project is it? (Infrastructure, conversion, deconversion, relocation, acquisition, government/regulatory, or proof of concept?)
• Who are the internal clients of the product? Who are the external customers of the product?
• Is it a national product or service, or is it specific to an affiliate, geographic location, region, market segment, or specific customer?
• Does this product have any foreign/international implications? If so, describe.
• Might the project be expanded to additional markets or areas at a later date? If so, when and where? Is that expansion in scope, or out of scope for this project?
• What business units will be involved in this project?
• What other products or services are affected by this initiative?
• With what other areas will it be interfaced? For what purpose?
• What is the anticipated life of the product or service?
• What information can you provide to further identify what is out of scope?
• Will any type of unique rollout plan be required? If so, describe.
• Define acceptance criteria for project completion.
Organization and Operational Impact
• What are the internal operating unit or department impacts?
• Will there be an operational need to perform new functions? If yes, describe. Include information on expected hours of service.
• Do you foresee manual intervention for the day-to-day processing of this service and/or product?
• Will any operational functions or applications be consolidated or separated as a result of this service, product, or function? If yes, describe.
• Will the function be supported centrally, or will it be decentralized?
• What are the operational service level agreements needed to deliver the service to the internal client and/or external customer?
Examples of Questions Typically Answered by I.S. Representatives and/or the Business Client
• What are the sources of input, methods of receiving input and the frequency of input? Specify when/how often.
• What, if any, existing data or information needs to be imported and/or made available from another source? Will this be needed once at start-up, or on a continual basis?
• Are there any interfaces to other systems, hardware, software, packages, facilities, etc.?
• If data is to either be sent or received from another source, are there any timing considerations to include in the design?
• Are there any known industry standards (i.e., file formats) to follow? What are they?
Infrastructure and Security
• Does this project fit into existing systems or processes, or will new software/hardware be required?
• What functional areas of the system are impacted? If multiple, list all.
• Is a specific release level of the system required? If so, what release?
• Has a solution already been determined, or an outside package purchased? If so, what are the vendor requirements in terms of hardware, communication, database, development language, etc.? Has the Standards and Architecture Group approved the selected solution? If a package is already selected, attach Request for Proposal.
• Is the solution to be internally or externally supported by a third party vendor?
• Will new files/data be required? If so, estimate volume and growth rate (i.e., new accounts/customers).
• Should a review of information extracts be done as part of the scope of this project? Describe high-level requirements.
• What areas will need access? Consider geographic locations and whether access is for bank personnel, vendors, or customers.
• How many (approximate ranges) clients/customers will access the system?
• Are there special requirements for customers/vendors in areas like hardware, operating systems, or communication devices in order to access the system?
• Will remote access be required by vendors, customers, or others?
• Will the project require Internet, intranet, private network access, or all?
• Will it interface to other platforms and/or systems? Real-time or batch?
• What are the requirements for system availability and service levels, performance, and response time? Are any of them required from an outside source?
• What are the forecasted workloads and peaks (i.e., daily, weekly, monthly, daytime, nighttime, etc.)?
• What drives the equipment location? What, if any, are the special equipment requirements?
• Will the project require the relocation of computer equipment, telecom, etc.?
• What are the required communication protocols (i.e., TCP/IP, IPX, SNA, FTP, Z modems)?
• Will the project require any special software for networking hardware?
• Will the project require any special development tools?
• Will the project utilize any proprietary network protocols?
• What different levels or types (i.e., primary, secondary, administrative, approval, etc.) of security will be required?
• If a package, describe the security subsystem within the package. Does the delivered package security integrate with our current security? Does the delivered package security conform to corporate security policy? If not, define the exceptions.
• Is there sensitive data that needs additional security?
• Are there additional security devices required to secure data or to access?
• If encryption is required, describe.
• Is a disaster recovery hot site required?
• What are the backup/retention requirements for the data?
• Will ongoing maintenance/upgrades to hardware/software be required? How often?
Examples of Questions Created for a Specific Group of Projects
• Is a new product being offered or an existing product being changed. If this is a new product, will it replace an existing product?
• What product(s) are impacted?
• Is there an existing product that can be used as a model? If so, what is the product? In general, describe the differences.
• Define any 3270 screen requirements. Identify number of new screens, number of screens changed and, in general, type of data on screens.
Deposits—Demand Deposit Account
• Define the following account criteria: interest or non-interest bearing, service charge type code, interest code, product name/description.
• Define the following fee structure criteria: frequency, amount, defined by market or balance method, new fee, waivers allowed?
• Are Demand Deposit Account Statements or Notices impacted?
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA