Author: Arsalan

75 Questionable Thoughts About Organizational Transformation

Questionable Thoughts

  1. Strategies
    • People
      • Only executives can transform organizations
      • Internal expertise have no/minimum value
      • Everyone will be eager to contribute
    • Processes
      • Internal business processes and Information Technology (IT) processes don’t matter
      • Interfacing processes with partners and vendors don’t matter
      • All processes and standard operating procedures (SOPs) have been documented and followed without deviation
    • Products
      • Our products can’t serve beyond current client industries
      • We don’t need to look for best-of-breed products
      • We don’t need product evaluation feedbacks from customers, employees, partners and vendors
    • Services
      • Employee experiences are not important
      • Customer experiences are not important
      • Partners and vendors’ experiences are not important
    • Technologies
      • IT doesn’t need to get involved
      • Shadow-IT doesn’t exist
      • IT is just an enabler
  1. Politics
    • People
      • All title-holders have the same power
      • Only leaders can be the go-to people
      • There are no biases at play
    • Processes
      • We always have fair ways of making decisions
      • We always methodically assess power and its affects
      • Power-grabs don’t happen
    • Products
      • Personal experiences don’t affect product selection
      • Personal experiences don’t affect product selling
      • Personal experiences don’t affect product development
    • Services
      • There is no correlation between employee services and customer services
      • Customer services don’t affect partners and vendors
      • Unconscious favoritism doesn’t happen during decision-making
    • Technologies
      • Technologies keep us unbiased
      • The ecosystem of technologies ends within organizational boundaries
      • IT can’t help
  1. Innovation
    • People
      • There is no correlation between organizational innovation and individuals being innovative
      • The innovation and experimentation of partners and vendors don’t affect us
      • People need to explore being innovative in their own time
    • Processes
      • Incremental and disruptive innovations follow same processes
      • Can’t learn from others failures
      • Innovation doesn’t require a methodical process
    • Products
      • A particular department/individual is responsible for innovation
      • Innovation of others doesn’t affect us
      • There is no need to have feedback loops from employees, customers, partners and vendors
    • Services
      • Only customer services can improve customer services
      • There is no need to test and improve customer service journeys
      • Wise to follow industry status quo standards
    • Technologies
      • There is no innovation left in technologies
      • Adapting technologies is the easiest thing to do
      • IT is a cost center and doesn’t require an innovation budget
  1. Culture
    • People
      • Only executives can set the cultural norms
      • External environments don’t affect culture
      • Culture is only about people
    • Processes
      • Business processes and IT processes don’t create culture
      • Culture is unquantifiable
      • Culture isn’t a learned behavior
    • Products
      • Culture doesn’t impact the products we buy
      • Culture doesn’t impact the products we sell
      • Culture has no implications on product development
    • Services
      • Culture doesn’t impact the services we buy
      • Culture doesn’t impact the services we sell
      • Culture has no implications on employee and customer journeys
    • Technologies
      • Technologies can’t augment culture
      • Technologies can’t destroy culture
      • Culture-clashes need to be normalized
  1. Execution
    • People
      • Preparing sponsors, champions and leaders isn’t necessary
      • Only a handful need to know about the overall strategy
      • Layoffs are on the table
    • Processes
      • No business processes and IT processes need to be adopted for transformation
      • No business processes and IT processes need to be adapted for transformation
      • No business processes and IT processes need to be abandoned for transformation
    • Products
      • Don’t need to learn and quantify how products succeeded
      • Don’t need to learn and quantify how products failed
      • Customer, employee, partner and vendor product usage has no relevance
    • Services
      • Customer experiences isn’t a priority to execute strategy
      • Employee experiences isn’t a priority to execute strategy
      • Don’t need to map the gaps of experiences
    • Technologies
      • Technologies can’t be used to execute strategy
      • Technologies can’t be misused to execute strategy
      • Technologies aren’t and can’t be ingrained into every aspect of executing strategy

Business Agility and Digital Transformation

What is Business Agility?

  • Business is “the activity of making, buying, or selling goods or providing services in exchange for…”
    • Corporations –> Money
    • Non-profits –> Social Causes
    • Education –> Knowledge
    • Government –> Citizen Services
    • Military –> National Defense
  • Agility is the “ability to move quickly and easily.”
  • Business Agility is the ability to move quickly and easily to:
    • Make products and services
    • Buy products and services
    • Sell products and services
    • Provide products and services

to employees and customers along with the ability to effectively and efficiently collaborate with partners and vendors.

What is Digital Transformation?

  • Digital is “electronic and especially computerized technology.”
  • Transformation is “an act, process, or instance of transforming or being transformed.”
  • Digital Transformation is the process of transforming:
    • How things are made
    • How things are bought
    • How things are sold
    • How products and services are provided
  • through electronic and especially computerized technology.

What is the Relationships between Business Agility and Digital Transformation?

  • All organizations are digital in one way or another. Some are more digital and some are less but fundamentally they utilize a mix of the following to achieve their desired outcomes and capabilities:
    • People who use technologies
    • Processes enabled by technologies
    • Technologies to capture and synthesize data
  • In order for your organization to survive and thrive in today’s hyper competitive business environments, your organization should have:
    • People who can quickly make decisions on how products and services are created, bought, sold and provided
    • Processes that reduce time between data capture to informed decision-making
    • Technologies that capture, manage and disseminate data quickly to decision-makers

Note that without Digital Transformation, achieving Business Agility is a hallucination!

Understand your Present to Create your Future

  • Do an honest and comprehensive analysis of how business is done currently
  • Holistically understand how current people, processes, technologies, products and services (business and technical) are affected by Strategies, Politics, Innovation, Culture and Execution (SPICE) factors
  • Determine if current capture of KPIs, SLAs and other metrics (e.g., employee incentives) are just for collection or are these measurements truly bringing change within the organization

SPICE Factors

While it is great to imagine and document your future, but any shortcuts you take in the assessing your present will come back to haunt you in the future!

Analysis

Today (Where you are)

  • Create a list of roles and responsibilities for everyone in your organization, partners and vendors
  • Map hybrid business processes that show people-technology interactions
  • Determine what data is being captured, managed and disseminated during people-technology interactions
  • Determine the relevancy of the data for informed decision-making
  • Assign a cost to each business process
  • Assess how quickly and easily your organization can respond to employee and customer needs
  • Determine the various obstacles that result in poor execution of strategy
  • Understand organizational and individual biases

Tomorrow (Where you want to be)

  • Eliminate overlapping and redundant roles and responsibilities that don’t provide value to your organization
  • Create governance, functions, teams and business processes that optimize use of data across people and technologies
  • Create metrics that result in effective decision-making and lessons learned to improve those metrics
  • Communicate effectively to eliminate any preconceived notions of your transformation journeys
  • Create test labs for all employees to test business models, enhance current capabilities and new capabilities
  • Create a new culture through norms, standards, communications and incentives and know that not everyone is motivated by the same things
  • Continuously self-evaluate your maturity level and make use of lessons learned

Asking Questions

  • Strategy
    • Who is affected by transformation?
    • What siloed/outdated/imaginary/undocumented processes are affecting strategic execution?
    • What technology and non-technology tools are used to make strategic decision?
  • Politics
    • Who is distorting transformation communications?
    • What processes and data are leading to transformation easily being vetoed?
    • What technologies decisions are empowering transformation?
  • Innovation
    • Who is assessing frontline employees, external customers, similar industries and different industries to bring innovation to the organization?
    • What processes are in place to raise people’s ability to contribute?
    • Are there technologies to test out new capabilities and business models?
  • Culture
    • Who is motivated to participate in transformation journeys?
    • What kind of processes are in place to encourage culture change?
    • What kinds of technologies are used to assess culture and changes?
  • Execution
    • Who is setting the expectation at all levels for the transformation journeys?
    • What processes are in place that obstruct strategic execution?
    • What technologies are in place that obstruct strategic execution?

Transitions

  • Organizational Structures
    • Optimize organizational structures based on a mix of functions, products, services and geography
    • Create formal and informal strategic linking through processes and coordination
  • Governance and Processes
    • Create governance structures and processes to evaluate how data can be captured, managed, modeled, assembled and deployed
  • People
    • Find people from top, middle and frontlines to champion transformation journeys
    • Show how transformation actually makes people’s lives easier
  • Program Mission
    • Views transformation journeys as an investment portfolio of multiple projects and operations
    • Connects business and technical operations to business capabilities and outcomes
    • Measures relevant metrics and abandon irrelevant metrics that cannot be connected to business value
    • Creates alignment of IT with non-IT functions (e.g., Accounting, Administration, Business Development, Customer Service, Finance, HR, Management, Manufacturing, Operations, Productions, R&D, Sales etc.)
    • Creates effective feedback loops across the organization

 

5 Questions to Ask About Your Organization’s Politics

Politics in an organization is about influencing others by using official and unofficial power. Official power comes from management titles while unofficial power comes from peers, juniors and even outsiders. Everyday in organizations official and unofficial power is used to: (1) frame problems, (2) influence changes and (3) make/guide decisions. This power can affect organizational structures, business processes, technologies and even innovation. Thus, it becomes imperative that organizations understand this power and how this power can affect organizational cultures. However, despite the strong relationship between politics and culture, most organizations are unaware, unwilling and/or unprepared to address it. The three main reasons politics is not directly addressed is because of:

  1. The inaccurate thinking that politics is always negative
  2. The fallacy that politics only happens at an individual’s personal level
  3. The inability to understand how politics can destroy/enhance capabilities

An organization’s politics is the total complex of relationships between people inside and outside of organizational boundaries. What this means is that people play politics even if they are unaware of it. While these people might have the best of intentions but their experiences/biases may or may not be best for the entire organization. By not keeping this in mind, organizations might not be able to self-assess if the IT vs. Business tension is a myth or reality, if the most optimized and continuously improving processes are present, if the correct technology is being selected for collective efficiency, if the right people are asking the right questions and if questioning the status quo is just a checkmark. In order to understand politics, the following questions need to be asked:

Strategic Perspectives on Politics:

 

Currently

In the Future

1. Who is incentivized at the executive level to understand politics? Who should be incentivized at the executive level to understand politics?
2. What governance structures are in place to address holistic vs. specific unit/function/team strategic needs? What governance structures should be in place to address holistic vs. specific unit/function/team strategic needs?
3. Where is technology being affected by politics? Where should technology affect politics?
4. When and how often political motivations are revealed? When and how often political motivations are revealed?
5. Why political understanding is critical to achieving strategic objectives? Why should political understanding be critical to achieving strategic objectives?

Tactical Perspectives on Politics:

 

Currently

In the Future

1. Who is incentivized at the middle management level to understand politics? Who should be incentivized at the middle management level to understand politics?
2. What business units, functional areas and teams are included to bring forth political implications? What business units, functional areas and teams should be made aware of political implications?
3. Where technology hinders understanding politics? Where technology might hinder in understanding politics?
4. When is the start and end of political motivations? When should be the start and end of political motivations?
5. Why political understanding is critical to achieving tactical objectives? Why political understanding should be critical to achieving tactical objectives?

Operational Perspectives on Politics:

 

Currently

In the Future

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

Politics and culture are two sides of the same coin and each lurking in the shadows or showing in broad daylight to change the direction of the organization everyday. To address this, (1) be transparent, (2) create an atmosphere of trust, (3) be genuinely helpful across business units, functional areas and teams.

Politics-Culture

5 Questions to Ask About Your Enterprise Content Management (ECM)

The term Enterprise Content Management (ECM) is used to describe the strategies, methods and tools to produce, share and capture information in organizations. Humans and/or computer systems use this structured (e.g., data in databases), semi-structured (e.g., social media) and unstructured (e.g., emails) information to make decisions that can improve the organization. Since every individual/team/group/unit/department produces and consumes information thus it becomes imperative that organizations start thinking about how to provide the right information to the right audience at the right time by taking into account how information flows holistically across the organization.

Organizations need to create the right balance between humans and/or computer systems to leverage information from internal and external sources. This balance comes from the understanding that humans and computer systems are both influenced by experiences and biases. The experiences and biases in computer systems emerge when humans decide (1) which data should be used, (2) how algorithms should use the data and (3) when to accept or reject the recommendations of the computer systems.

In today’s world, Big Data has captured the imagination of most organizations and how it can help improve them. Organizations are collecting more and more data everyday, writing algorithms and mining for patterns to use this data for descriptive analytics, predictive analytics, prescriptive analytics and even Artificial Intelligence. However, if an organization’s Big Data strategy lacks an ECM mindset and does not have mature data management governance processes in place then organizations would not be able to fully release the true potential of the information they continue to produce, share and capture.

To start having an ECM mindset for Big Data, organizations need to (1) identify the different structured, semi-structured and unstructured internal/external information sources consumed and produced by the organization, (2) identify all the obstacles in the smooth flow of information and (3) train all individuals to see all data as assets to be leveraged.

First, lets identify some of the internal and external information sources. Here is a non-exhaustive list to get started:

  • Accounting Software and Systems
  • Architecture Software and Systems
  • Artificial Intelligence Software and Systems
  • Analytics Software and systems
  • Architecture Software and Systems
  • Barcodes and Quick Response (QR) codes
  • Books and Blogs
  • Business Case Software and Systems
  • Business Development (BD) Software and Systems
  • Business Intelligence (BI) Software and Systems
  • Business Process Management (BPM) Software and Systems
  • Business, Analytics and IT dashboards
  • Cloud, Managed Services and Anything-as-a- Service (XaaS) Metrics
  • Computer Output to Lase Disc (COLD)/Electronic Report Management (ERM)
  • Construction Software and Systems
  • Consumer Electronics
  • Customer Relationship Management (CRM) Software and Systems
  • Customer Service Software and Systems
  • Databases, Data Warehouses, Data Marts and Data Lakes
  • Decision-Making Software and Systems
  • Delivery Software and Systems
  • Document Management (DM) Software and Systems
  • Document Software and Systems
  • Electronic Data Interchange (EDI)
  • Electronic Data Processing (EDP) Software and Systems
  • Emails, Instant Messages (IM), Web Chats and Mobile Chats
  • Expert Software and Systems
  • Enterprise Architecture (EA) Repositories
  • Enterprise Resource Planning (ERP) Software and Systems
  • Extensible Markup Language (XML)
  • Financial Software and Systems
  • General Administration Software and Systems
  • Global economic trends and reports
  • Governments, Colleges, Universities and Internal R&D Departments
  • Handprint Character Recognition (HCR) Software and Systems
  • Human Resources (HR) Software and Systems
  • Images and videos
  • Industry, Competitor, Partner and Vendor reports
  • Information Technology (IT) Software and Systems
  • Innovation and R&D Software and Systems
  • Intelligent Character Recognition (ICR) Software and Systems
  • Internet of Things (IoT) Software and Systems
  • Inventory Software and Systems
  • Investment Software and Systems
  • Legal and Insurance Software and Systems
  • Learning Management Software and Systems
  • Lessons Learned Software and Systems
  • Log Files and Incident Report Software and Systems
  • Manufacturing Software and Systems
  • Marketing Software and Systems
  • Network Software and Systems
  • Operations Software and Systems
  • Optical Character Recognition (OCR) Software and Systems
  • Optical Mark Recognition (OMR) Software and Systems
  • Paper and Electronic Documents
  • Paper and Electronic Forms
  • Partners, Vendors and Consumer Electronics
  • Payroll Software and Systems
  • Phone Software and Systems
  • Procurement Software and Systems
  • Procurement Software and Systems
  • Production Software and Systems
  • Production Support Software and Systems
  • Program and Project Management Software and Systems
  • Records Management (RM) Software and Systems
  • Retail Software and Systems
  • Robots, Software Robots and Robotic Systems
  • Sales Software and Systems
  • Social Media and Forums
  • Software Development Software and Systems
  • Supply Chain Software and Systems
  • Version Control and Release Software and Systems
  • Warehouse Software and Systems
  • Web and mobile applications
  • Websites, Portals, Intranets and Extranets
  • Workflow Management Software and Systems

Second, lets look at some of the obstacles to smooth information flows across organizations:

  1. Self-Preservation – People think that sharing information makes them vulnerable.
  2. Doubt – People are unsure of how much importance others would pay to their information.
  3. Repetition – Processes are not in place to know how many times the same data field is created, captured and shared.
  4. Awareness – Processes created in a vacuum don’t take into account why they were created in the first place and if they have run out of their usefulness.
  5. Imbalance – Too many or too few technology systems to capture information.
  6. Black Hole – Technology systems continue to ingest massive amounts of data without providing any direct and relevant benefits to the organization.

Lastly, to help individuals in considering the importance of data, (1) a culture of data as leverage needs to be created, (2) individuals should be empowered to use data to enhance and challenge the business models, (3) every individuals’ data success and failures should be encouraged and shared so that lessons can be learned and (4) there should be quicker and easier ways for individuals to sift through historical and new incoming data.

For an ECM mindset lets understand the complexities, intricacies and subtleties of data –> information –> knowledge by asking the following questions:

Currently

In the Future

Who is incentivized at the executive, middle management and frontline individuals’ levels for making information-based decisions?

Who should be incentivized at the executive, middle management and frontline individuals’ levels for making information-based decisions?
What happens to information when it is produced and consumed? What should happen to information when it is produced and consumed?
Where are the entry and exit points of data? Where should be the entry and exit points of data?
When does information become irrelevant? When should information become irrelevant?
Why all information is important?

Why all information should be important?

When you are asking yourself the above questions, keep in mind a survey of data scientist that revealed that 80% of the time in data is spent on collecting data sets, cleaning the data and organizing data. The reason for this is (1) there are no comprehensive lists of all the relevant data sets available inside and/or outside organizations, (2) there are no agreed upon consistent international standards on how data sets should be published and/or obtained, (3) there are no substantially automated ways (yet) of how to get rid of all junk data and (4) holistic global data exchange standards across industries don’t exist. Now, imagine if your organization had an ECM mindset, what benefits would you reveal?

ECM Mindset

 

5 Questions to Ask About Your Customer Relationship Management (CRM)

Customers are the lifeblood of any organization. In order to capture and track customer information (e.g., demographics, buying habits, satisfaction and loyalty etc.), organizations use information systems called Customer Relationship Management (CRM). CRM is utilized by sales, marketing, customer support services and other organizational functions to capture new and potential customer information from multiple sources (e.g., websites, email, phone calls, chats, customer lists, social media, government data etc.) into a single source of reference.

CRM provides the organization to have “one voice” when addressing customer-related activities and provide internal organizational consistency. However, a standalone CRM is useless unless it is augmented with the right people, efficient processes and effective technologies. From a people’s perspective, customer relationship development becomes the responsibility of any individual who interacts with the customer at any level. From a processes perspective, enhanced customer experiences should be the goal. From a technologies perspective, information systems should be able to quickly capture customer information, be easy to use and always be available anytime anywhere.

In order to understand if CRM is helping or hurting your customers, ask the following questions to assess what is happening and what should be happening within your organization:

Currently

In the Future

Who is responsible for customer relationships? Who should be responsible for customer relationships?
What happens when customer relationships do not pan out? What should happen when customer relationships do not pan out?
Where does customer relationships take place? Where should customer relationships take place?
When are customer relationships developed? When should customer relationships be developed?
Why customer relationships are important? Why customer relationships should be important?

When you are asking the above questions across all levels of the organization, take into consideration the direct and indirect (e.g., word of mouth, organizational reputation, (ex) employee feedbacks etc.) ways of developing customer relationships. Keep in mind that customers are there to buy into your ideas, products and services and thus they need to trust you at some level. Customers should be able to:

  1. Trust that your organization will be transparent about how information is collected, used and distributed
  2. Trust that your organization will keep information safe
  3. Trust that your organization will provide the most efficient process for resolving issues
  4. Trust that your organization will provide customized services
  5. Trust that your organization will not try to sell them something they don’t need

5 Questions to Ask About Your Customer Relationship Management

SPICE for Business Transformation

Imagine an organization where people, business processes, products, services and technologies are in sync. Where an organization performs at its most optimal levels and miraculously everyone is happy and contributing for the wellbeing of the organization. No, I am not talking about a fictional scenario in a far off land. I am talking about an organization harnessing all the power of its capabilities to achieve Business Transformation. And I believe that there is a lot organizations can achieve if they view Business Transformation as a holistic and all-encompassing endeavor. So, today I am going to talk to you about how SPICE can make your organizations better.

slide02-about-me

I help organizations pursue a better version of themselves. In this pursuit, I collaborate with front-line employees, middle management and the C-suite to understand issues beyond the obvious so that individuals and organizations can achieve their objectives. Over the years, I have held many titles but the underlying theme is to always do and look for Business Transformation opportunities.

slide03-what-is-bt

Business is “the activity of making, buying, or selling goods or providing services in exchange for money” for corporations. For non-profits, business is the pursuit of social causes. For educational institutes, business is the pursuit of knowledge. For governments, business is the pursuit of citizen services and for military business is national security.

Transformation is “a process”.

Now, that you have a baseline understanding of what Business Transformation is and how it helps, the next time when you hear this term you would be aware that it is not just another buzzword and not just another business initiative that would disappear with time.

slide04-meet-john

Now, imagine a person named John who is walking through an unknown and dark tunnel with just a flashlight in his hands and he is carrying some baggage behind him. John does not know what is in the baggage. He continues to use the flashlight to look ahead to find his way out. His resources are limited. Thus, his objective is to reach the correct end of this unknown and dark tunnel as efficiently as possible.

Would John make it?

According to some experts, if this person were an organization pursuing Business Transformation then he would have failed 70% of the time. Think about this for a second, this means that only 30% of Business Transformation endeavors are able to achieve their full potential. Why is this?

slide05-business-vs-it-1

While there could be a variety of reasons for this high failure rate, I have observed that the number one reason for this is related to a typical conversation within organizations.

How many times have you said or heard someone say, “the business” wants this and “the business” wants that and that “the business” doesn’t understand that systems cannot be developed overnight. Ingrained in this sort of thinking is the idea that somehow IT is different from “the business”.

Somehow there is this “Us” vs. “Them” mentality.

If we think about it, all organizations take advantage of technological advancements. Paper, which was once considered a technology itself, is now used in every organization today in one way or another. Today, all organizations are digital in one way or another even if they don’t realize it yet and to think that they are not stems from this “Us” vs. “Them” mentality.

slide06-business-vs-it-1

Perhaps it is time to change the conversation! Perhaps it is time to think about IT as not something that is outside of “the business” but it is part of “the business”. To have this conversation, there has to be mutual understanding that neither “side” 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 I started assessing and improving organizations in 2003, I didn’t know what it was called. All I wanted to do was help organizations apply the full potential of their capabilities beyond what they perceived them to be which included but not limited to IT capabilities. Over the years, this took on new meaning for me as the conversation quickly changed from just doing my duties to fundamentally reshaping organizations inside out.

A couple of years ago Business Transformation, IT Transformation and Digital Transformation started to pick up steam and it took off. A lot more individuals and organizations started to pay attention when they saw their bread and butter business models being shattered in light of the new economy. Startups like Uber took on the Taxi Services around the world and now are expanding into other means of transportation as well. In response, Taxi Service companies pushed back hard by either through legislation and government policy or creating their own taxi mobile apps. If the taxi service companies think that they can compete with Uber with just their own taxicab apps then they are hugely mistaken. This is just one example that illustrates how one industry became complacent and within a short period of time a competitor emerged with a new business model that directly tied its operations to technology and the rest, as we know it, is history.

So, if you think about it, Business Transformation is not a standalone activity but a holistic one. Thus, if the people, business processes, products, services and technologies are ignored or not paid enough attention then Business Transformation becomes just another pipe dream.

slide07-business-transformation-5-ws

As I see it, organizations that are committed to figuring out the Business Transformation journey have to ask 5 fundamental questions from an internal perspective and an external perspective. These questions are:

  1. Who is helped by Business Transformation efforts? Is it management? Is it employees? Or maybe its customers and shareholders? Perhaps answering this entails understanding customer experiences issues and long-term value propositions to shareholders.
  2. What does Business Transformation teach us? Is it better internal communications? Is it Governance and Standardization? Or is it Branding? An organization that showcases and does actual Business Transformation has better stories to tell about improvements and thus can attract customers who see value in an organization that is trying to do better.
  3. Where does Business Transformation start? Does it start in IT? Does it start in Marketing or Operations? Or does it start with customers, vendors and partners? When a customer comes to you and requests a system to be developed, do you ignore this request since your organization does not develop these types of systems or do you explore this further and figure out how you or a partner could help your customer?
  4. When should Business Transformation be considered? How about when an employee has a conversation with a customer? How about when established competitors are eating your lunch? Or should it be considered when new innovations and methods arise?
  5. Most importantly, why do Business Transformation in the first place? Is the organization looking to become optimized and have better cohesiveness? Or is it better long-term value and creating positive societal ripples such as the creation of Corporate Social Responsibility groups that look into Green Technologies to save electricity and in turn save the plant as a consequence.

These are all important questions to ask before, during and after the Business Transformation journeys. But if there are no effective feedback loops then most Business Transformation journeys would be just a one-time initiative and not something that makes organizations become self-improvement entities.

slide08-so-what

By this time, most of you might be thinking “well ok I get it that Business Transformation is more than what meets the eye but so what?!!”

What does Business Transformation really have to do with Business Architecture?

A valid question. I want you to think about this…

Do you see Business Architecture as just a plan, as just a design or a model, maybe perhaps a guide, or a way to create documentation, or for the purposes of alignment? Or do you see Business Architecture as a way to accomplish a vision and even to improve an organization’s mentality.

The fundamental reason we do Business Architecture in the first place is to fully leverage the technical and non-technical capabilities of the organization to transform itself. You don’t create a plan or a model or a guide to just document it but you do create it so that these insights can be used to make the organization better otherwise why do it in the first place anyways!

Thus, Business Architecture and Business Transformation are highly intertwined. An effective Business Architecture would open up avenues for Business Transformation so that when it comes to responding to market demands, strategy does not get lost in translation when it comes time for execution.

slide09-spice

I have spent many years recognizing patterns in my own engagements, academic literature and case studies and have determined that there are fundamentally 5 factors that affect the journeys towards Business Transformation.

These 5 factors are Strategies, Politics, Innovation, Culture and Execution or simply called the SPICE Factors.

I represent these factors in a pentagon shape. On its edges are the 5 factors which start from Strategies on the left hand corner and going clockwise until Execution. In the middle of the pentagon shape, there is a loop in yellow indicating that Business Transformation is a continuous process and not just a single project or initiative. Besides each SPICE factors there is a performance indicator to represent that each of the factors have to be measured. This measurement can entail Key Performance Indicators and even Service Level Agreement checks.

The red pentagon indicates where the organization is today (aka the current state) while the green pentagon indicates where the organization wants to be tomorrow (aka the future state). In the middle, the yellow arrow from the red pentagon to the green pentagon indicates transition and indicates what the areas that need to be taken into consideration namely people, business processes and technologies. By extension, these areas influence the products and services provided by the organization.

I am going to go through each of these 5 factors and make you think about how each of these factors can affect Business Transformation within your organizations.

slide10-strategies-1slide11-strategies-2slide12-strategies-3

The first SPICE factor is Strategies. Strategy is a careful plan or method for achieving a particular goal usually over a long period of time. Depending upon how far out your organization can think, a long period of time can be 1 year, 3 years or even 10 years. Of course as you go further out in time, your strategy gets complex as you might not be able to anticipate what is going to happen.

There are many levels of strategies within the organization such as Financial Strategy, Marketing Strategy, Operations Strategy and IT Strategy to name a few. Additionally, strategies can be top down, bottom up, cross-functional and hybrids. But fundamentally, I put strategies in three big buckets namely Organizational Strategy which affects Executives (e.g., performance compensation, M&A etc.), Team Strategy which affects Middle Management (e.g., Operational Improvement, Tool Selection etc.) & Individual Strategy which affects front-line employees (e.g., career trajectory, hiring etc.).

In addition to these strategies and the types of people that they affect, it gets more complex and the real relationships actually look more complicated. Upon further depth, we realize that all of these types of strategies have an internal perspective and an external perspective.

For example, from an internal perspective, organizational strategy looks at things like the type of organizational structures such as functional, matrixed, product-based or hybrids. Depending upon what structure your organization has or wants to evolve into, there would be repercussions. In a functional organizational structure, focus on areas of expertise is increased but what is lost is the cross collaboration which leads to silos. On the other hand, in a matrixed project-based structure, the individuals are only needed for the duration of that project and then they go back into a pool to be picked up or not. What incentive do people have in this type of structure to get the job done efficiently? Something to think about.

Depending upon what the end goal is, these strategies can

  1. Affect performance compensation for executives
  2. Create or destroy middle management fiefdoms
  3. Affect Hiring, Training and Layoff of frontline employees
  4. Create and destroy bloated expectations

The last point is interesting since a strategy with bloated expectations or no expectations at all can lead to misalignment namely between IT Strategy and other Organizational Strategies. Lets think about this…

  1. Was this misalignment always there or somehow it evolved over time?
  2. Why did this misalignment happen in the first place?

A root cause understanding from technical and non-technical views can reveal something that might have been taken for granted. For example, IT teams creating and acquiring tools that have no relationship to the Organizational Strategy or perhaps revealing the purchase of technology by non-IT teams which again has no relationship to the Organizational Strategy.

In short, there are 3 key points to consider for Business Transformation in terms of strategies:

  1. The real an unreal organizational structures matter more that you might like to believe
  2. Plan to plan and measure performance both at an organizational level as well as at individual levels
  3. Alignment is a two-way conversation that is not a top-down demand but should be a collaborative approach

Having said that, as corporate citizens of the organization, we have to realize that Strategies are not shelf-ware.

slide13-politics-1slide14-politics-2

Merriam Webster defines politics to be the complex of relations between people living in a society. For our purposes, here society would refer to your organization. No one wants to talk about politics in the organization and yet there are decisions made everyday that are political in nature. 

Politics in organizations is about power; the power to frame a problem; the power to influence decision and the power to make decisions. While we are all aware of the official power that is the power of your superior within the organization but most have also encountered unofficial power where regardless of the title an individual is able to persuade others. Some people call this leadership while other call it manipulation.

In organizations, while it may seem that all similar titles should hold the same power but that is certainly not the case. Even with VP titles, not all VPs are the same. Some have more power based on the number of people they manage, based on the revenue generated by their teams and even based on the relationships they have with others within the organization. So, the next time you look at an org chart and see all VPs at the same level you will know that an organizational chart is just a fairytale representation and not reality. Why this matters? This matter because the next time you are looking for champions to support your projects keep a vigilant eye on who has power and how much of their power is used to make decisions.

The display of power is more relevant today in the age of big data than ever before. As you know, most Big Data initiatives revolve around gathering massive amounts of data and then finding patterns. The thought behind is that once we can figure out patterns then we can make better decisions. This however is not the complete picture. Beyond the usual Vs of Big Data, I believe there are 4 Vs that are critical but missing in most conversations.

These Vs are Vitality meaning how important the data is, Versatility meaning how data could be applied to various scenarios, Vocality meaning the supporters of data-driven approaches and lastly Veto meaning the ultimate authority to accept or reject big data conclusions. As you might have noticed, Vocality and Veto are about Power.

The idea of power also applies when you are creating an ERP System. The executives who have official and unofficial powers can become champions or become obstacles. One way to remedy this is to get them involved early on; have a discussion, find out pain points and get feedback. So, when it is time to standup an ERP system, the people have been engaged from the begining and it is not a surprise. Also be prepared that business process optmization should be done first prior to any large scale systems because otherwise all you are doing is automating broken business processes and thus when it is time to optmize them it would become much harder to do so. Other examples of displaying of power would be in Cloud Computing and Shadow IT.

In short, there are 2 key points to consider for Business Transformation in terms of politics:

  1. The official and unofficial power considerations matter and can make or break a project
  2. Create a Power Map to know where a power resides, assign quantitative values to them to set a baseline and then verify with projects that those baselines are correct

Remember, politics needs to be understood especially in the case of organizations.

slide15-innovation-1slide16-innovation-2

Innovation is defined to be the act or process of introducing new ideas, devices or methods. Innovation can be a new product, a new way of hiring people, a new way of doing business processes, a new service and it can also be a new technology. If there are so many ways of being innovative, why organizations and individuals struggle in this area?

For most, innovation is something that is considered difficult since people don’t know where to start or how to continue. Innovation comes from inspiration and I believe that organizations and individuals can be inspired by things around them. The left picture represents the possible sources of organizational inspiration for innovation. These sources include:

  1. First, the organization’s internal customers. By internal customer, yes I do mean anyone who is within the boundaries of your organizations and yes that includes your employees. Employees who can see beyond the immediate needs and are able to connect the dots should have an avenue to express it. Thus, there should be some sort of innovation process that captures the wisdom of these employees.
  2. Second, the organization’s external customers. We are all aware of the external customers who are outside the boundaries of your organization but they too can provide feedback to improve your products and services.
  3. Third, within your own industry, which includes looking at what competitors, partners and/or startups are doing something that could be applied internally.
  4. Fourth, outside your industry. Think about the field of Project Management that emerged from the construction industry but now it is used in Software Development.
  5. Lastly, the integration, customization and combination of inspirations from the above four ways. Think about the evolution of writing from cave walls to stone tablets to paper and then eventually to computers.

The picture on the right represents the possible sources of individual inspiration for innovation. These sources include:

  1. First, your direct circle of influences namely your friends and family. Have you considered talking with them about problems that you might be facing and what they would recommend?
  2. Second, your indirect circle on influence namely your co-workers, educational and professional associations. Perhaps what you are having trouble with they have already solved or at least they can give you a nudge in the right direction.
  3. Third, increasing your understanding of areas that interest you which includes reading books, blogs, news articles and talking to people who have experience in that area.
  4. Fourth, increasing your awareness of areas that you are not that knowledgeable in which includes different types of readings, experiencing cultures beyond your own, conversation with diverse people, observing the plant kingdom and observing the animal kingdom.
  5. Lastly, the stitching, applicability and combination of inspiration from the above four ways. Think about the invention of Velcro by observing cockleburs in the plant kingdom.

Thus, it would be naïve for organizations to think that they cannot fully take advantage of innovation at the organizational and individual levels.

They have to remember that innovation is the lifeline.

slide17-culture-1slide18-culture-2

Culture is a way of thinking, behaving, or working that exists in a place or organization. Often times when there is a discussion of culture within organizations we immediately think this is something fuzzy and it is only equated with people. While people definitely create a culture but there is more to this than meets the eye.

You see culture is not just one thing but a combination of things. Most organizations don’t have one culture but they have a mix of sub-cultures. The way people are treated creates a sub-culture. For example, how are people within the organizations at all levels incentivized and rewarded? The way people dress creates a sub-culture. For example, if executives dress differently vs. non-executives this visibly creates the culture of in-crowd vs. outsiders. The posters in public locations, the discussion between Mac. Vs. Windows, IT behind closed doors and even an individual can create sub-cultures within an organizations.

All of this matters because culture is not just having a foosball table or other “perk”, it is creating an environment where employees are appreciated not just by talk by the executive but by tangible actions through incentives, rewards and performance goals.

Culture is at the base of the SPICE factors for a reason.

Culture can make a strategy just another paper-exercise, culture can drastically affect politics, culture can resist organizational innovation, and culture can prevent effective execution of operations and all of this means that culture can diminish any hopes for Business Transformation.

slide19-execution-1slide20-execution-2

Execution is the act of doing or performing something. If you notice in the above-mentioned factors, all of them need to be executed; measured and performed otherwise all we are doing is just wasting our breath and paper. As I see it, execution also has an organizational level and an individual level. Both of them are highly intertwined. If there are no structures and processes to determine and quantify execution issues then how would you know where your baseline is and if you don’t know where your baseline is then how would you know if your Business Transformation efforts have been successful or not.

Note that execution is highly based on biases and perceptions of organizations and individuals as discussed earlier. They have to be considered and if needed be persuaded to be changed.

Rewards and incentives can not only change behavior but it can enhance cohesion and collaboration across the organization.

Lesson learned are useless when all they are is a paper exercise of capturing what happened wrong or right but not an input for other projects so that they can avoid similar mistakes or repeat successes.

slide21-it-all-comes-together

All the factors that have been discussed are not something that are done in isolation but they all come together to create an organization that is able to transform it self based and stay ahead of the game.

slide22-survey

As we can see from the live survey, the most important area for Business Transformation is People and the most important factor for Business Transformation is execution.

slide23-meet-john-again

Now, let’s go back to our dear friend John (aka your organization). With his understanding of the SPICE Factors and his awareness of how the SPICE Factors can affect people, business processes, products, services and technologies, don’t you think he would have used his flash light to find out what was in the baggage. Perhaps some of the baggage was dead weight that he needed to get rid of and perhaps in the baggage there were additional resources he could use such as food, liquids and even a map. But the only way John would find out would be to look behind and just check his baggage!

All I am saying is…help John find his way and help him succeed!

slide24-summary

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.