IN PHYSICS, when mass and velocity approach infinite values, the observed dynamics change and basic principles must be redefined. This is also true in the science of project management.
Certain general principles of good project management have become second nature to IT professionals in every major industry: Process decisions with those closest to the work. Getting things right the first time saves time and money in the long run. Form follows function. These are principles drawn from project experience in the defense industry as well as from research in design theory and from total quality management models; principles we use to identify the key drivers in critical design decisions. They have become integral components of Systems Development Life Cycle (SDLC) work done by professional project managers everywhere.
Then there are other principles that we intuitively know to be true and which resonate with our observations when we see a project “go south”: Front end users couldn't integrate the software into their work flow. Redesign and rework generated huge cost overruns and delayed delivery by years. The screen design didn't follow the data capture form.
But a new dynamic emerges when cycle time compresses to months or even weeks instead of years, when the half life of the work technology shortens considerably and when the scope of projects becomes enterprisewide. Managers confronting this new dynamic need to question the applicability of their basic principles and formally modify design decision processing.
Three Mutable Principles
Teams comprised of business users and systems analysts close to the work can take weeks or months to achieve consensus on critical decisions. They rarely have the perspective necessary to gore their own ox in the interest of the organization at large.
In an enterprisewide project, system design decisions that are related to business processes generally have broad effects upon organizational units with strong competing interests. Enterprise projects create win/lose situations demanding an effective framework for issue resolution. These situations require that decisions be made by executives with authority or by a high-level, cross-functional group charged with the specific task of acquiring decisions just in time to keep the project on schedule.
When projects touch the whole company and product cycle time is critical, call for votes with incomplete information. Getting some tasks done wrong is part of getting all tasks done.
Internal customers accept this situation only if critical decisions are made at a high level. Senior management must own the operational repercussions of expediency. Some high-profile examples:
Motorola has a reputation for high-quality engineering design; consequently its beepers have outlived the market demand for their simple feature set. Rapid technological development is supplanting the old product with new pagers capable of full text messaging. These new units are quickly rendering a well-engineered and still reliable product obsolete.
At one time, buying a Mercedes might be justified by the supposition that the car would still be reliable in 15 years. Today many would question the wisdom of driving around in a car without air bags. The half-life of technology has reached the point where sometimes “good enough” is not bad.
The concept of “just in time” materials delivery can be broadened to address the notion of “just enough quality” engineering. The role of senior executives is to make the tough calls and move on. Microsoft appreciated this when they released Windows 95 to the market while reviewers were assessing it as “not ready for prime time.” Early release was better than risking market share, and most of the market was satisfied with the quality of the product; improvements can come with time.
Sometimes, function must follow form; business practice must be reconciled with system capabilities.
Some valuable business processes are incompatible with vendor-supplied software. In industries where broad standard practices have not yet evolved, where market demand and supplier dynamics are highly volatile, and where integrating information systems can provide strategic advantage, no vendor package will accommodate the best practices of every business unit. With trends in the health care industry, for example, leading organizations away from home-grown systems development, vendor product customization can be a schedule killer. Here's a case in point.
A Tale of Two Systems
The merger of Harvard Community Health Plan (HCHP) and Pilgrim Health Care (PHC) resulted in a 1 million-member health care delivery system that combined the three major models of managed care under one umbrella organization, Harvard Pilgrim Health Care (HPHC). The combined HPHC provider network provided its members access to a staff model HMO with 20 owned and operated health centers, a group model HMO with a broad mix of exclusive and nonexclusive medical groups, and an Independent Practice Association (IPA) consisting of a network of 12,000 community-based physicians.
Exhibit 1. Combining the out-of-date information systems of two large HMOs into one created an IS architecture that was inelegant at best. Platform consolidation was imperative, and on a timetable that approximated warp speed.
Exhibit 2. The first-round solution to the merger of the two information systems was an example of fitting the foot to the shoe: through a complex web of interfaces and software overlays, it created the appearance of integration with the external business environment but preserved existing legacy infrastructure.
The newly merged organization and its information systems had to support three different provider payment mechanisms:
Under the staff model, physicians are paid a fixed salary as employees of the company
Group model providers are paid prospectively via capitation, a mechanism whereby physicians receive a fixed dollar amount on a per member/per month basis to provide all care.
IPA doctors are reimbursed under a budgeted fee for service agreement such that they receive payment for each service rendered with a percentage of that payment being withheld pending the achievement of mutually agreed upon total dollar targets.
These three very different payment mechanisms require very different support capabilities in their insurance information systems. At the point of the merger, the information systems architecture supporting the total business was anything but elegant, as Exhibit 1 illustrates.
Because of the complexity of managing and maintaining multiple insurance information processing systems, HPHC initiated a major information technology (IT) initiative to integrate their systems in concert with the integration of its products and business operations. Significant benefits were anticipated. Sizable cost savings would be realized with the consolidation of information system platforms and the standardization of business practices. Real quality improvement could be achieved via the enhanced ability of HPHC to respond quickly to its customers' needs for flexible and efficient access to products and services. And platform consolidation would greatly increase the integrity and value of data by improving the ability to collect, analyze and report on all aspects of the financing and delivery of care.
Exhibit 3. By integrating teams from Product Integration and Systems Integration, a new and streamlined solution was created. Although it turns conventional wisdom on its head by allowing function to follow form, the solution was attractive for the potential speed of implementation.
Exhibit 4. A task force of over 100 managers and staff met to determine if there were any aspects of the proposed solution that would compromise patient/employer service, jeopardize the financial health of the organization, and/or prevent HPHC from meeting regulatory requirements. In the absence of any such deal-breaker issues, the decision was made to proceed with the systems project.
Newtonian Design. Initially, HPHC organized this project around its business structure, assigning the tasks of integrating products to the vice president for product integration and of integrating systems to the CIO. Two separate project teams were organized to assume responsibility for meeting the organization's goal of integrating within 12 months. The teams quickly formed subteams with front-line business users to articulate a product design. Subteams focused upon primary business functions: Enrollment/Billing (E/B), Customer Services, Claims Services, Provider and Network Services, Medical Services Management, Marketing and Sales, and Rates, Underwriting and Reporting.
Six months post-merger, the Product Integration Team (PIT) had assimilated a vast amount of information about legacy products and business practices but hadn't produced a clear definition for a portfolio of new products. Subject matter experts from the various business areas carried significant responsibility to preserve practices that had proven effective and valuable. Achieving consensus for a new product development vision by attempting to integrate bottom-up was proving extremely difficult and time consuming.
During the same time period, the Systems Integration Team (SIT) had achieved a concept definition and product design. They succeeded in addressing the stated needs of all business constituencies by building a virtual box around all existing systems, thus leaving business practices intact and requiring little change on the part of front-line systems users. The IT department assessed that they had achieved an optimal solution in that they had found a way to deliver all the functionality that business representatives requested. Business units assessed that all valuable business practices had been preserved.
The design that achieved these goals called for the construction of a complex web of interfaces and software overlays that created the appearance of integration with the external business environment but discretely maintained all existing capacity by preserving the legacy infrastructure. (See Exhibit 2.)
The CEO and senior management perceived two major drawbacks to this solution: It took twice as much money as they wanted to spend, and the time frame for implementation doubled the optimal target for capitalizing on the strategic advantage of the merger. The market environment in health care, like most industries, is forcing companies to be singularly resolute about reducing costs and shortening product cycle times. Six month's work using traditional methodologies was dismissed by senior management as unacceptable. The PIT and SIT were asked to reassess alternatives.
Warp Drive Decision Processing. Deciding that the most expedient way to realize the value of the merger was to focus HPHC's efforts on integrating the product portfolio, the CEO restructured the company's work by integrating the resources of the IT and Product Integration departments.
The teams (PIT and SIT) collaborated to identify solutions with potential for achieving aggressive deployment of an integrated product. Systems experts from the two teams reviewed options that had been rejected earlier because of their impact on business operations. These solutions were evaluated as to their capacity to support the goals for an integrated product from the patient and employer group customer perspective.
A premise set forth by the CEO was that staff and providers are motivated to change and adjust, not patients and employers. That the job of the organization was to respond to the market even if that meant losing systems support for key business processes that offered demonstrable and significant value to the organization, e.g., the ability to administer customized capitation contracts. The purpose and result of the CEO's directive was to turn around the standard method of system design. Instead of designing the system around the business operation, PIT and SIT were to find a software solution that would accomplish fundamental business goals, then determine if the enterprise was capable of redesigning business operations to support new products using that solution. Essentially, function would follow form.
Deal-Breaker Analysis. Taking advantage of six months' experience working on integration issues, PIT and SIT quickly determined the four most likely options for an integrated product systems solution. They presented their work to the CEO and a group of senior managers determined to be the major stakeholders in the systems decision. In concurrence with a recommendation from the PIT/SIT representatives, the senior managers selected the option most likely to succeed: Use the vendor software currently supporting the legacy PHC products and bring up new HMO products on new hardware with dedicated servicing units. The high-level concept was to implement a virtual company within a company; (See Exhibit 3.)
The PIT/SIT was then empowered by the CEO to convene a large task force of business operations experts. The team's charge was to spend one week with over 100 managers and staff from across the organization. Their goal was to identify any deal breakers in the proposal. The task force was divided into five teams, each identified with a major business process: Claims; Enrollment/Billing and Member Services; Provider Contracting and Network Issues; Referral and Authorizations; and Reporting.
The teams were to look for deal-breaker issues resulting from the implementation of the solution. They were to assume that manual work-arounds to currently automated processes were acceptable to preserve customer and patient satisfaction. Any business practice was questionable if it was incompatible with the software solution.
Deal-breaker issues were anything that compromised patient/employer service, jeopardized the financial health of the organization, and/or prevented HPHC from meeting regulatory requirements.
Exhibit 5. The Product Integration Team developed a process to acquire critical decisions for systems configuration. To process timely, definitive decisions that could simultaneously be communicated to the Systems Integration Team and business operations staff, PIT formed the Systems Issues Resolution Committee (SIRC).
Members of the SIT/PIT led the process teams through their analyses. Results of the week-long exercise were presented immediately at meetings attended by the CEO and senior managers representing affected business units. A final meeting was held to review a budget prepared by the CIO for the solution implementation. Since no substantive deal breakers were identified, a decision to proceed with a systems project that had major implications for the entire organization was made in just three weeks. (See Exhibit 4.)
The decision to proceed was based in great part on the CEO's faith that staff could achieve goals in the face of significant barriers and uncertainty IT was implementing a system with important business decisions yet to be made and most operations processes undefined. The project required a just-in-time mechanism for the delivery of configuration and design decisions necessary to set up the Integrated Systems Environment (ISE).
The PIT became the clearinghouse for business information. They developed a process to acquire critical decisions for systems configuration. To process timely, definitive decisions that could simultaneously be communicated to SIT and business operations staff, PIT formed the Systems Issues Resolution Committee (SIRC). (See Exhibit 5.)
The SIRC consisted of six PIT representatives with cross-functional experience and expert knowledge in claims, clinical operations, provider contracting, information systems, health benefits and general insurance functions; one SIT project manager; and one documentation specialist.
SIT documented each configuration issue needing resolution (nearly 200). Issues were brought to twice-weekly SIRC meetings. SIRC ensured each issue was appropriately and accurately articulated. Each was assigned to a SIRC subject matter expert who would reach out to the PIT team and other major stakeholders for feedback. Once compiled, the feedback was discussed and deliberated upon by SIRC. Draft resolutions were then circulated to one or more contact groups for review. These contact groups included Claims, Enrollment/Billing, Finance, Delivery System Leadership, Marketing, Medical Directors' Office, Medicare, Member Services, Provider Contracting, and Sales.
SIRC selected the contact groups to review drafts for a given resolution based upon the strength of a group's stake in the issue's outcome. Membership for these contact groups was initially nominated by PIT, reviewed by senior leadership for input and approval, and approved by the CEO.
Comments on draft resolutions were required back within one week. Responsibility fell upon members of each contact group to solicit input from any operations area staff affected by the resolution. The SIRC member assigned to each issue collated all feedback and followed up on all questions. Feedback was incorporated into a revised resolution. If the resolution was substantively changed by the feedback, it was re-circulated in draft form; if the changes were minor, it was signed by the executive champion of the PIT team and circulated as final.
If an issue required a major business change, or broad organizational consensus, or would result in a high impact to project cost/schedule, member satisfaction, or operations design, instead of circulating the draft to a contact group, the issue was referred for Leadership Review by senior leadership or a selected group of executive stakeholders.
If a delayed resolution was affecting the project's critical path, SIRC would consult with the executive champion of the PIT team, determine a resolution and instruct SIT to proceed under the assumption that the resolution would stand. PIT owned responsibility for any rework needed because of incorrect assumptions.
The SIRC decision process worked extremely well to ensure that decisions were made just in time. The project came in on time, under budget, and membership in the integrated products has exceeded all expectations. Membership on all legacy systems will be migrated over time to the Integrated Systems Environment (ISE). Continuous quality improvement processes are being incorporated into the design of IT's operational support plans for all ISE users.
IT DEPARTMENTS ARE MOST often identified as the culprit for information systems projects that don't meet expectations. The larger the scope of a project, the higher the volatility in the business environment, the less likely the culpability of IT. Project managers in IT who have decision processes embedded in their project structure are at high risk for failure because the reliability of those processes decreases as project mass and velocity approach infinite values. Taking IT off the critical path, formalizing decision process outside of the IT management structure, ensures that a project will take full advantage of an organization's capacity to deliver an acceptable percentage of right choices in product and process design. ∎
John kelly is project manager, business operations, at Harvard Pilgrim Health Care in Dedham, Mass. He has been with Harvard Community Health Plan since 1982, and spent the past two years working on project management and decision process as a member of Harvard Pilgrim Health Care's Product Integration Team.