Delivering successful transformation projects in healthcare
This article proposes a new approach to delivering consistently successful improvement and transformation projects that are accepted by all involved — sponsors, stakeholders, staff, IT, patients/families, physicians and other clinicians.
Today, project success is judged by many more people and factors than at any time in the past. This is partially the result of a perforation of business and clinical silo barriers and the availability of new and powerful application generation technology. These advances are causing a revolution in the expectations of patients, their families and the hospital’s physicians. The limitations of the past are no longer being tolerated and many hospitals, insurance companies and companies in virtually every industry are feeling this push. The simple fact is that this evolution is causing real changes in the operation of business and the way healthcare institutions operate and compete.
Given the investment that many are making in moving to operate in this new consumer enabled culture, it is critical that projects succeed — and not simply in the opinion of IT or any single group. To help adjust to this reality, we propose that projects start with the identification of all who will be affected and include their perspectives in formally defining success — based on a negotiating and collaborative process. This step feed into a definition of the foundation considerations of the project and sets the conditions that allow the project to succeed.
Success is then supported through the use of business process management concepts, methods and techniques and technology. Leveraging both iteration and simulation provided through the BPMS technology, the solution can be proven successful from a variety of perspectives before it is released. In this way, all involved formally declare the project’s success based on performance analytics and a beneficial influence on their work.
Success is thus assured — as is acceptance.
In addition, the ability to quickly evolve the solution in the future due to regulatory changes, clinical changes, business changes, competition and more, will have been put in place. These changes become further iterations of the models based on formal requirements as defined collaboratively among the new group of affected managers, staff, patients/families and doctors. And, the process repeats to find and deploy the most optimal solution — based on performance measurement and ease of use.
BPM — Business Process Management: an approach to business evolution based on process and its controlled change to deliver improvement or transformation.
BPMS — Business Process Management Suite: A set of integrated tools that support business flow modeling, business rules capture, business metrics capture, data capture, screen/report design, design iteration and simulation, and application system generation.
BPMS supported BPM — Where a BPM techniques, approaches and methods are supported by an automated tool (a BPMS).
Business Architecture — The design of the business operating model in support of strategy and business opportunity.
Stakeholder — The person or persons who have an interest or concern in the change and thus the project outcome.
Sponsor — The person who is responsible for the project’s outcome and who serves as the final authority on project providing leadership, defining required benefits/outcomes, approving budget, approving change designs, and approving project changes.
Transformation projects — large, complex mission critical projects that change large parts of the business and clinical operations.
Improvement projects — smaller more focused projects to eliminate a problem, make a specific improvement, or automate a part of a business units operation.
Managing project outcome satisfaction — delivering consistent success!
Are those affected by projects in your hospital usually satisfied with the project’s outcome?
Do projects really deliver measurable improvement — in the view of a majority of people in clinical, business, consumer and IT areas?
For most of us, success has always been simply to fulfill the list of requirements defined in the project’s request/charter/statement of work. If all the requirements have been checked off, the project is finished and if the solution’s delivering each requirement work, the project is a success. This measure is applied to all types of projects and has gotten us to where we are — solutions are close enough where we can generally make them work.
But today that simple view is no longer acceptable. It is now as outdated as much of our technology. The fact is that neither one fit very well into the world we find ourselves part of today.
We have seen many cases where initial satisfaction with a project’s outcome changes as those affected begin to use the solution and complain. We have also seen where all requirements have been met but the solution causes more harm than good.
I recently sat in on a project’s solution acceptance meeting at a major retail pharmacy. The VP of IT was there because this was their first big project using a Business Process Management Suite (BPMS). He was beaming and started the meeting saying how they had delivered all the requirements and that IT considered the project to be a resounding success. The VP of the business area stopped him after a few minutes and asked if he was talking about the same project they had come to discuss. The VP of IT was now a little leery, but said, that it was. The business VP then told everyone that the project was a failure and that he had come to the meeting to ask that it be backed out and that the work returned to its former operation. The problem is that IT sent people to hold a few workshops, collected requirements, and had them signed off on. While I look at that approach as archaic, IT was happy — they had requirements and they designed, built, tested and delivered that solution. But, they didn’t consider what it did to the work and the way people had to use the solution. It actually caused more harm than good. The fact is that any solution can be based on a hundred different ways of changing the business. Some help, some don’t. Some place barriers between the company and the customer and some can help the relationship. The problem is that the old ways of silo solution development don’t work.
Collaboration — reaching across the organization silos
The fact is that business approaches and the way companies need to work are evolving — and we are learning more and evolving more every day. A big change is collaboration and the acceptance by most managers that island silos need to open their boarders — they are really part of a larger process or processes. The changes this evolution in approach are causing are both obvious and subtle. For example, this weakening of organization silos due to collaboration and the growing use of BPM concepts and BPMS technology, the number of stakeholders and concerned managers has increased significantly and the need to reconsider how success is viewed and determined has changed.
In hospitals, this journey can easily be traced back to physician teaming. That teaming concept has now expanded and has caused solid silo boarders to perforate and different disciplines to begin working together — in reality, not just in name.
Focusing on this opening of silo boarder and collaboration, we find that the number and nature of stakeholders has changed. It is no longer sufficient to simply deliver a solution based on checking off requirement. This is true for IT, it is true for the business operation and it is true for clinical activities.
So, today success must be viewed from multiple perspectives — each unique to a different stakeholder or a person/group that will be affected by the solution and its changes. This requires the project sponsor, manager and team to expand their view of success beyond the obvious one or two disciplines in those directly involved and beyond the perspective of the person or group paying for the project. It requires that all stakeholders and affected mangers and groups be identified and included in a collaborative group that directs the outcome of the project. But, while necessary to avoid issues after the delivery of the solution, it is not easy to do — that is one of the reasons it is often avoided.
Have you ever seen a project that was declared a success, later after it has been used for a while be declared a failure? Have you seen solutions that IT considered a success but the business or clinical user hated? Why do you think that happens?
The fact is that success today starts with the identification of all those who are involved and then defines through consensus building a composite view of the project’s outcome and what will make it a success. This then leads to an agreement on how “success” will be measured and what improvement will be considered to be a success. This is the tough part. The participants in this collaboration will have different:
Ideas of what problem or problems the project is trying to fix
What the problem or problems mean to them (impact) — this will differ from manager to manager
The priority that will be given to fixing the problem or problems
What the solution will touch and how it will be scoped
How the solution will need to function — how it can improve their operations (the size and shape of the solution box)
Their personal involvement and the involvement of their managers and staff
Acceptable changes to their applications and how they interact with patients, families, physicians, and other business areas in the hospital
Federal reporting requirements
Finding these considerations and more during a discovery process and then confirming it will take time, but it is critical in building a model of what it will take to be successful. This definition of success is the key in any real hope of consistent accepted solutions. It move the evaluation of the solution and the declaration of success or failure out of the realm of perception and personal “discipline or political bias” to measurable targets that can be proven to have been met.
This definition is also the foundation for making all affected by the possible solution, think of how it can and should affect them, what they are willing to change and why, what they need to get from the solution and how it will impact their operation. This is a no-surprise approach.
I have found that the evaluation of success needs to be tied to delivered, measurable, outcomes. These fall into at least five categories.
- Improvements in the business operation — quality, cost, speed of operation (cycle time), ease of interaction with patients, family and others
- IT applications and/or infrastructure enhancement — new function and feature, speed, data quality, reduced cost
- Improvements in the way the IT applications interact — interface quality and speed, data delivery, data update, data access ease
- Improvements in the way people can interact and in the way the interactions are supported — easier to use, more flexible, saves time over old way of interaction
- Improved ability to support profitability and legal compliance/reporting
In addition, some add in risk reduction in change and flexibility in making faster low cost improvements.
The outcome is that success can be measured and delivered from the perspective of all involved.
Following the identification of participants and the definition of success, you have the framework needed to succeed. But, to leverage this framework and actually deliver successful outcomes, it is necessary today to build the right foundation for the project. Experience in numerous projects and project rescue efforts, has shown that a leading cause of failure is not taking the time to set the right foundation for the project. Too many projects skip this step to save effort and cost, and just “begin” with a charter (many times this is also skipped) and then go right into workshops or interviews to collect requirements. Given the drive to reduce project cost and time, this “jump right in” approach has often been necessary, but it also seriously increases risk.
The creation of a good foundation focuses attention on:
defining who will be involved in the project — and their role
understanding how all the differing participant perspectives on the goals and outcomes can be brought together to form a common vision of the outcome
identifying how that outcome can be measured to prove success
the technology that will be used (such as BPMS or traditional programming, simulation and technology communications approach)
defining the constraints that will need to be considered (IT, timing, etc.)
agreeing on how the project will be controlled — methodology, governance
This also includes the identification of the location/distribution of the team, how it will work together and how management can be engaged.
Components of this foundation are shown above in the “Project Foundation Model”. These components will be customized for each hospital, department, project and IT environment. Once customized, this foundation will provide a foundation for success.
In the past, business activity change support generally meant the application of some type of automation. However, history has proven that the past approaches have often failed to yield consistent results and have required the addition of staff to address improperly automated business activity — white space work. This “adjustment” needed to support business change was accepted. Today it is not.
BPM has changed the game. It forces people to consider change at as affecting a process or a defined part of a process in improvement. It also requires that change be viewed based on its impact on the resolution of a problem or the delivery of an opportunity based change — from the perspective of those it will affect. Consideration of successful change is thus not limited to the business unit directly involved, but includes the downstream work that is driven by that business unit. This addresses and eliminates the age old “ripple effect” that has caused problems and weakened operations.
BPMS has enabled the broad application of BPM concepts to business transformation and improvement, and taken business flexibility and evolution to a whole new level. But, it has also opened new needs in building our perspectives on how any company or business unit should evolve and who should be involved in that evolution.
Framework for Change
In this move to optimizing business change, companies are struggling with fundamental concepts. Should change be organized and coordinated throughout the company to help deliver strategy? How do we leverage needed cultural changes from things like social and mobility computing to reach and interact with customers? How do we really look at process and traditional organization? Can we spend the time and money needed to build flexibility into the company? How do we deal with our people? What do we need to change to improve the way our staff looks at customers and interacts with them? Are we interested in short term profit or do we take a long term view?
The diagram “Considerations in building and evolution plan”, above, shows the major components that need to be considered when looking at change and how you want to address it within the context of your company.
Starting with enterprise level concerns, we can focus on the market, how it is changing, and how the company than thrive in the changing market environment. For the customers in this market, we can then look at perspective and value. We can also focus on keeping customers while growing the brand and increasing the company’s share of the consumer’s spend. With this insight we can them look at the strategy needed to deliver company goals given the market and the customers Sr. Management wants to focus on. For example, will the company focus on high volume low, margin products or low volume, high margin products — some people like inexpensive cars and some will by high end cars. There is a market for everything, but each buyer group requires a different strategy, different interaction standards, different internal company operational activity and different ways of reaching and selling to the prospects.
Once the strategy is in place and the customer defined, the business capability model can be created to make certain that the right capabilities are available to the right people at the right place and time. This delivery is based on process, talent and the technology support that enables interaction to take place. Finally, recognizing that the operation will need to change and flex as the mark place changes, Sr. Management will need the financial and performance analytics to look at focusing change and guiding the evolution of the company.
This approach aligns strategy and its execution and provides the vision needed to business operation improvement and in places transformation. The vision is critical because it defines the context for the operational evolution and the direction that change should take — including improvement prioritization.
This alignment is an important part of a project foundation as it provides context for determining the most important parts of any change and thus the parts that should be measured to prove success.
Success is no longer strictly an end of project declaration
With BPM and BPMS supported BPM it is very possible for a project to take a different path than the traditional business or IT project of the past. Today a solution may be broken into components and evolve as core components are released to solve problems and change the benefit realization model. This approach allows the “end state solution” to begin modestly and evolve with the continuing delivery of parts of the solution until it is fully delivered. This approach is like building a puzzle. You may build it in parts and then put the parts together to create the completed picture. This approach provides flexibility and allows very complex projects to be divided in less complex components — limiting cost and risk. The end outcome is actually stronger and more attuned to the business in this approach as it allows the team to learn with each component and take advantage of this increasing business area experience in the design of all remaining components. It also allows early components to be iterated and adjusted based on this growing understanding of the business, its customers, its operation and its IT applications.
A process perspective — Business Process Management
Significant change, such as transformation projects need to begin with strategy. More focused, smaller improvement projects can start with process or sub process. In both cases the starting level provides the context for the change and helps define the scope of the project. Also, in all cases, the change should support some element of strategic delivery.
Although there are several models of BPM levels and Business Architecture level models, few combine both. However, in reality, they fit together to deliver both transformational and improvement change that aligns to strategy. In this model, strategy is defined based on the outcome or new business operation that it will require to be implemented. This is level 1 in the following model.
This picture of the future business operating model in turn defines the capabilities that will be required and through them, the functions that the new operating model will need to support. These capabilities can be complex since they include business activity, IT, manufacturing production, legal, financial, customer interaction and more. This list in itself is not that complex, but when the list is put into a matrix of capabilities vs. function it becomes difficult — many capabilities apply to multiple functions — creating capability versions.
Business functions are them are then aligned to the sub processes that support them. The sub processes are performed through one to several business units where the work is actually performed. The work is performed in work flows which aggregate work steps into activities — and shown in their relationship to one another — workflow.
For repetitive work, activity can be defined in scenarios which are always performed in the same way under certain conditions. At the lowest level are the tasks which a person performs. Application context and flow is shown at the workflow level with activities and the application requirements are provided at the task level where detail is provided.
The importance of this model and similar Business Architecture and Process hierarchy models is that they show the relationships between the various levels of operating detail in a company and allow managers to look at the operation at the level of detail best representing the topic and the discussion. They also show management what levels of detailed information should be available and how that information is broken into lower levels of detail.
When considering collaborative discussions, these models help the participants understand what they are working with and how to define the scope of the project. It also helps them understand how any transformation or improvement supports strategy and what other parts of the business the change may affect. In this way, these models help frame the project and its outcome — thus setting the foundation for the identification of involvement needs and the definition of success.
Iteration, simulation and success
With BPMS supported BPM, project teams are able to identify performance measurement formula and imbed it in the process flow or at a lower level of detail, a business unit’s workflow models. These measurement models are tied directly to the delivery of stated success criteria and standards and may or may not leverage Six Sigma measurement and analytic models.
The project team should begin the definition of current operating volumes and error with the “current state” business models — also known as “As Is” models. In most companies this measurement will need to be created and entered as an “add on” to the current state models. However, this addition is critical in actually defining the level of improvement of the new solution over the present workflow. It is accordingly recommended that this performance measurement be imbedded in the current state models and tested to gain acceptance by those performing the work today.
Each “future state” or “To Be” new design model should have this performance measurement built into the design. Once completed, the new design model will then be run in simulation and the results compared against the target improvements. The simulation will also produce analytics that will point to further improvements of the design. The design will then be modified and rerun in simulation. The analytics will again be analyzed to find further improvements. This process of design, simulation, analytics analysis and redesign is referred to as iterative design. This is a key benefit in BPMS supported BPM.
This simulation/iteration cycle allows project teams to assure that all requirements are met and that the solution is as optimal as possible — given the constraints that must be dealt with. However, this is still only a single view of success — the technical view.
Once this view has been proven as success through measurement, the solution’s needed interfaces will be built and tested. This is a second technical view — the interface and data view. Testing here is comprehensive, assures that data movement is good and data quality is acceptable.
Following the completion of these technical views, the solution should be placed into a “model office” testing environment where staff can work with it and help evolve the “user interface” — the placement of screens, the placement of data on the screens, the usability of the solution and an assessment of the actual operational improvement of the solution. This will assure a business success. It can also assure a legal and a financial reporting/compliance success.
The final test of success is the patient/customer/family view. There are different ways to approach this test, but it is critical that the solution be patient friendly and easy for all involved to use. It should also be tested to assure that the solution provides the information each group will be looking for. This test drives further solution design iteration and simulation until acceptance has been formally assured by all involved.
This extra level of testing and assurance testing is necessary today because business operations are different, patient expectations are different and the technology that is available is changing the way hospitals compete for physician admissions and patients.
Every day hospitals invest in all sized of project with differing levels of importance. Every day projects are delivered and many of those projects fail to meet expectations by some stakeholders and are berated as failures. However, success can become consistent — from the perspectives of all involved. To assure this success, the teams must begin with a comprehensive identification of stakeholders and a collaborative definition of success. With this and other key foundation elements in place the team can leverage BPM concepts and techniques using BPMS tools to drive simulation and solution iteration until success is proven — from the perspectives of all stakeholders.