Healthcare.gov – Who is at fault?

Credits: Arsalan Khan, Ed Heironimus, Francis Wisseh, Maryam Moussavi and Udhayakumar Parerikkal

1. EXECUTIVE SUMMARY

This research paper analyzes the Center for Medicare and Medicaid (CMS)’s Healthcare.gov project in detail and makes recommendations on what could have been done differently. The project had 55 federal contractors working on it but this research paper will concentrate on only three. These federal contractors are:

  • CGI Federal who was developing and implementing the Federally-Funded Exchange (FFE). The estimated value of the contract was $93.7 million and it was awarded in December 2011.
  • Optum/QSSI was developing the Data Services Hub that would verify citizenship, immigration status and tax information. The estimated value of the contract was $144.6 million and it was awarded in January 2012. Optum/QSSI was also developing the Enterprise Identity Management (EIDM) that would provide enterprise-wide credentials and single sign-on capability. The estimated value of the contract was almost $110 million and it was awarded in June 2012.
  • Terremark Worldwide, In., (acquired by Verizon) was going to help increase CMS’ Platform-as-a-Service (PaaS) capabilities in the CMS cloud-computing environment. The total estimated value of the contract was $55.4 million and multiple task order were issued until summer of 2013.

The following tables summarize this research paper:

Table 1: Key Inputs

Key Inputs of the Project

CMS CGI Federal Optum/QSSI

Verizon

·      Affordable Care Act

·      States

·      People/Team

·      FFE RFP

·      Requirements

·      Data Services Hub and EDIM RFP

·      PaaS RFP

Table 2: Key Components

Key Components of the Project

CMS CGI Federal Optum/QSSI

Verizon

·      Agile Methodology

·      Project/System Integrator

·      Parallel “stacking” of phases

·      CMMI Level 5 Maturity

·      Agile Methodology

·      CMMI Level 3 Maturity

·      Agile Methodology

·      Data Services Hub Documents

·      EIDM Documents

·      Architecture diagram

·      Security

Table 3: Quality of Project Management – Qualitative View

Qualitative View of Project Management

CMS CGI Federal Optum/QSSI

Verizon

·      Government vs. Private industry projects

·      Test plans and test reports

·      Requirement changes

·      Lessons learned from a state exchange

·      Requirement changes

·      Previous benchmarking and audits used

·      Issue escalation

·      Poor coordination

Table 4: Quality of Project Management – Quantitative View

Quantitative View of Project Management

CMS CGI Federal Optum/QSSI

Verizon

·      HHS Enterprise Life Cycle ·      Highly metrics-driven ·      Use of charts ·      Delayed processing of orders

Table 5: Project Management Successes and Failures

Key Successes and Failure of Project Management

CMS CGI Federal QSSI

Verizon

·      Pressure from White House

·      Lack of business processes

·      Miscalculated costs

·      Various technical options were not considered

·      FFE

·      Changing Requirements

·      Testing

·      Data Services Hub and EIDM

·      Buggy Data Services Hub and EIDM

·      Financial Success

·      Hardware Outage

·      Project Management

Table 6: Lessons Learned

Lessons Learned on Project Management Best Practices

·      Roles and Responsibilities Matrix

·      Full-Time Project Manager

·      Business Processes and Governance

·      Requirements Management

·      Communications and Sharing

·      Metrics and Measurements

·      Methodologies and Documentation

Table 7: Recommendations

Team Recommendations

Project Design

Project Implementation

·      Project Manager

·      Cross-Functional Team

·      Team Satisfaction Survey

·      Pilot Approach

2. INTRODUCTION

The Affordable Care Act (ACA) is the nation’s healthcare reform law enacted on March 23rd, 2010. Under the law, a new “Patient’s Bill of Rights” gives the American people the stability and flexibility they need to make informed choices about their health. There were numerous reasons why healthcare reform was critically needed in the United States, including:

  • High health insurance rates and lack of coverage by many: In 2013 the Congressional Budget Office (CBO) estimated that 57 million Americans under the age of 65 are uninsured; representing 1 out of 5 in the population.
  • Unsustainable healthcare spending: Healthcare spending represented 17.9% of the nation’s Gross Domestic Product (GDP) in 2011.
  • Lack of emphasis on prevention: 75% of healthcare dollars are spent on treating preventable diseases, however only 3 cents of each healthcare dollar goes toward prevention.
  • Healthcare disparities: Healthcare inequalities related to income and access to coverage exists across demographic and racial lines.

On October 1st, 2013 Healthcare.gov went live as part of the technical implementation of the ACA reform to help Americans buy healthcare insurance, however the release was an astronomical failure. The cause and contributing factors that led to issues with this project are explored in detail. Focus is placed on looking at CMS’ capabilities from a Project Integration and Project Management perspective. Additionally, our analysis will assess the role of the major Federal contractors in the project. Examples are included to show how contributing factors such as scope creep, schedule constraints and lack of adequate testing led to a website which provided an inadequate customer experience.

This research paper provides a descriptive review and analysis of the Healthcare.gov project. During our analysis, we used Kathy Schwalbe’s (2014) Three-Sphere Model for System Management which entails organizational, business and technological perspectives of Project Management. We utilize these perspectives to determine what went wrong with the Healthcare.gov project from the Federal Government, CGI Federal (contractor), United Healthcare QSSI (contractor) and Verizon (contractor) points of view.   Furthermore, building on these unique perspectives, we analyzed the stated objectives and real implications of the project, the quality of the project management from a qualitative and quantitative perspective, key successes and failures factors, key lessons learned, project management best practices, and recommendations for what might have been done differently.

3. BACKGROUND

In order to set the context of the research paper, we have to understand what the CMS does, what the reason for the Healthcare.gov website is, and why the on-time completion of the website was a priority. Additionally, we will look at the key inputs, components and deliverables of this project.

3.1 About CMS

According to the www.CMS.gov and www.hhs.gov/about/foa/opdivs/index.html websites, CMS is one of the operational divisions of the Department of Human and Health Services (HHS). CMS is responsible for providing oversight on the Medicare and Medicaid program, Health Insurance Marketplace and related quality assurance activities. It has 10 regional offices with its headquarters in Maryland. The Administrator for the CMS is nominated by the US President and confirmed by the Senate. Figure 1 (Priorities, 2014) below shows CMS’s 2013 budget that accounted for 22% of the entire US Federal Government Budget.

federal-budget-distribution

Figure 1: Federal Budget Distribution

 

3.2 Why CMS was given the project?

CMS was designated as the chosen one by the Obama administration for obvious reasons. As discussed earlier the purpose of the ACA was to enable all Americans with the ability to buy health insurance. We also defined the CMS as an organization which provides healthcare to the elderly, disabled, and those who are not financially capable of buying healthcare. Healhcare.gov project began as a sub agency under HHS called the Center for Consumer Information and Insurance Oversight (CCIIO). This office’s charter was to support a successful rollout of the ACA. In 2011, the secretary of HHS, Kathleen Sebelius “Citing efficiency gains…” stated that the CCIIO would be moved under CMS (Reichard, John. Washington Health policy Week in Review Sebelius Shuffles Insurance Oversight Office into CMS, Shifts CLASS Act to Administration on Aging. January 10, 2011). The Obama administration insisted this was a way to control IT costs and leverage economies of scale through existing investments and infrastructure.   The Republican opposition believed this was another example of “…resources being diverted from seniors’ health care to be used to advance the Democrats’ new government-run health care entitlement” (Reichard, John. Washington Health policy Week in Review Sebelius Shuffles Insurance Oversight Office into CMS, Shifts CLASS Act to Administration on Aging. January 10, 2011).

3.3 About the Federal Contractors and their relationship with the CMS

3.3.1 CGI Federal

CGI Group Inc., a Canadian company acquired American Management Systems (AMS) in 2004 to enter the U.S. Federal Government market. Due to this acquisition of an American Federal contractor by a foreign entity, there was a “firewall” created so that CGI Federal (formerly called AMS) could continue to work on Federal contracts. This “firewall” entailed that CGI Federal would not share Federal client information with CGI Group Inc. thus CGI Federal became a wholly owned subsidiary of CGI Group Inc. This acquisition proved to be very lucrative for CGI Group Inc. CGI Federal became one of the most profitable business units due to the Healthcare and Human Services division. This division provides IT services in the areas of provider-based services, public health surveillance, portal integration, security, enterprise architecture, service orientated architecture, business intelligence and applications development.

On September 2007, CGI Federal, among 16 other Federal contractors was awarded the Enterprise Systems Development (ESD) Indefinite Delivery Indefinite Quantity (IDIQ) contract by the CMS. The purpose of the ESD IDIQ was to support CMS’ Integrated IT Investment & Systems Life Cycle Framework and various IT modernization programs and initiatives. Although there were no task orders issued under this contract at the time but it kept the door open for future task orders to the 16 contractors.

The Healthcare.gov project was competitively bid under the ESD IDIQ. This bid resulted in four contractors becoming the finalists. Out of those four contractors, CGI Federal was selected in September 2011 as the awardee based on “best value”.

3.3.2 Optum/QSSI

Founded in 1997, Quality Software Services Inc. (QSSI) is an established Capability Maturity Model Integration (CMMI) Level 3 organization with a proven track record of delivering a broad range of solutions with expertise in Health IT, Software Engineering, and Security & Privacy. Based in Columbia, MD Optum/QSSI is a subsidiary of UnitedHealth’s Optum division and was acquired by Optum in 2012.

Optum/QSSI is privately held with about 400 employees and collaborates with both the public sector and private sector to maximize performance and create sustainable value for its customers. In its 15 year existence, the company has cultivated a process driven, client focused method of IT solution development, which, has solidified its reputation as a capable IT partner in both the federal and commercial marketplace. In the federal landscape, Optum/QSSI has established itself as an industry in the field of Health IT and this reputation was key in the company’s selection as a federal contractor for Healthcare.gov.

3.3.3 Verizon

Terremark is now a Verizon company, dedicated to combining the strongest cloud-based platform with the security and professional services that are necessary to conduct today’s enterprise and public sector business across the next-generation IT infrastructure. At the center of Verizon’s capabilities is its enterprise-class IT platform, which combines advanced IT infrastructure with world class provisioning and automation capabilities which is what CMS leveraged in this case. Verizon’s standards-based approach fully aligns with today’s enterprise business requirements driven by agility, productivity, and competitive advantage.

Verizon Terremark was a natural fit at the CMS through a long standing relationship. Verizon manages and maintains the entire HHS Wide Area Network (WAN) along with ancillary services such as security services, mobile solutions, and unified communications. Verizon also developed a homegrown fraud detection service it used to identify toll free fraud to pursue Medicare and Medicaid fraud saving the agency millions.

3.4 Key Inputs of CMS

For the Healthcare.gov project, we identified the following key inputs for CMS:

  • Patient Protection and Affordable Care Act (ACA): The ACA became law on March 23rd, 2010 under the Obama Administration. The legislation was passed to address various consumer health insurance purchase issues such as denial of coverage due to pre-existing conditions, stopping of coverage if patients became sick, lifetime benefit limits and access to affordable healthcare. The ACA mandated the creation of “exchanges” that would be used by consumers to compare and buy a Qualified Health Plan (QHP) based on their state of residency, income level, age and other factors. These exchanges could be created at the state level or at the federal level. If states decide not to create their own exchanges then they would have the option to redirect their constituents to the federal exchange to buy healthcare insurance.
  • States: The various states and Washington D.C. informed CMS if they intend to create their own exchanges or they would utilize the exchange developed by the Federal government. States also had the flexibility to utilize the federal exchange when they wanted and thus initially 26 states opted to have their constituents go to the federal exchange to purchase healthcare insurance.
  • People/Team: CMS assigned a part-time Project Manager to the Healthcare.gov project.

3.5 Key Inputs of Healthcare.gov for Federal Contractors

The Healthcare.gov project is one of the most complex systems in recent times. The project entailed 55 contractors working on various aspects of the system. These contractors were responsible for the creation of a robust network/infrastructure, the development of a website front-end, the Federally-Funded Exchange (FFE), the Data Hub and the EIDM. Additionally, this system receives eligibility and verification information from various other federal government agencies as the consumer fills out the online form. The following figure (Ariana Cha, 2013) below shows the complexity of the information flow of the entire system.

Healthcare.gov contractors and agencies processes.png

Figure 2: Healthcare.gov contractors and agencies processes

3.5.1 CGI Federal

CGI Federal was one of the prime contractors for the Healthcare.gov project. It had the following key inputs:

  • Request for Proposal (RFP): An RFP was one of the first key inputs for the Healthcare.gov project. It required the establishment of a FFE that would be used for eligibility and enrollment, plan management, financial management, oversight, communication and customer service. The following Figure (Desai, 2013) shows the FFE Concept of Operations:

ffe-concept-of-operations

Figure 3: FFE Concept of Operations

  • Requirements: After the contract was awarded, first the CCIIO and then various other representatives within CMS provided requirements to CGI Federal for the FFE. These representatives came from policy, legal and Office of Information Services (OIS).

 

3.5.2 Optum/QSSI

  • Request for Proposal (RFP): This was the primary input for the project. It required the development of a data services hub for information exchange and the EIDM for user account registration.

3.5.3 Verizon

  • Request for Proposal (RFP): One of the first RFPs released in 2010 was for the infrastructure and essentially Platform as a Service (PaaS) for the ACA as dictated in the 2010 RFP. A Cloud Solutions Executive for Verizon Terremark said Verizon received an award prior to the additional contractors involved. Following the award, CGI Federal and others were asked to develop the system to conform to the Verizon environment.

3.6 Key Components of Healthcare.gov for CMS

  • Systems Development Methodology: A presentation from April 2012 by CMS’ OIS shows that an “Agile” methodology was used for the Healthcare.gov as shown in the following figure (Services, 2012).

cms-agile-methodology

Figure 4: CMS Agile Methodology

  • Project/System Integrator: CMS took on the role of “system integrator” to manage all 55 contractors.
  • Implementation Consideration: A McKinsey report shows the parallel “stacking” of all phases for this project as shown below (CMS, Red Team Discussion Document, 2013):

mckinsey-report-for-cms

Figure 5: McKinsey Report for CMS

3.7 Key Components of Healthcare.gov for Federal Contractors

3.7.1 CGI Federal

  • Process Methodology: Patrick Thibodeau indicates in a Computerworld article that CGI Federal attained Capability Maturity Model Integration (CMMI) Level 5 maturity making it only the 10th company in US to achieve this level. By extension we can assume that CGI Federal brought the best practices of CMMI for the Healthcare.gov project.
  • Systems Development Methodology: Based on Federal contracting experience, the Federal contractor would either have their own development methodology or they would use the development methodology of the client (CMS in this case). Research indicates that CGI Federal used an Agile methodology to develop the FFE.

3.7.2 Optum/QSSI

  • Process Methodology: As a CMMI Level 3 organization, Optum/QSSI has a reputation for process driven and client focused methods of IT solutions development. Based on our research it is evident that the company implemented CMMI best practices on the project.
  • Systems Development Methodology: According to a senior analytics consultant with a major health provider who worked on the project, Optum/QSSI used an agile development methodology similar to the one depicted below (Group, 2014) based on iterative and incremental development with continuous visibility and opportunity for feedback from CMS.

agile-methodology

Figure 6: Agile Methodology

  • Requirements Documentation for Data Services Hub: The Data Services Hub is a central function of the federal exchange which connects and routes information among trusted data sources including Treasury, Equifax, Social Security Administration (SSA) etc. Inputs from CMS which changed in late September 2013 to allow for an account creation before shopping for health plans.
  • Requirements Documentation for EIDM: EIDM enables healthcare providers to have the ability to use one credential to access multiple applications, serving the identity management needs of new and legacy systems. Inputs from CMS which changed in late September 2013 to allow for an account creation before shopping for health plans.

3.7.3 Verizon

  • System Architecture Design: There was an architecture diagram and overall design for the entire system that lost effectiveness due to a lack of accountability to ensure each component was delivered.
  • Security: Security was a huge component within the requirements for infrastructure, and Verizon Terremark offered a highly secure architecture designed to meet all of the critical compliance and certification requirements. Verizon had been audited against FISMA to the moderate-level and NIST 800-53 for federal customers. Verizon was also asked for advanced security options on the platform such as intrusion detection/intrusion prevention (IDS/IPS), log aggregation, and security event management.

3.8 Key Deliverables for CMS

  • Website: A website that should be able to provide residents ability to compare QHPs.
  • Exchange: A website that should enroll residents by verifying their eligibility based on income level, age and other factors.

3.9 Key Deliverables for Federal Contractors

3.9.1 CGI Federal

  • FFE: A fully functional FFE would be ready to go-live by October 1st, 2013. The FFE would be the backbone of Healthcare.gov and would seamlessly integrate with the website, the data hub and the EIDM.

3.9.2 Optum/QSSI

  • Data Services Hub: This system of Healthcare.gov determines eligibility for financial help. It sends customer data to various government agencies (VA, DHS, Treasury, etc.) to verify eligibility.
  • EIDM (Proof of Identity): Upon account creation, this system verifies identity with Experian. The system also enables healthcare providers to have the ability to use one credential to access multiple applications, serving the identity management needs of new and legacy systems.

3.9.3 Verizon

  • PaaS: Fully operational infrastructure which provides servers and hosting for the Healthcare.gov exchange.
  • Environmentals: Supports power, connectivity, and memory requirements for the environment.
  • Service Level Agreement (SLA): Rolling out the infrastructure in a timely fashion, offering and executing upon SLA’s required by the Government among other things.

4. ANALYSIS

4.1 Project Management Quality of CMS

4.1.1 Qualitative

  • Quality Planning:Quality planning for government releases is at a different scale than quality planning for private companies.  Many factors come into play such as redistributing of the resources through regulation, subsidization, and procurement. As part of CMS’ quality planning phase, the main scope aspects were functionality, features, and system outputs.  However, performance, reliability and maintainability suffered heavily due to time constraints as October 1st, 2013 was the hard deadline.
  • Quality Assurance: CMS used test plans and test reports to insure quality coverage were being met as per the requirements.  The front-end web interface was indeed completed in time.  However, identifying quality system integration was difficult due to the complexity of the back-end sub-systems.

4.1.2 Quantitative

  • Quality Monitor and Control:During the implementation phase, CMS didn’t take proactive measures to address the issues they found one week before launch. Specifically, when the testers reported server crashes at a scale of 10,000 concurrent users. Additionally, CGI Federal had reported more testing is required yet it appeared that CMS was insensitive to their recommendations.  Status reports were supposed to be read, understood and acted upon. HHS followed the Enterprise Life Cycle and CMS was supposed to follow these guidelines.

4.2 Project Management Quality for Federal Contractors

4.2.1 Project Management Quality of CGI Federal

4.2.1.1 Qualitative

  • Quality Planning: As a CMMI Level 5 organization CGI Federal had optimized quality processes to deliver appropriate outcomes for the FFE. However, requirement changes seem to be one of the main issues with the project. Requirements were still being revised until summer of 2013 and kept on evolving even a week before go live. Additionally, the number of states that were going to join FFE increased from 26 to 34 that created another level of complexity in terms of maintaining quality on the project.
  • Quality Assurance: According to Cheryl Campbell, Senior Vice President at CGI Federal, in the Congressional hearings CGI Federal developed the FFE as per the contract requirements. It is interesting to note that CGI Federal was also one of the companies that developed the Massachusetts Health Exchange that was used as a model for the FFE. Hence, we can make the assumption that quality lessons were learned from that project which could have been used for the FFE.

4.2.1.2 Quantitative

  • Quality Monitor and Control: CGI Federal is a highly metrics-driven organization. Each project is monitored and measured according to industry “best practices” and proprietary methodologies. Projects are evaluated based on scope, cost, schedule and other factors to check the health of the project and verify if they are keeping the customer satisfied. But if the requirements continue to evolve then even the best methodologies and measurements are not a match for customers changing their minds.

4.2.2 Project Management Quality of Optum/QSSI

4.2.2.1 Qualitative

  • Quality Planning: As a CMMI Level 3 organization Optum/QSSI had a planned quality process to deliver appropriate outcomes for the Data Services Hub and EIDM project deliverables. However changing project requirements from CMS severely impacted quality planning efforts. For instance, the late requirement change in September that required consumers to create user accounts before browsing the exchange marketplace resulted in higher than expected simultaneous system usage and as a result impacted the functionalities of the EIDM tool which was originally designed to allow consumers to first access the systems, browse the marketplace, and if they wanted a product, create an account. Because the EIDM is only one tool for the federal marketplace registration system, this late requirement change made it impossible to coordinate and plan quality processes with other contractors who worked on portions of the registration system to ensure the appropriate performance outcomes before the go-live date of October, 1st.
  • Quality Assurance: Both the Data Services Hub and EIDM deliverables met quality assurance satisfying CMS’ requirements and all relevant quality standards for the project according to Andrew Slavitt’s, Group Executive Vice President at Optum/QSSI, during his Congressional hearings. It is important to also note that Optum/QSSI developed an EIDM tool for two other CMS systems. This EIDM tool followed benchmarking and quality audits taken from those existing EIDM solutions at CMS.

4.2.2.2 Quantitative

  • Quality Monitor and Control: Requirements changes greatly impacted quality monitoring and control. Although Optum/QSSI used quality control tools such as charts to guide acceptance decisions, rework, and process adjustments, changing requirements severely impacted these controls. These changes introduced time constraint challenges and limited system-wide testing, and most importantly user acceptance testing.

4.2.3 Project Management Quality of Verizon

4.2.3.1 Quantitative

  • Extensive delays in processing orders for additional capacity, provisioning resources, and implementation also caused Verizon a lot of angst with the CMS customer.

4.2.3.2 Qualitative

  • Management within Verizon also failed to run some of the concerns up the executive flagpole to make leadership aware of issues that could have prevented delays or numerous escalations by CMS.
  • Verizon’s project management failed on many accounts. Poor coordination was to blame between multiple project managers assigned to the project within.

4.3 Project Management Key Successes and Failures

4.3.1 CMS

If we review the congressional hearings and documentation, they reveal that the Healthcare.gov project was a high priority project for CMS. In conversations with Federal contractors, CMS would start by saying “this is what the White House wants…”. It is still unclear whether this prefix was used because directions were actually coming from the White House or whether it was just used to indicate the importance of the project. Regardless of the intentions, one thing is for sure that they were not followed by action since there was not a dedicated full-time Project Manager to manage the project from kickoff to implementation. Most likely decisions were made by committees as is often the case with large government projects.

A big piece of the Healthcare.gov project included behind the scenes business processes even before the technology was to be considered. These business processes and governance entailed not only coordinating with 26 states but also with insurance companies. The picture below depicts an exhaustive list of stakeholders that were affected by the project:

FFE Stakeholders.png

Figure 7: FFE Stakeholders

From a business standpoint, CMS failed to calculate in advance the true cost of the entire Healthcare.gov project. Additionally, even after reports by McKinsey indicating a danger of not doing end-to-end testing and warnings from CGI Federal in their August 2013 status report (Federal, 2013) that testing could be an issue, CMS ignored these experts and went full steam in going live on October 1st, 2013.

Research indicates that some COTS products and custom software were developed to standup Healthcare.gov. It also seems like CMS failed to look at the various internal and external “firewalls” the Healthcare.gov system needed to pass through.

4.3.2 Federal Contractors

4.3.2.1 CGI Federal

  • FFE: According to Congressional hearings, the CGI Federal representative indicated that they had provided a fully functioning FFE as per contract requirements by October 1st, 2013. This was their success factor.
  • Changing Requirements: CGI Federal was responsible for developing the FFE. It was put under the spotlight for not providing recommendations holistically for the entire project. It is evident that requirements were changing and new states were being added. But there was no push back from CGI Federal to indicate that the requirement changes would result in quality issues on their end that would affect the entire system.
  • Testing: While the system did work for the initial couple of users but logging delays resulted in a poor customer experience. Research indicates that no end-to-end testing was performed to see holistically how the system would work. CGI Federal could have used their vast amount of industry expertise to inform CMS that no end-to-end testing would result in major issues.

4.3.2.2 Optum/QSSI

  • Data Services Hub & EIDM: Based on Andrew Slavitt’s Congressional hearings on Healthcare.gov, Optum/QSSI successfully developed and delivered a fully functional Data Services Hub and EIDM tools. For example, according to Slavitt on October 1st the Data Services Hub processed over 175,000 transactions and millions more after the project launched.
  • Buggy Data Services Hub & EIDM: In the same Congressional hearings, however, Andrew Slavitt acknowledged that the Data Services Hub and EIDM tools, although worked functionally as designed, experienced performance bottlenecks when the project launched because of the late requirements changes requiring consumers to create accounts before browsing the marketplace. This change resulted in higher than expected simultaneous usage of the registration system and the Data Services Hub eligibility verification tool. Slavitt also admitted to the fact that Optum/QSSI identified and fixed bugs in the EIDM tool days after the October, 1st launch date. The release of code that had bugs was a quality failure and contradicts Slavitt earlier comments about delivering a fully functional EIDM tool.

4.3.2.3 Verizon

  • Financial Success: The primary success story for Verizon was that financially the company did far better as a result of this project than initially predicted based in large part to the scope creep. Additionally Verizon specifically was not the cause for delays or outages on day one of the project and delivered the infrastructure to support the site by launch date. A significant underestimation of capacity would be to blame for the initial failures of Healthcare.gov.
  • Hardware Outage: subsequent failure which Secretary Sebelius cites in her testimony was a hardware outage unrelated to project management (Krumboltz, Michael. Helathcare.gov suffers outage as Sebelius testifies that it never crashed.).
  • Project Management: Key project management failures within Verizon were inherent with the ordering, design or engineering phase, and eventually implementation suffered due to project management inefficiencies. As discussed previously, Verizon had several members of a project management team supporting the CGI Federal relationship, QSSI, and CMS relationships. There should have been one central program manager supported the ACA contract for Verizon. The communication failure through project management teams created bottleneck failures which spread throughout the engineering teams.

4.4 Lessons Learned on Project Management Best Practices

  • Who’s on First: Even though this project needed input from various internal and external stakeholders, a clear roles and responsibilities matrix should have been developed. This matrix should have been used by the contractors to see who is responsible for various activities of this large project and who specifically reach to out to incase they ran into bottlenecks.
  • Project Manager: CMS did not assign a full-time Project Manager for the Healthcare.gov project. For this large-scale project, it would have been prudent to have a full-time project manager responsible for coordinating various activities internally and across various contractors.
  • Business Process and Governance: Since this was the first-time such an endeavor was taking place with multiple stakeholders, it would have been useful to map the business processes of the future state prior to award. Overall business processes would also support governance structures that would help in checking progress and checking alignment with the stated objectives of the project.
  • Requirements Management: Ever-changing requirements and a change in strategy can affect projects dramatically. For Healthcare.gov, there should have been some baseline requirements established earlier in the project. The baseline requirements would entail the basic functionalities needed by CMS. It would have been useful to use a Requirements Traceability Matrix (RTM) that would be available to everyone on the project. The RTM would not only help all stakeholders be informed of what is going but it would keep the entire team honest as well and perhaps identify any issues before they become a problem later.
  • Communications and Sharing of Information: The way the Healthcare.gov project was setup it seems like the left-hand did not know what the right hand was doing. This can create problems in understanding issues from a holistic prospective and not knowing if there are dependencies that should be coordinated.
  • Metrics and Measurements: Reasonable metrics should have been created to assess the health of the project. These metrics should measure the stakeholder and team satisfaction at the beginning and during the project in the project life cycle to determine where adjustments need to be made. Based on these metrics, remediation processes should have been setup so that nothing falls through the cracks.
  • Methodologies and Documentation: Although it seems like CMS was suppose to follow HHS’ Enterprise Life Cycle (ELC) but research indicates that an Agile methodology was used to develop the Healthcare.gov system. This alludes to a conflict in terms of what is supposed to be used versus what was actually being used. Additionally, the vendors who were helping CMS came with their own methodologies. It seems like there was too many methodologies but not a consistent alignment of them across the organization so that all teams were on the same page. In this scenario, the advice would be to understand the various methodologies at play and select the most appropriate one. This selection might also entail having some sort of a hybrid methodology that everyone conforms to. Having one methodology would reduce the amount of documentation that needs to be developed thus freeing up resources to work on the actual needs of the project.

5. RECOMMENDATIONS

5.1 Project Design Recommendations (CMS only)

  • Project Manager (PM): The Healthcare.gov project had 55 federal contractors working on it at various times. The system components that these federal contractors were developing were dependent on each other. For example, the Healthcare.gov website needed to communicate with EIDM and Data Hub which would communicate with FFE. Due to these complex dependencies, there was a significant amount of communication and coordination that needed to happen on this project. Additionally, someone needed to see how not only if these system components would work with each other but how the thorough testing of these systems would be the difference between a failed project versus a successful project. Despite the complexity of managing such a large group of contractors and understanding the pros and cons, CMS did not have a full-time PM for Healthcare.gov. While the real reasons for this decision are unknown, we can extrapolate from research that lack of an astute full-time PM was one of the major causes of the issues with Healthcare.gov.

We recommend that a full-time PM should have been assigned to Healthcare.gov who had experience in large-scale implementations. This PM would have the authority to push back on unrealistic timelines, have a holistic view of the project and understand that even though individual system components are being developed, there should be time allocated in the project to perform effective end-to-end testing.

  • Cross-Functional Teams: As discussed earlier, the system components that the federal contractors were developing had many dependencies on each other. Despite these dependencies, no proof has been found that cross-functional teams were established.

We recommend that in designing the project, the development of cross-functional teams should have been given a high priority. These cross-functioning teams would comprise of government and contractors. These teams would not only create synergies among the various people but should be designed in a way where sharing of lessons learned and recommendations are encouraged.

  • Team Satisfaction Survey (TSS): When a project falls off track, often times it is because once management pays attention to it, they are at a point of no return. This is what seems to have happened at CMS. By the time people working on the project started showing their concerns that testing could be an issue, CMS either ignored this or that they did not have a choice and thus went ahead to release a buggy version of the system to the masses.

We recommend that a TSS should be incorporated into the project whose purpose would be to ask people at all levels about their concerns and recommendations of the project. The TSS should collect this information at the beginning and periodically during the project. The TSS should also have a mechanism where actions could be taken promptly by management if there are issues that seem to be recurring. The TSS is not a status report but actually a mechanism to check the pulse of the project.

5.2 Project Implementation Recommendations (CMS only)

  • Pilot Approach: The healthcare.gov project used a “big bang” approach to release the software on October 1st, 2013. This approach resulted in overwhelming the system as users who tried to login found that their online forms were either taking too long to verify their information or that simply they were kicked out of the system. Additionally, it is apparent that the federal government did not anticipate the system errors it was going to get when the system went live.

We recommend that a pilot program should have been created for one of the states. This pilot program would be used to see how the system would perform when it goes live and what kind of issues it might have once it is open to the masses. Lessons learned from this pilot program could have been used to provide a better customer experience once the system went live.

CONCLUSION

To summarize, it should come as no surprise to those familiar with IT projects that most IT projects fail. A recent Gartner user survey showed that, while large IT projects are more likely to fail than small projects, around half of all IT projects fail in part due to unrealistic requirements, technical complexities, integration responsibilities, aggressive schedules, and inadequate testing. Causes that were all related to the Healthcare.gov project which resulted in its failure. As outlined in this case analysis, these fundamental mis-steps were the contributing factors that led to issues with this project and ultimately its failure. Based on our analysis CMS did not have the Project Integration and Project Management know-how to manage such a major project. The Agency’s assignment of a part-time project manager to the Healthcare.gov project is evident that leadership did not fully understand the magnitude and importance of the project, and what it took to implement IT projects. Based on our recommendations, it is our hope that such project management mis-steps are avoided for IT project implementations in the future.

References:

  1. Ariana Cha, L. S. (2013, 10 24). What went wrong with HealthCare.gov. Retrieved 04 16, 2014, from washington post: http://www.washingtonpost.com/national/health-science/what-went-wrong-with-healthcaregov/2013/10/24/400e68de-3d07-11e3-b7ba-503fb5822c3e_graphic.html
  2. CMS. (2012, 04 01). Health Insurance Exchanges. Office of Information Services, 25.
  3. CMS.GOV. (2014, 04 01). CMS covers 100 million people. Retrieved 05 01, 2014, from cms: http://cms.gov/
  4. Conerly, B. (2013, 07 16). ObamaCare’s Delays: Lessons For All Businesses About Project Management. Retrieved 04 21, 2014, from http://www.forbes.com/sites/billconerly/2013/07/16/obamacares-delays-lessons-for-all-businesses-about-project-management/
  5. C-SPAN. (2013, 10 24). Implementation of Affordable Care Act. Retrieved 03 15, 2014, from c-span.org: http://www.c-span.org/video/?315767-1/implementation-affordable-care-act
  6. Daconta, M. (2013, 11 01). Media got it wrong: HealthCare.gov failed despite agile practices . Retrieved 04 21, 2014, from gnc: http://gcn.com/blogs/reality-check/2013/11/healthcare-agile.aspx
  7. Desai, C. (2013, 03 05). Federally Facilitated Exchange. Health and Compliance Programs, 44.
  8. DHHS. (2012, 06 2012). Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews. Center of Medicare & Medicaid Services.
  9. Dudley, T. (2012, 06 10). The Affordable Care Act and Marketplace Overview. CMS Office of Public Engagement.
  10. Federal, C. (2013). Monthly Status Report –August 2013. CMS. MD: CGI Federal.
  11. Hardin, K. (2013, 11 13). HealthCare.gov rollout lesson: Push back on unrealistic launch dates. Retrieved 05 02, 2014, from techrepublic: http://www.techrepublic.com/blog/it-consultant/healthcaregov-rollout-lesson-push-back-on-unrealistic-launch-dates/#.
  12. Office, U. S. (n.d.). Patient Protection and Affordable Care Act. DC: GAO.
  13. Simon & Co., L. (2013, 12 04). Major Contracts to Implelment the Federal Marketplace and Support State Based Marketplaces. DC: Simon & Co.
  14. States, C. o. (2013). 113 Congress. DC: House of Representatives.
  15. Thibodeau, P. (2013, 12 30). The firm behind Healthcare.gov had top-notch credentials and it didn’t help. Retrieved 03 04, 2014, from computer world: http://www.computerworld.com/s/article/9244923/The_firm_behind_Healthcare.gov_had_top_notch_credentials_and_it_didn_t_help
  16. Thompson, L. (2013, 12 03). HealthCare.gov Diagnosis: The Government Broke Every Rule Of Project Management. Retrieved 04 01, 2014, from forbes : http://www.forbes.com/sites/lorenthompson/2013/12/03/healthcare-gov-diagnosis-the-government-broke-every-rule-of-project-management/
  17. Turnbull, J. (2013, 12 12). What The US Government Learned About Software From The Healthcare.Gov Failure (And Some Of Us Already Knew). Retrieved 05 02, 2014, from gaslight: http://gaslight.co/blog/what-the-us-government-learned-about-software-from-the-healthcare-dot-gov-failure-and-some-of-us-already-knew
  18. Walker, R. L. (2013). Response of CGI Federal Inc. to Additional Questions for the Record and Member Requests for the Record. DC: Wiley Rein LLP.

 

 

 

5 Questions to Ask About Your Business Transformation

Business transformation is the process of transforming (1) how things are made, (2) how things are bought, (3) how things are sold and/or (4) how services are provided. It has been pursued by organizations ever since the first organization came into being and would continue to be pursued in the foreseeable future. It is the way for organizations to know their current state (i.e., know where they are), their future state (i.e., know where they want to be) and their transition (i.e., what steps to take) by considering the people, business processes, services, products and technologies that can help them achieve their objectives. To be clear, business transformation is not merely a “business” only pursuit but rather it is an organizational pursuit that encompasses Information Technology (IT) and digital transformation journeys as well.

While the promise of business transformation is great, it is still something that organizations consistently struggle with. There are multiple factors that can lead to failed business transformation efforts but the number one reason seems to go back to a typical conversation within organizations. In the 21st century, technology for organizations is not just an enabler but paramount to their success. But how many times have you said or heard someone say, “business” wants this and “business” wants that and that “business” does not understand that systems cannot be developed overnight. Ingrained in this sort of thinking is the idea that somehow IT is different from “business”. Somehow there is this “us” vs. “them” mentality.

It is time to change this “us” vs. “them” culture. It is time to think about IT as not something that is outside of “business” but is part of “business”. To have this conversation there has to be mutual understanding that neither should downplay the importance of the other. This requires an understanding that all technical and non-technical aspects of the organization are there to support the end objectives of business transformation and that collaboration works much better than just mere animosity.

When organizations’ bread and butter business models are shattered in light of the new digital and sharing economy, “business” and technical folks have no one else to blame but themselves. As such it becomes imperative that organizations don’t get lost in complacency and infighting. These organizations should view business transformation as a holistic endeavor by paying enough attention to people, business processes, products, services and technologies that directly and indirectly affect them otherwise business transformation is just a pipe dream. In order for organizations to figure out their own business transformation journey, they need to ask the following questions from internal and external perspectives:

 

Currently

In the Future

1. Who is helped by business transformation? Who should be helped with business transformation? (E.g., management, employees, customers, shareholder etc.)
2. What does business transformation teach us? What should business transformation teach us? (E.g., better internal communications, governance, standardization, discipline, branding etc.)
3. Where does business transformation start? Where should business transformation start? (E.g., IT, marketing, operations, customers, vendors, partners etc.)
4. When is business transformation considered? When should business transformation be considered? (E.g., customer-employee conversations, competitors’ disruption/re-imagination of business models, new innovations, new methods etc.)
5. Why is business transformation is being done? Why should business transformation be done? (E.g., optimization, cohesiveness, long-term value, positive societal ripples etc.)

When you ask the above questions, keep in mind that without effective and unbiased feedback loops most business transformation journeys would be just nearsighted one-time initiatives and not something that would make organizations self-improving entities. Smart organizations have realized this and are taking advantage of not only technological changes but also setting themselves up for the future before they themselves get disrupted.

Business Transformation 5Ws

Lessons Learned in Creating a Corporate System

EXECUTIVE SUMMARY

This article discusses the various strategic, political and cultural factors that were associated with the decision to develop an online employee portal at SmFedCon. The cause and contributing factors that led to the software development project are explored in detail. Focus is placed on SmFedCon’s decision processes to make the initial decision not to develop the employee portal.

Examples are included that show how factors such as person biases and financial conservatism influenced SmFedCon from realizing the potential of the online employee portal.

ABOUT SMFEDCON AND THE PROBLEM REQUIRING A DECISION

SmFedCon was a small US Federal government contractor that provided Information Technology (IT) services in the areas of strategic planning, project management and software development. It had approximately 240 employees and 98% of these employees worked onsite at various government locations across 14 states and Washington DC.  It was growing rapidly and was involved with multiple high-level projects. Due to this rapid growth, a decision needed to be made if SmFedCon was going to spend time and resources to create an online employee portal.

HOW WAS THE PROBLEM IDENTIFIED

Within a few months of joining SmFedCon, CIO noticed a pattern where quality of documentation deliverables was declining due to lack of a version control system and no central document repository. What broke the camel’s back was an incident where one of the federal clients was about to receive different versions of the same document from the main office, project manager and the project team member. Although this was stopped in time, CIO realized that this as an issue and needed to be addressed. This issue was also confirmed by some of the employees who worked on site at federal client facilities.

ACTORS AND ROLES

The following table shows the reporting structure, roles and actors involved in the decision making process for creating an online employee portal:

Actors

Roles

Reported To

Chief Executive Officer (CEO)

  • Corporate priorities decision maker
  • N/A
Chief Financial Officer (CFO)
  • Corporate Financial Management
  • CEO
Chief Information Officer (CIO)
  • Corporate Technology Management
  • US Federal Government Projects Management
  • CEO

In regards to the online employee portal decision process, (1) the CFO’s role was to determine if new project budget requests made financial sense, (2) the CIO’s role was to provide a 2-page business case document to the CEO and (3) the CEO’s role was to decide.

BACKGROUND

Strategic Factors – Not in the Technology Roadmap

Although the initial decision not to develop the employee portal was overturned due to changing circumstances but at the beginning it was based on SmFedCon’s technology roadmap. The technology roadmap was written some year back before the company started to see rapid growth and did not take into account potential issues that might occur due to mismanagement and miscommunications.

Political Factors – Power

The CFO and CIO reported to the CEO however the CFO had more power at SmFedCon. CFO could easily influence the CEO in certain decisions. The CFO’s power came from the 20-year friendship with the CEO and as a trusted advisor to the CEO. The CFO was also responsible for IT prior to the CIO joining the company.

Cultural Factors – Small Business Mentality

While costs should be kept under control in all organizations but small businesses are especially sensitive to this. However, this sensitivity can blind the small businesses from what is possible. This was the case with SmFedCon. Even though they saw how an online employee portal could help solve some of the issue they had it was just not in the budget to pursue this direction.

SMFEDCON DECISION PROCESSES – The 2-Page Business Case

After the issues were identified, CIO met with the CEO to discuss that an employee portal could be the answer. CEO requested a 2-page business justification document to show if the employee portal could address the current and perhaps future needs.

The 2-page business case linked current issues with quality degradation, loss of productivity and eventually loss of clientele. It also listed the various types of options that were considered to stand up an online employee portal. These options included proprietary software vs. open source, existing application customization vs. software development and associated costs. The document listed the only option that was most feasible for SmFedCon.

The CEO discussed the 2-page business case with the CFO during one late hectic evening. The next day CEO informed CIO that the company had decided not to move ahead with the online employee portal project.

Next week, the CEO was working on a federal solicitation response when the computer died. At that time CEO was the only person who had the latest version of the document. CEO was also collaborating with other writers but they only had previous versions. Although the documents were retrieved but CEO realized how the online employee portal with the documentation management system could have saved time and would have been beneficial. The next day SmFedCon won a contract that they were working on and the CEO asked the CIO to go ahead with managing the development of the online employee portal.

The following diagram shows the decision-making process at SmFedCon.

Decision Making Process at SmFedCon

Decision Making Process at SmFedCon

ANALYSIS

In hindsight, there are a number of things that could have been handled better.

As companies grow, they have to realize that what worked in the past when there were only a few employees would not be sufficient in the future. Processes and tools should be in place and scalable to the growing needs of the organizations. In regards to SmFedCon, this was not the case. Although the company was growing rapidly it did not invest in processes and tools that could have helped it become a well-oiled machine. In the case of an online employee portal it was a necessity not a luxury since a vast majority of the employees were not on corporate locations but they still needed to access correct version of documentation and be able to collaborate with other team members.

Framing the Problem

When CIO joined SmFedCon, the problem with documentation management, project management and team collaboration was not defined. There was no framing of what was going on. Although CIO was were not hired to improve operations but suspected that it might have been one of underlying Blink moments that the CEO had. CIO suspected this because CIO had worked with CEO as a consultant and helped one of SmFedCon’s clients improve operations. It would have been advantageous to the company if they had given CIO the opportunity to conduct a thorough study of the company to see what other areas could be improved upon.

Biases – We all had them

In the decision-making process for the online employee portal there were definitely some biases from all actors. CIO’s bias came from working with small business in the past where cost was always a major issue. Additionally, in those organizations CIO was responsible for recognizing patterns and improving operations and thus tried to do the same with SmFedCon. Due to CIO’s background in technology, CIO believed that most operational issues can be solved through well thought out management and technology systems which was another bias. CIO’s decision not to get buy-in from the CFO prior to giving the 2-page business case and not getting CFO involved in determining the project budget stemmed from an unpleasant experience working with a previous CFO. All of this played into the CIO developing the business case without working with the CFO.

There were some biases from the CFO as well. Since CFO handled IT before CIO joined, it seems like CFO was reluctant in giving up control. As CIO looks back, s/he remember an incident where the CEO had to have a closed door meeting with CFO so that CEO would give CIO login credentials for a corporate system. CFO was skeptical about IT projects and was quick to make judgments about them. CFO was also double the age of the CIO and might have not understood/accepted why SmFedCon hired a young CIO at the company only in their 20s. In regards to the online employee portal, all these biases might have played a role in the CFO convincing the CEO that it was not feasible to start this project.

Although the CEO was not quick to make judgments but the 20-year-old relationship with the CFO might have played a role in the decision. Additionally, the decision not to be move ahead on the project might have been exacerbated by that hectic late evening.

Alternatives to Recommended Direction

The 2 pages CIO chose to concentrate on stated what issues SmFedCon was having and how they could be solved through the online employee portal. The document did not have any alternatives to select from. It only listed that SmFedCon can create the online employee portal (1) using open source technologies, (2) CIO would guide the developers and vendors in the design and (3) CIO would manage its development.

CONCLUSION

Although a decision-making process was followed but initially it did not result in the desired outcome. As discussed earlier, while there are many reasons for this however establishing good relationships and getting buy-in would certainly have helped.  Some of the other decision-making processes that could have helped include:

  • Nominal Group Technique – This technique could have been helpful in determining the various issues employees were having. Since the online employee portal was the CIO’s idea even though s/he had been with the company only for few a months versus other employees who had been around for a long time. This might have created some resentment towards the idea. The Nominal Group Technique could have helped to make idea generation and problem solving more collaborative.
  • Framing – Proper framing of the issues would have helped too. CIO did not frame the issues correctly and jumped to the solution. It would have been great to just step back, frame each issue individually and then see how issues could be resolved.
  • Personality Types – CIO assumed that most people are people are like him/her. However, if CIO had understood the various personality types and their motivations then his/her recommendations could have appealed more to CEO and CFO.

 

5 Questions to Ask About Your Culture

Peter Drucker, one of the most influential management consultants in the world, is often attributed to coining the phrase “Culture eats strategy for breakfast.” Organizations that can harness the power of culture can create environments where everyone can contribute towards the attainment of strategic objectives. However, most organizations are unable to create such environments and hence their pursuit of strategic objectives never fully comes to fruition. The three main reasons for this failure are:

  1. The fallacy that culture is considered something fuzzy thus unquantifiable
  2. The lack of a holistic approach to forming/enhancing positive attributes of the inherent cultures
  3. The half-baked idea that culture equates to only people

An organization’s culture is a way of thinking, behaving and working within the physical, virtual, legal and mental organizational boundaries. What an organization thinks about its place in the world is shown by its vision, mission statement and (un)displayed values which directly influence internal and external stakeholders. How an organization behaves is shown by leadership examples, levels of (un)trustworthiness, encouragement and discouragement of cross-collaboration and camaraderie. How an organization works is shown by its (un)biased business processes, (non)adoption of technological advancements, (un)approved frameworks/methodologies/approaches, employee (non)recognitions, (un)real career ladders, risk averseness, salaries, (non)physical locations, clothing and subcultures.

Culture is not just one thing but it is a collection/combination of different things/subcultures that can be observed and also measured. Thus, how organizations measure, incentivize and reward from the selection of the right people to optimized processes and efficient use of technology becomes crucial towards achieving organizational objectives. In order to understand and effectively bring cultural change, the following questions need to be asked:

Strategic Perspectives on Culture:

 

Currently

In the Future

1.

Who is incentivized at the executive level to transform culture?

Who should be incentivized at the executive level to transform culture?
2. What governance structures are in place for strategic cultural transformation? What governance structures should be in place for strategic cultural transformation?
3. Where is technology integrated into transforming culture? Where should technology be integrated into transforming culture?
4. When and how often cultural transformation objectives are communicated? When and how often cultural transformation objectives should be communicated?
5. Why cultural transformation is critical to achieving strategic objectives?

Why transformation should be critical to achieving strategic objectives?

Tactical Perspectives on Culture:

 

Currently

In the Future

1.

Who is incentivized at the middle management level to be champions of transforming culture?

Who should be incentivized at the middle management level to be champions of transforming culture?
2. What business units, functional areas and teams are included to bring about transformation? What business units, functional areas and teams should be included to bring about transformation
3. Where technology hinders in cultural transformation? Where technology might hinder in cultural transformation?
4. When is the start and end of cultural transformation communicated? When should the start and end of cultural transformation communicated?
5. Why cultural transformation is critical to achieving tactical objectives?

Why cultural transformation should be critical to achieving tactical objectives?

Operational Perspectives on Culture:

 

Currently

In the Future

1.

Who sees cultural transformation as an obstacle?

Who might see cultural transformation as an obstacle?
2. What business processes provide views on the organization’s culture? What business processes should provide views on the organization’s culture?
3. Where is technology part of your understanding the organization’s culture? Where should technology be a part of understanding of the organization’s culture?
4. When were you informed about the cultural transformation objectives? When should you have been informed about the cultural transformation objectives?
5. Why cultural transformation is critical to achieving your daily tasks?

Why transformation should be critical to achieving your daily tasks?

Culture transcends most of our thoughts and how we function within organizations and outside of it. This overarching affect of culture can create biases in terms of what people we hire, what processes we put in place, what technologies we choose to use, who we talk to and what we care to observe. By asking the right questions and putting the right measurements in place, we can have a quantifiable understanding of the baseline cultures and enhance it for the better. In doing so we have to be cognizant of our own biases, biases of others and any prevailing biases that result in cultural stagnation.

Cultural Infleunces.jpg

Standing Up an Enterprise Architecture Center of Excellence and a Certification Program at Your University

EXECUTIVE SUMMARY

This article proposes the establishment of a Center for Operations, Research and Education (CORE) at your university. CORE would be a team of people that proactively and holistically help achieve university’s business outcomes. Its mission would be to provide comprehensive educational programs in Enterprise Architecture, conduct research and use this research to help transform the university.

For this article, the strategic direction and cultural factors in relationship to operations, research and education in Enterprise Architecture are considered. We assume status quo in regards to your university’s culture for this assessment, specifically the perception of Information Technology. The following table shows what we considered:

  Operations Research Education
Current State (Observations)
  • No one is responsible for Enterprise Architecture
  • No research is being conducted in this field
  • No comprehensive program in Enterprise Architecture
Future State (Recommendations)
  • CORE would be independent of your university’s President
  • Rotating leadership where every school, department and division has the opportunity to lead CORE
  • Conduct research by partnering with other elite institutions
  • Begin by providing a graduate certification program
  • Aim for providing Bachelor’s, Master’s and executive programs in the future

This assessment reveals that currently where Enterprise Architecture is placed in the organization, it will not be able to provide the organizational transformational value that is aspires to provide. Additionally, your university should start providing comprehensive programs in this field otherwise they would be left behind other educational institutions that are already moving in this direction.

1. ANALYSIS

This section provides an analysis of standing up CORE from an operational, research and educational prospective.

Assumptions

  1. Your university’s executive management would support this effort
  2. All university communities would help transform it to achieve operational excellence
  3. Perception of IT would not change instantly

1.1 What is Center of Excellence?

According to Tarek M. Khalil et al. (2001), within an organization, a Center of Excellence may refer to a group of people, a department or a shared facility. It may also be known as a Competency Center or a Capability Center. The term may also refer to a network of institutions collaborating with each other to pursue excellence in a particular area.

1.2 What is Enterprise Architecture?

Due to the evolving nature of this field, there are many academic and practitioner definitions of what is Enterprise Architecture. For our purposes we will use the one definition from the glossary on Gartner’s website that states Enterprise Architecture as a discipline for proactively and holistically leading enterprise responses to disrupt forces by identifying and analyzing the execution of change toward desired business vision and outcomes. Enterprise Architecture delivers value by presenting business and Information Technology (IT) leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. Enterprise Architecture is used to steer decision-making toward the evolution of the future state architecture.

In a nutshell, “Enterprise Architecture bridges the Business and Information Technology via enterprise integration/standardization resulting in people becoming more efficient and effective in achieving their objectives.” Kevin Smith (2010)

It should be noted that Enterprise Architecture is not an Information Technology endeavor but in fact it sits in between Business and IT and works across organizational silos.

1.3 What is CORE?

If we combine the two definitions above then a definition for center of excellence in enterprise architecture emerges which is a team of people that proactively and holistically helps achieve business outcomes. For your university and breadth of this center’s agenda, it would be called Center for Operations, Research and Education (CORE).

1.4 What is the Operational Perspectives?

1.4.1 Why should Your University Pay Attention to Enterprise Architecture?

One of the biggest proponents and users of Enterprise Architecture is the most powerful office in the world – The White House. The United States Federal Government has been using Enterprise Architecture for more than a decade and continues to see it as a way to look across organizational silos.

What this means for your university is that, huge organizations are trying to improve their operations and they are turning towards Enterprise Architecture to help them do that. Your university can tap into this, apply Enterprise Architecture effectively and perhaps get involved in Enterprise Architecture discussions for organizational improvements. This involvement could also translate into future research grants and job opportunities for students.

1.4.2 Why putting Enterprise Architecture under Information Technology is Not a Good Idea?

All organizations are a composition of many cultures and subcultures. Some of these cultures develop over time and then become part of the routine mentality of an organization. Your university is not immune from this. In order to understand the perception of Information Technology at your university, look at how the university’s strategic plans were developed. Was Information Technology involved/invited to help in the development of your university’s strategic plan?

If not, then this is a cultural issue and often the cause of misalignments within organizations. Whenever Information Technology is not involved in strategic planning, it gives the perception that Information Technology is not important, it is just a commodity and it is just back office activities. This lack of involvement is the reason that according to the 2013 Chief Information Officer ‘State of the CIO’ survey, “63% [of the respondents] say the majority of their time and focus is spent on aligning Information Technology initiatives with business goals.” This shows there are gaps in aligning Business and Information Technology. This alignment can be achieved through Enterprise Architecture. According to a Gartner study (G00146809), Business-Information Technology alignment is the primary driver for Enterprise Architecture as shown below:

Primary Driver for Enterprise Architecture

Taking into consideration the current culture at your university, placing Enterprise Architecture under Information Technology would not make sense. If Enterprise Architecture continues to be placed under Information Technology then at your university Enterprise Architecture would be perceived as an “Information Technology thing”. This perception would defeat the overarching purpose of Enterprise Architecture. Enterprise Architecture needs to have a holistic understanding of your university going beyond Information Technology. A Gartner study (G00245986) supports this thought of Enterprise Architecture going beyond Information Technology as shown below:

Enterprise Architecture beyond IT

From the above figure, we can learn that while technology is a consideration in Enterprise Architecture but it is certainly not the only aspect that needs to be considered. A well-run CORE at your university would consistently produce qualitative and quantitative for both Business and IT. Some of examples of these are:

  • Qualitative Benefits
    • Improved Communications Across Organizational Silos
    • Increased Productivity
    • Efficient Portfolio Management
    • Effective Business Intelligence
  • Quantitative Benefits
    • Reduced Costs
    • Revenue Generation

1.4.3 What are the Maturity Levels for Enterprise Architecture?

According to a Gartner study (G00252206), it outlines the five levels of Enterprise Architecture maturity shown below:

Enterprise Architecture Levels of Maturity.png

What this means is that a lot of work needs to be done in this area and your entire university has to be involved in it so that it can be used effectively across organizational boundaries.

1.4.4 How will CORE Measure its Success?

From an operational prospective, a Gartner study (G00247593) indicates the following ways to align Enterprise Architecture to strategic business initiatives:

Align Enterprise Architecture to Strategic Business Objectives

At your university, success of Enterprise Architecture would depend upon how it can help your university transform itself to achieve its strategic visions.

1.5 What are the Educational and Research Perspectives?

1.5.1 Is Enterprise Architecture Taught at Your University?

Are Enterprise Architecture courses taught at your university in various schools (e.g., business school, engineering school, professional studies school etc.)? If yes, do you know if these schools at your university are talking to each other about Enterprise Architecture? If not, then there is no comprehensive Enterprise Architecture program at your university. From this observation, we can decipher that although Enterprise Architecture might be part of certain programs but overall it is fragmented at your university.

1.5.2 Why Should Your University Teach or Do Research in Enterprise Architecture?

In order to be an elite institution, your university needs to look at what other elite institutions are doing, assess what programs they offer and what kinds of research they are pursuing. Your university should then look at how these programs can be stood up.

For the purpose of this article, we will only focus on the institutions that teach, conduct research and/or have comprehensive programs in Enterprise Architecture. These include:

  Institutions Name Country
1 Harvard University USA
2 Massachusetts Institute of Technology USA
3 Dartmouth College USA
4 Carnegie Mellon USA
5 Pennsylvania State University USA

2. Recommendations

Due to the importance of Enterprise Architecture as a catalyst in organizational transformation, in the current culture at your university, CORE should not be under IT. CORE’s mission is to help your university continuously evolve, conduct/use research and provide comprehensive educational programs. It should be an interdisciplinary entity whose members include all schools, divisions and departments of your university. Thus, it should be placed where it has the most influence as shown below:

CORE at your university.png

CORE should start as a chartered center initially led by School of Business and in collaboration with Engineering School, Professional Studies School and IT. Within the first year this would develop relationships across all the university.

CORE’s leadership should be on a rotating basis where each school, department and division of your university has the opportunity to lead CORE for at least 1 year. This will create an atmosphere of collaboration and help break down organizational silos. This governance structure would also encourage participants to be actively involved in CORE’s advancement and they can use it to also enhance their own schools, divisions and departments.

In regards to education and research, CORE should develop a graduate certificate program with the goal of creating Bachelor’s, Master’s and executive programs in the future.

References:

  1. Tarek M. Khalil; L.A. Lefebvre; Robert McSpadden Mason (2001). Management of Technology: The Key to Prosperity in the Third millennium: Selected Papers from Ninth International Conference on Management of Technology, Emerald Group Publishing, pp.164
  2. IT Glossary, Enterprise Architecture, http://www.gartner.com/it-glossary/enterprise-architecture-ea/
  3. Kevin Smith (2010), Pragmatic EA: The 160 Character Challenge, Version 1.3, pp.12
  4. White House (2012), http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/common_approach_to_federal_ea.pdf
  5. CIO Magazine (2013), ‘State of the CIO’ Survey, pp.4
  6. Robert A. Handler (2007). Key Issues for Enterprise Architecture. Retrieved from Gartner database.
  7. Julie Short (2013). Agenda Overview for Enterprise Architecture. Retrieved from Gartner database.
  8. Chris Wilson (2013). ITScore Overview for Enterprise Architecture. Retrieved from Gartner database.
  9. Betsy Burton (2013). EA Business Value Metrics You Must Have Today . Retrieved from Gartner database.
  10. Harvard University, IT for Management, http://hbsp.harvard.edu/list/it-for-management-toc
  11. Massachusetts Institute of Technology, Center for Information Systems Research, http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/
  12. Dartmouth College, Auburn Cyber Research Center, http://www.ists.dartmouth.edu/events/abstract-hamilton.html
  13. Carnegie Mellon, Institute for Software Research, http://execed.isri.cmu.edu/elearning/enterprise-architecture/index.html
  14. Pennsylvania State University, Center for Enterprise Architecture, http://ea.ist.psu.edu

CEO and Service Orientated Architecture

EXECUTIVE SUMMARY

This article discusses what is Service Orientated Architecture (SOA), how it is used, what are its benefits and what are the challenges when adopting it for your organization. It explores the business and technology perspectives of where SOA can be applied internally and externally by showing the following benefits of SOA to your organization:

  • Enhanced Operational Insights
  • Increased Business Agility
  • Better Customer Experience
  • Reduced Technology Costs
  • Creation of New Business Models

Keeping the benefits in mind, your organization has to also assess the following challenges that SOA brings for your organization:

In a nutshell, SOA is a framework that allows business processes to be highlighted to deliver Information Technology (IT) interoperability and rapid delivery of application functionality. A successful adoption of SOA would result in enhanced alignment between Business and IT. So, while there are challenges to overcome by your organization but overcoming these challenges would make your organization aligned from top to bottom and across people, processes and technologies.

1. WHAT IS SOA?

1.1. What is a Service?

In order to understand SOA, lets first explore the concept of a ‘service’. Depending upon the context, Merriam-Webster defines a service in 11 different ways. These include a service being “the occupation or function of serving”, “the work performed by one that serves” to many other religious, military, public utilities and organizational definitions (“Service.” Merriam-Webster. Merriam-Webster, n.d. Web.). In economics and marketing, a service is the exchange of non-material equivalent of a good.

In organizations, a service can have business contexts and technological contexts. From a business context, a service can be activities that are performed inside the organization (e.g., Accounts Receivables), outsourced to another organization (e.g., Payroll Processing) and performed for the internal or external customers (e.g., Helpdesk Support). From a technological context, a service can be provided within an operating system (e.g., Windows EventLog), for software (e.g., log service) and where a user exchanges messages with a program to interact with it.

1.2. What is Service-Orientation and Service-Orientated Architecture?

Now that you have an understanding of what a service is, lets define what is service-orientation and what is service-orientated architecture. Microsoft defines SOA to be “a design philosophy independent of any vendor, product, technology or industry trend” (Linthicum, David. “Chapter 1: Service Oriented Architecture (SOA).” Chapter 1: Service Oriented Architecture (SOA). Microsoft, n.d. Web.). Oracle on the other hand says SOA “provides a unified approach with a single interface for all of your current and future integration requirements” (“Oracle SOA – Service-Oriented Architecture.” Service Oriented Architecture. Oracle, n.d. Web.)

In light of the varying definitions from vendors and practioners, a working group was established in 2009 to remove the confusion. This working group had a mix of practioners and vendors and came up with the SOA Manifesto that states “service-orientation is a paradigm that frames what you do” and that “SOA is a type of architecture that results from applying service-orientation” This group also prioritized SOA as a business initiative rather than a technological initiative and thus states the importance of (1) business value over technical strategy, (2) strategic goals over project-specific benefits, (3) intrinsic interoperabilityover custom integration, (4) shared services over specific-purpose implementations, (5) flexibility over optimization and (6) evolutionary refinement over pursuit of initial refinement. (Erl, Thomas et al. “SOA Manifesto.” SOA Manifesto. N.p., Oct. 2009. Web.)

As you can see, SOA is an organizational journey that spans across business and technology. From a business perspective, business objectives drive the integration of applications within the organization and between business partners. From a technological perspective, integration of applications is modeled using loosely coupled services that can be combined and orchestrated to achieve business objectives. Thus, you can say that SOA is a framework that allows business processes to be highlighted to deliver interoperability and rapid delivery of functionality.

1.3. How does SOA work?

In SOA, you have three roles that include the Service Provider, the Service Requester and the Service Registry. The Service Provider role (1) describes what the service does, (2) deploys the service over the network and (3) publishes service in a service registry. The Service Requester role (1) finds service in a service registry and (2) uses the service description to invoke the service. The Service Registry advertises the availability of a service that is published by the Service Provider. The interaction between Service Provider, Service Requester and Service Registry is shown below:

Business Objectives and SOA

From the above figure, you can see that business objectives are the drivers for SOA within an organization. While the main idea behind SOA is the reuse of generalized software components modeled as services, but due to its ability to encourage collaboration between business and IT, it can create alignment and can help the organization respond to the rapidly changing business environments.

2. WHAT ARE THE BENEFITS OF SOA?

In order to understand how SOA can help your organization, you have to explore some of its benefits and how other organizations were able to use SOA for their strategic advantage. Following are some of the benefits of SOA:

2.1 Enhanced Operational Insights:

It is often observed in organizations that the left hand is unaware of what the right hand is doing. This type of disconnects cause organizational silos where the approach to developing business processes and the technologies that support it have a very narrow focus. Due to this, the business processes and technologies are tightly coupled with the functional needs at the time when they were created. While this gets the job done for a particular functional need but now if you multiple this scenario across the entire organization and its various functions then you start to see a spaghetti of business processes and its enabling technologies (“Why Enterprise Architecture?” YouTube. Mastering ArchiMate, 19 Apr. 2013.)

The ‘spaghetti architecture’ can result in duplicative business processes and technologies across different organizational divisions. These business processes and enabling technologies are rarely documented which increases the risk of costly mistakes when these business processes change and when the underlying technologies that support these business processes become outdated. In spaghetti architecture, there is also rarely any thought put into the future needs of the organization as whole, this can also result in using technologies that might become obsolete for future needs.

SOA addresses the spaghetti architecture head-on by creating operational insights into the different organizational processes of the organization. Since the main driver of SOA is business objectives that encompass business processes, your organization can start to view the various unique, duplicative and interdependent business processes holistically across the entire company. This holistic view gives your organization the ability to see which business processes can be completely eliminated, which ones can be combined and which ones can be used to make rapid decisions. An example of an organization that used SOA to address its spaghetti architecture is FedEx, a $32 billion multinational organization. By overhauling FedEx’s entire spaghetti architecture to SOA, within 3 years it was able to better manage acquisitions and process changes (Ganesan, Suresh et al. “What Business Executives Must Know About SOA.” Cognizant White Paper (2007): n. pag. Bloom Group, 2007. b.)

2.2 Increased Business Agility:

In today’s competitive business environment, business agility is the ‘holy grail’ that organizations strive to achieve. This business agility can entail many things and can range from bringing a product/solution quicker to the market to providing efficient troubleshooting support for customers. This also implies that business agility is a moving target and can be achieved partially and holistically depending upon the business objectives. The underlying thought behind business agility is the idea of continuous improvement to get better and better at what the organization does.

As your organization looks to be agile, SOA provides the foundation to do this. Due to operational insights and an understanding of the shared services within your organization, SOA can help accelerate what you are trying to achieve. An example of an organization that used SOA to become agile was Wachovia Bank. Using SOA, Wachovia was able to promote a product engineering mentality and make IT an advisor to the business (Ganesan, Suresh et al. “What Business Executives Must Know About SOA.” Cognizant White Paper (2007): n. pag. Bloom Group, 2007. Web.). In 2008, Wells Fargo bought Wachovia for $15.4 billion and when in 2014 Wells Fargo became the highest earning bank in the United States, its CEO gave credit to their smooth acquisition of Wachovia due their cultural similarities (Raice, Shayndi. “As Wells Fargo Hits Profit Milestone, CEO Gives Credit to Wachovia.” MoneyBeat RSS. The Wall Street Journal, 14 Jan. 2014. Web.). You can extrapolate that Wachovia’s SOA might also have been a factor in the smooth acquisition since most acquisitions fail due to cultural and technological differences.

2.3 Better Customer Experience:

If customer is king, then customer experience must be the only priority. Traditionally, organizations have considered customer experience to be the point of transaction when a purchase is made. But a more holistic view of customer experience entails the pre-sales and post-sale processes as well. Due to the many touch points (e.g., physical, website, mobile, social media etc.) of the customers with business; customer experience is not a point of transaction anymore. Forrester® goes on to say that in today’s era of empowered and always connected customers, organizations need customers more than the customers need organizations. [9] Forrester® goes on and talks about creating a “customer experience ecosystem” that entails the people, processes, policies and technologies. (Fenwick, Nigel. “Nigel Fenwick’s Blog.” Why Customer Experience Will Become The #1 CIO Priority. Forrester Research, 27 June 2013. Web.)

When you talk about customers, you have to take into account both the internal customers and the external customers. The ease by which internal customers can provide customized and quick services to external customers can increase productivity and improve the bottom line for your organization. An example of an organization where SOA was used to improve customer experience was The Hartfort Group, a $26 billion organization. By implementing SOA, The Hartfort Group was able to enable its agents to create, assemble and complete transactions with the external customers (Ganesan, Suresh et al., “What Business Executives Must Know About SOA”).

2.4 Reduced Technology Costs:

As discussed earlier, “spaghetti architecture” can prove to be costly to the organization due to duplicative business processes and the underlying technologies. These costs can quickly add up and start to affect the bottom line of your organization. On the flip side, since SOA allows reuse of services across many functional domains, this can free up money for other endeavors that your organization might be interested in pursuing. An example of this would be Starwood Hotels who are on their way to saving $20 million per year simply by moving from tightly coupled mainframe applications to loosely coupled SOA services (Ganesan, Suresh et al. “What Business Executives Must Know About SOA.” Cognizant White Paper (2007): n. pag. Bloom Group, 2007. Web.).

2.5 Creation of New Business Models:

In today’s competitive business landscape, organizations are continuously looking for ways to differentiate themselves from their competitors. This differentiation can also come in the form of determining new business models enabled by SOA services that would not have been possible in the past. Due to SOA, your organization can look across the various services and make intelligent decisions on what services can be combined to create additional value for the customer that in turn can increase the bottom line. An example of where SOA is best used and enforced is that of Amazon, a $74 billion online retailer (“Amazon Booms in 2013 With $74.45 Billion in Revenue.” Digital Book World. Digital Book World, 30 Jan. 2013. Web.). In 2002, Jeff Bezos of Amazon issued a mandate that stated, “All teams will henceforth expose their data and functionality through service interfaces” and “anyone who doesn’t do this will be fired” “The Secret to Amazons Success Internal APIs.” The Secret to Amazons Success Internal APIs. API Evangelist, 12 Jan. 2012. Web.). Bezos’s commitment to SOA and betting the entire future of the company speaks volumes about what SOA can do for an organization.

3. WHAT ARE THE CHALLENGES OF SOA?

So, while SOA provides great promise for your organization, it is by no means a panacea. Thus, you have to also carefully assess the following challenges that SOA brings to your organization:

3.1. Governance & Organizational Maturity:

Governance in a way is the policy of how things ought be done. It provides a framework in which business processes can operate under regulatory, time and other constraints. Thus, governance is an organizational responsibility even for SOA and not only an IT activity. In order to accomplish this, your organization should setup a governance board that consists of a cross-functional team from both business and IT. Additionally, governance should not only include the overall organization and management of SOA activities but also creation of success and failure measurements. These measurements should be used to actually determine the state of SOA within your organization instead of people doing vaporware measurements that have no grounds in reality.

3.2 Not Only an IT thing:

If the burden of implementing SOA across your entire organization is on IT then it takes away the business-side’s responsibility and involvement. While IT is responsible for creating SOA services but business has to work collaboratively with IT to define what those services are. Additionally, the business-side has to understand how did the current state of misalignment between business and IT came into being and how this can be avoided in the future. Thus, SOA is not an IT issue but an organizational endeavor that affects all parts of your organization.

3.3. Organizational Processes Need Reevaluation:

While the presence of too many point-to-point integrations in your organization can reduce your ability to be agile but there is a bigger perspective that you also have to consider. This perspective revolves around your organizational processes that led to misalignment in the first place. These organizational processes not only entail IT but also the business-side. Typically, IT does what business asks but then there has to be some mutual understanding that the requests for services have to be understood holistically. Even after SOA migrations, if your organizational processes are not optimized they might still result in ad-hoc requests from the business leading back to point-to-point tightly couple services that you try to avoid in SOA.

3.4. Long-Term View of Legacy Systems is Needed:

In the short term, it may seem like a good idea to not replace your organizational legacy systems but in the long term there are issues when you do this. These issues entail the constant “patching” to upgrade underlying hardware and software in addition to overburdening legacy systems where new services are being added on top of systems that should be replaced rather than being continued to extend their life. While it may not be possible to replace legacy systems altogether but you should have a plan to retire these systems with new systems eventually.

3.5. No Measurement Means No ROI:

If your organization does not measure pre-SOA activities then how would you know if what SOA promised for your organization is what you really wanted to achieve. So, since SOA often requires long-term commitment from both business and IT, you have to develop performance metrics upfront before you embark on your journey towards SOA-fication.

4. CONCLUSION

Due to your organization’s desire to compete in today’s competitive business landscape, you have to carefully weigh the benefits of SOA’s value in terms of operational efficiencies and organizational improvements. Based on the information provided above, using SOA will help your organization have enhanced operational insights which can increase your organization’s agility to provide better customer experiences, reduce technology costs and explore new business models. Also, you need to keep in mind that SOA presents the challenges of honestly looking at yourselves in terms of maturity and business-IT collaboration by having a long-term view of what you want your systems to accomplish and how you measure what success looks like. Consequently, if you lack foresight into how SOA can be used as a business transformation effort then your desire to be the best would just be a pipedream.

References:

  1. “Service.” Merriam-Webster. Merriam-Webster, n.d. Web. <http://www.merriam-webster.com/dictionary/service&gt;.
  2. Linthicum, David. “Chapter 1: Service Oriented Architecture (SOA).” Chapter 1: Service Oriented Architecture (SOA). Microsoft, n.d. Web. <http://msdn.microsoft.com/en-us/library/bb833022.aspx&gt;.
  3. “Oracle SOA – Service-Oriented Architecture.” Service Oriented Architecture. Oracle, n.d. Web. <http://www.oracle.com/ca-en/products/middleware/soa/overview/index.html&gt;.
  4. Erl, Thomas et al. “SOA Manifesto.” SOA Manifesto. N.p., Oct. 2009. Web. <http://www.soa-manifesto.org/&gt;.
  5. “Why Enterprise Architecture?” YouTube. Mastering ArchiMate, 19 Apr. 2013. Web. <http://www.youtube.com/watch?v=qDI2oF1bASk&gt;.
  6. Ganesan, Suresh et al. “What Business Executives Must Know About SOA.” Cognizant White Paper (2007): n. pag. Bloom Group, 2007. Web. <http://bloomgroup.com/sites/all/files/Cognizant%20SOA%20paper.pdf&gt;.
  7. Raice, Shayndi. “As Wells Fargo Hits Profit Milestone, CEO Gives Credit to Wachovia.” MoneyBeat RSS. The Wall Street Journal, 14 Jan. 2014. Web. <http://blogs.wsj.com/moneybeat/2014/01/14/as-wells-fargo-hits-profit-milestone-ceo-gives-credit-to-wachovia/&gt;.
  8. Fenwick, Nigel. “Nigel Fenwick’s Blog.” Why Customer Experience Will Become The #1 CIO Priority. Forrester Research, 27 June 2013. Web. <http://blogs.forrester.com/nigel_fenwick/13-06-27-why_customer_experience_will_become_the_1_cio_priority&gt;.
  9. “Amazon Booms in 2013 With $74.45 Billion in Revenue.” Digital Book World. Digital Book World, 30 Jan. 2013. Web. <http://www.digitalbookworld.com/2014/amazon-booms-in-2013-with-74-45-billion-in-revenue/&gt;.
  10. “The Secret to Amazon’s Success Internal APIs.” The Secret to Amazon’s Success Internal APIs. API Evangelist, 12 Jan. 2012. Web. <http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/&gt;.

 

Future Considerations for Hewlett Packard Enterprise

A year ago Hewlett Packard (HP) decided that it was going to split into two companies. This decision became real last week when HP officially split into HP Inc. and Hewlett Packard Enterprise (HPE) as announced by Meg Whitman on her LinkedIn post. The main reason given for this split was focus. HP Inc. would focus on selling consumer products such as personal computer and printers. HPE would focus on selling enterprise products, enterprise software and enterprise services such as cloud computing, big data, cyber security to improve operations.

It seems that on the surface the announcement of the split of HP into HP Inc. and HPE has received a mix bag of optimism and skepticism from different corners of the tech industry. On the optimistic side, this is a good move since it would help these companies focus on their core competencies and provide focused customer service and client experience. On the skeptical side, this is a little too late since the tech industry has been moving from merely selling computer products to selling more technology software and services for at least 20 years.

If we observe the tech industry from a modern economics lens we would find that this split is not something that is novel but it is very predictable. From a modern economics lens, the ‘primary sector’ for the tech industry focused on hardware and products, the ‘secondary sector’ for the tech industry focused on software and the ‘tertiary sector’ for the tech industry focuses on technology services. What is interesting is that this split lets HP Inc. focus on the ‘primary tech sector’ for consumers while HPE focuses on both the ‘secondary tech sector’ and the ‘tertiary tech sector’ simultaneously for enterprises. Eventually though, HPE would increase their focus on the ‘tertiary tech sector’ since the margins are much better in services as compared to just products and software. In order for HPE to become a bigger player in the services market, they should consider the following:

Currently

In the Future

Who is leading the services division?

 

Who should be leading the services division?
What processes are being followed to provide services? What processes should be followed to provide services?
Where mix of tech and non-tech services are being provided? Where mix of tech and non-tech services should be provided?
When are services bundled with hardware and software? When should services be bundled with hardware and software?
Why standalone services are provided? Why should standalone services be provided?

HPE leadership has to realize that any organizational splits are not without consequences. These consequences could entail: (1) Stocks becoming more volatile as any budget cuts with client enterprises could affect the bottom line, (2) Competitors might be able to provide same level of service at a cheaper cost with better client experiences and (3) Lack of optimized processes with no flexibility to adjust for enterprise clients needs could reduce overall reputation of HPE.

One of the ways to address the above mentioned split issues would be to create independent mock enterprise client teams that would rate how easy or difficult it was to deal with HPE in light of changing economic conditions, client experiences and efficient and effective processes. These independent mock enterprise client teams would be used to further refine HPE and put itself in the shoes of its enterprise clients.

Organizational Changes - HPE