ACO Disease Specific Analytics

“What can Edgewater’s Accountable Care Analytics do for me that we cannot already do with our EHR and patient financials reporting?”

To be successful, ACOs and other integrated health systems must bring together both clinical and claims data – and they must make the data available for use by clinical, operational and financial leadership across the entire organization.  The biggest challenge our clients face is an ability to provide management this data now, to drive early operational decisions. This is what Edgewater’s Accountable Care Analytics can do – provide organization-wide dashboards for decision support in advance of the complex and time consuming integration projects these health systems face.

This podcast shows a quick demonstration of the capabilities our ACA application.

Edgewater Healthcare Analytics

I recently read an article called “The 4 Biggest Obstacles ACOs Face” on Forbes.com that I found really interesting. In it, the author identifies what I think are the primary challenges for Accountable Care Organizations (ACO). But, I would change the order.

ACOs need a management structure in place to make critical operational decisions. But those decisions should be made leveraging enterprise wide data. So, the primary challenge for ACOs — Providing management with accurate, actionable data to make management decisions, before all of the technical integration challenges have been addressed.

To learn more about Edgewater’s Accountable Care Analytics application, and how it can help you get meaningful data to ACO decision makers, email us.

Edgewater Consulting blog

Technical How-to: Redirecting SSLv3 Users to a POODLE warning page using Apache2 mod_rewrite

The Padding Oracle On Downgraded Legacy Encryption (POODLE) vulnerability has been making headlines since September 2014. There are a few options for mitigating the risk, but our infrastructure team has found that not all organizations are able and willing to implement them. Disabling SSLv3 entirely can cut users off from secure websites they rely on, and Google’s TLS_FALLBACK_SCSV mechanism requires support from the web browser, and has not been implemented server-side by all distributions, especially on older and unsupported versions. Further, TLS_FALLBACK_SCSV does not address the issue of SSLv3 support itself, rather it prevents devices which support TLS from downgrading connections to SSLv3. It does not help in cases where the browser is Internet Explorer Versions 1 through 6 (although Internet Explorer versions 4 through 6 can be configured to enable TLS.)

A more elegant solution is not to block SSLv3, but to instead warn users that their current browser is vulnerable to known attacks and instruct them on how to upgrade. With Apache2 and mod_rewrite, it is possible to redirect SSLv3 connections to such a warning page and advise users of the issue and how to resolve it. Here are the steps to do so:

  1. Prepare or find an explanation page you wish to redirect insecure SSL sessions to and note the URL.
  2. If you run a reverse proxy, load balancer, or other session layer device between your apache server(s) and the Internet, please be aware that those devices may be vulnerable to POODLE even though they support TLS: http://www.computerworld.com.au/article/561828/poodle-flaw-returns-time-hitting-tls-security-protocol/
    To be sure that your entire chain of TLS implementations is secure, temporarily disable SSLv3 in apache2 and head over to SSL Labs to test your site. If your TLS chain is vulnerable you should receive a grade of “F” with a warning (emphasis ours:) “This server is vulnerable to the POODLE attack against TLS servers.” If you receive this warning, you should contact your vendors and request patches.
  3. Make sure that Apache2’s mod_rewrite has been installed on your system. Apache2 runs on a variety of architectures and operating systems, so installing individual Apache2 modules is beyond the scope of this article.
  4. Make sure that Apache2’s mod_rewrite is enabled. To do this, run the following as root/administrator:
    a2enmod rewrite
  5. Add the following lines, without the line numbers, to your Apache2 HTTPS site configurations, changing http://yourwebsite.com/yourexplanationpage.html to the explanation page you wish to redirect users to:
    1. #POODLE REDIRECT CONFIG–
    2. SSLOptions +StdEnvVars
    3. RewriteEngine On
    4. RewriteCond %{ENV:SSL_PROTOCOL} ^SSLv[2-3]$ [NC]
    5. RewriteRule ^.*$                    http://yourwebsite.com/yourexplanationpage.html
    6. #END POODLE REDIRECT CONFIG–
  6. If you have disabled SSLv3 already, undo the configuration disabling it.
  7. Restart Apache2
  8. Now test, test, and then test some more! You can use Firefox and enable/disable SSLv3. To force an SSLv3 connection set both security.tls.version.min & security.tls.version.max to 0. To disable SSLv3 in Firefox set security.tls.version.min to 1 or higher and set security.tls.version.max greater than or equal to security.tls.version.min
blended project management

Have you tried to blend agile methodologies into your traditional waterfall world?

Did you get a tasty stew?

….Or a culinary disaster?

I like to cook, but I’m not exactly a purist.  By that I mean that I almost never follow a recipe exactly.  Instead I treat a recipe as more of a guide.  Sometimes I omit ingredients that my family doesn’t like; other times I add in ingredients to see what the affect will be. I often combine a couple of recipes together, mixing and blending ideas from several sources.  Sometimes the result is a wonderful creation that suits the tastes of my family.  Other times, we take a bite and reach for the pile of take-out menus.

I find myself taking the same approach to development methodologies.  Like most of you, I find traditional, waterfall methodologies to be too rigid, too slow, and too removed from reality.  Their assumption that everything about a project can be known and documented up front has always struck me as laughable.

But when I look at pure agile methodologies, I find them too rigid and idealistic as well.  Successful projects need a framework around them; they can’t be driven simply by empowering a team to prioritize a backlog and deliver chunks of code.  Project components need to be fit into a larger vision and architecture; organizations need to have a sense of scope, plan, and budget.  Large, complex systems can’t always be nicely packaged in 2 or 3 week sprints.

So I find myself mixing and blending.  Take a few waterfall concepts like a defined project scope, written business requirements, defined technical architecture, and a project plan.  Blend with an agile development window where the project team can work through detailed requirements, development, and testing together; shifting priorities as business needs change.  Garnish with some user testing, training, and release planning.

Maybe this is agile book-ended by just enough waterfall to frame the work that the agile teams will take-on and integrate their work with the organization’s larger planning processes.  Maybe this is diluting agile precepts by subjugating them to overreaching controls.  Some call these approaches “waterscrumfall”; some call them an abomination.

My experience (and the experience of at least one of my colleagues) has been that a pragmatic blending better suits the needs of most projects and most organizations. It creates just enough structure to tame the chaos while recognizing that projects can’t be and shouldn’t be totally defined up-front.  It ensures that project deliverables fit into the larger enterprise architecture and meet strategic objectives.  Yet it takes advantage of the agile team’s strengths, allowing them to drive the project’s pace and details.

What has your experience been?  Have you tried more blended approaches?  Have they been successful?  Or have they resulted in the equivalent of a culinary disaster?

Chinese_character_採_cai3_pick

Just Pick 3

Fast away the old year passes, as the song goes.

It’s that introspective time when we all review the victories and defeats of the last twelve months and come up with a list of resolutions.

How long was your list last year?
How many of those goals did you attain?
Did you come out of the gate in January with a bang, and light a fire under 10 or more action plans, or did you attack your list in a prioritized sequence?
How did that work out for you?

In any year where I made a lengthy list, I ended up frustrated before February rolled around, and never looked at my list again. I just couldn’t achieve the progress I envisioned.

This year, I am going to do something different, and I think you should too.

By January 1, I will pick 3 areas to focus on in my work and personal resolutions. When I have achieved the desired results there I will pick 3 more.

The best way to do this is to pick 3 goals phrased as metrics you can measure.

Start your list. What do you want to change? How will you measure it?

Decide what is  most important.

Then, just pick 3.

homer_simpson_doh_02

Does your PMO get in the way of your Agile Development Teams?

Do your agile teams have your PMO pulling their collective hair out in frustration?

A family in harmony will prosper in everything. ~ Chinese Proverb

Does this sound familiar:

We value face-to-face conversation We need formal, written documents
Working software is our primary measure of progress Where is your status report?
How are you progressing against your project plan?
Self-Organizing Teams Defined Roles and Responsibilities
Individuals and Interactions Processes and Tools
Respond to Change Follow a Plan
Culture of Change Culture of Order

You’ve embraced an agile development methodology, empowered your teams, and they are eager to move forward.  They want to deliver a quality product to the organization as quickly as possible.  They want to add value and make a difference.

Your project management office (PMO) understands and supports the agile development approach, but they still need to manage the overall project portfolio and they want to be sure that the agile teams deliver in alignment with the organization’s strategic objectives.  They want to add value and make a difference.

Both groups have the organization’s best interests in mind, but there is a definite culture clash.

Agile teams can be dismissive of the PMO. Their approach is different, they don’t need to worry about those processes and frameworks; they just need to focus on their own project.  The PMO should get out of their way.  It reminds me of a teenager who wants their parents to just leave them alone – until the parent is needed.

PMOs can act like a dictatorial parent.  They can demand process and procedure from agile teams because that is what they’ve always done.  But process and procedure that doesn’t add value does get in the way.

Both groups need to respect each other and adapt.

Just like the parent of a teenager, the PMO should be loosening the rules and allowing greater freedom while demanding accountability (and standing by with a safety net). The PMO has to adapt itself to the agile world,  working with the agile teams to understand the tools that they are using to manage and control the agile project.  It should adapt these tools to their use rather than making the agile team use the same old PMO provided reports and templates.

The agile team, like the teenager, also needs to acknowledge and respect the role of the PMO.  The project and the project team aren’t operating in a vacuum.  It needs to fit into the larger organizational plan and processes.  So the agile team needs to fit itself into the framework that the PMO has established.  That may mean complying with certain project checkpoints or processes, such as conducting a formal risk analysis or establishing a milestone-level, project plan, budget, and scope.

If each can recognize that the other is not purposely trying to obstruct them and understand the value of the other to the organization, they should be able to leverage on another’s strengths.  While there may still be friction and areas of disagreement, the end result should be a set of processes that improve project outcomes and ensure alignment with overall organizational objectives.

Edgewater Consulting blog

Voice of the Customer – Kano Analysis

As a Consultant, I’ve acquired specific preferences when traveling, and learned to adapt behaviors that make these experiences as stress free as possible. For example, at airport security, I try to avoid standing in line behind anyone who is dressed too “casually” or has sun screen as one of the items in their plastic bag. Chances are that they will take twice as long going through security, thus delaying my time to reach my gate/flight. When selecting a hotel, I look for one with a good in-house dining menu. The benefit of coming back to the hotel and enjoying a good meal without having to leave my room is priceless. Also, let’s be honest, it all comes down to points.

The casual traveler might see little value in earning points or priority boarding; however, the business traveler sees great value in these service items.  Not all consumers value the same services and products on the market in the same way and many companies are keen to analyze these trends. To aid in analyzing customer needs, and provide insight into services or products of little importance or that miss Critical to Quality (CTQ) features, companies may want to perform a Six Sigma process based on the Voice of Customer (VOC), called Kano Analysis.

What Does It Do?

Kano Analysis identifies and prioritizes customer needs or requirements by classifying them under key categories, including: basic services a customer expects, services that a customer desires, and services that delight a customer. Below is a summary of categories and definitions (terminology may vary slightly).

Requirement/Need Definition
  • “Must Be”
  • Basic Requirements
  • Dissatisfiers
  • (Expected Quality)
  • Expected features – cannot increase satisfaction
  • Taken for granted, rarely voiced
  • If not fulfilled, customer is extremely dissatisfied
  • “More is Better”
  • Performance Requirements
  • Satisifers
  • (One Dimensional Desired Quality)
  • Linear effect – the more needs are met, the more satisfied
  • Customer is aware that feature is important to them
  • Remain in the market
  • “Delighter”
  • Excitement Requirements
  • Satisifers
  • (Excited Quality)
  • Unexpected feature – impresses customers
  • Delights when present – does not cause dissatisfaction when not present – rarely voiced
  • Leading edge in the marketplace

How To Do It?

Gather as much VOC information as possible (via interviews, focus groups, surveys, etc.) from your customers regarding service or product offerings. Have them classify the requirements / needs under the three categories. Eliminate any requirements that aren’t relevant. The example below shows classifications pertaining to hotel services.

Requirement/Need Definition
  • “Must Be”
  • Basic Requirements
  • Dissatisfiers
  • (Expected Quality)
  • Clean hotel room
  • Reinforced lock
  • Toiletries
  • Towels
  • “More is Better”
  • Performance Requirements
  • Satisifers
  • (One Dimensional Desired Quality)
  • Large work desk
  • Wi-Fi
  • Car service
  • Hair dryer
  • Bed-side outlet
  • On-Demand movies
  • “Delighter”
  • Excitement Requirements
  • Satisifers
  • (Excited Quality)
  • Dimmable lights
  • Heated floors
  • Bottle of wine on birthday
  • Cappuccino machine in room
  • Room access activated via smart phone

It’s important to point out that a customer’s needs / requirements change over time. What was once a “Delighter” could be a “Dissatisfier” nowadays. For example, receiving an invoice (slipped under the hotel room door) used to mean that it wasn’t necessary to wait in line to check out of the hotel. Nowadays, it’s just one more piece of paper to file. Many travelers prefer to automatically receive an electronic copy of the invoice.

Tree

Voice of the Customer – Critical to Quality Trees

Don’t Get Stumped by Broadness

Often times, employees are able to identify a service need or improvement opportunity, but do so in a way that is too broad or can’t be acted on by the team. Employees may have identified needs such as a comfortable work environment, increased competitiveness in the marketplace, or improved customer service, but what does that really mean and how can it be achieved?

In this case, having a structured approach in place with which to identify specific characteristics or requirements that are critical to quality is imperative. To achieve this, implement techniques for process improvement known as Six Sigma . Through the use of the Six Sigma technique, Voice of the Customer (VOC), you’re able to gain insight into customers’ needs and their perception of quality. One VOC tool, Critical to Quality (CTQ) Trees, aid in identifying quality measures from the customer perspective.

What Does It Do?
  • It aids in the transition from broad, Voice of the Customer (VOC) needs / vague statements to precise, actionable performance requirements
  • It identifies problems along with root causes
  • It enables employees to identify features by which customers can evaluate companies’ services and that can be used as measures for a project
  • A useful CTQ characteristic is:
    • Critical to the customer’s perception of quality
    • Specific
    • Easy to measure
How To Do It?

Identify Critical Needs

  • Ask yourself “What is critical for this service or product?”
  • Brainstorm to identify the critical need that has to be met
  • Create a CTQ Tree for each identified need

pic 1Identify Quality Drivers

  • Identify specific quality drivers that have to be present to meet the needs identified in the previous step
  • When considering each need, ask, “What would that mean?”
  • “Good Customer Service” means “Knowledge of Product”

pic 2

Identify Performance Requirements / CTQs

  •  Identify the performance requirements that must be satisfied for each quality driver
  • Keep asking “What would that mean?” until reaching the level of detail that the team’s knowledge will allow
  • “Knowledge of Product” means “Zero Calls Transferred”

pic 3

What’s the Benefit?

It’s easy to get trapped by broad concepts that are not so easily quantified, such as providing good customer service. When you branch out and translate performance in terms of units (e.g. number of calls made) time (e.g. amount of time on hold) or money (e.g. total expenses) you start to see the clearing through the trees. The Voice of Customer approach is a great way to obtain clear, desired performance requirements that promote overall company goals. In my next blog, I continue exploring the Voice of Customer, but do so using the tool of Kano Analysis. It’s sure to delight!

For more information on Voice of the Customer, or other related Six Sigma processes, the following book is recommended: Voice of the Customer: Capture and Analysis.

PMO for Life insurance

How Life Insurance Companies Can Use the PMO to Improve Outcomes of Agile Projects

The Agile approach used in software development helps projects respond to unpredictability.

What? Unpredictability?

Life insurance companies are founded on predictability! How can Agile work at insurance companies, the reigning rulers of predictability?

In an informal examination of multiple large life insurance provider websites, the following key words were found (multiple times/places):

  • Preserve
  • Long tradition
  • Security
  • Base for building
  • Permanent
  • Fixed
  • Deeply committed
  • Dependable

So how can we, as project managers and program managers, fuse the “traditional” insurance corporate cultures with Agile projects that are based on evolving, iterating and changing?

A PMO initiative can help manage the point where predictability has to meet unpredictability, and blend as peacefully as possible in the project world:

  • Work with project teams and vendors to ensure agile terms, practices and goals are understood and met
  • Instill a level of commitment for agile projects that meet and align with overall project goals
  • Help set up or enhance proper Agile governance for projects and vendors
  • Assure that all integration points between multiple projects are identified, efficient and manageable
  • Perform ongoing scope analysis while adhering to the Agile philosophy of shifting and reprioritizing as necessary
  • Initiate risk analysis and align with the Agile methodology
  • Provide long term, short term or interim leadership in overall project work and Agile core competencies
  • Supplement resources to help with project and business area gaps
  • Guide project managers, sponsors and stakeholders throughout the agile process and provide ownership and stability with this methodology
  • Keep a balance of traditional project reporting and documentation while managing everyday Agile shifts and changes

As daunting as it may be for “old school” companies, exposure to Agile projects is inevitable. Managing Agile in a predictable way allows insurance companies to understand what it will take to adapt to the Agile project mindset and advocate the change.

eMetrics Boston 2014 Recap: A Web Analytics Consultant’s Perspective

dalmatianLast week I had the pleasure of attending eMetrics Summit Boston at the Seaport World Trade Center as both an Edgewater Web Analtyics consultant and an attendee. For those of you reading this that may have been there yourselves, we were the booth with the cute Dalmatian. ;)

Overall, I really enjoyed the event and was motivated by some of the topics covered. Below are a my highlights:

  • It’s All One Big Decision: AB Testing, Predictive Analytics, and Behavioral Targeting
    Speaker: Matt Gershoff
    I thought Matt brought an interesting perspective to these topics and really came up with a great title for this session. All too often marketing departments decide to get into AB Testing or Behavioral Targeting for the wrong reasons – someone told them they should, or they heard a particular tool was good. It is important to step back and think about the WHY before the WHAT. There are a lot of great tools out there but ultimately optimization is all about positioning your business with the ability to make better decisions.
  • Boston Red Sox – One Year Later
    Keynote Speaker: Tim Zue
    As a Red Sox fan and New England native I must admit a bias here but it was very interesting to see some of the measurement issues a huge sports organization like the Boston Red Sox faces. While most of us can’t directly relate to same specific issues, Tim’s presentation illustrated the importance of out-of-the-box thinking. I found it particularly fascinating how Fenway Park has been transitioning from traditionally more flat pricing into more flexible ticket pricing based on true market value data imported from after-market ticket sales. Seats that have proven higher value have increased over time while others have decreased. Analyzing after market prices to make these adjustments to the primary market was a very clever strategy. Kudos to you Tim Zue.
  • Five Big Analytics Project Lessons
    Speaker: Jim Cain
    Everyone can learn from what someone else has already learned from. A few quick takeaways I found particular useful:

    • Utilizing “Active Community Members” as a social KPI.
    • Making sure web analytics data matches internal systems, “If the CFO doesn’t agree with your numbers, no one else will either.”
    • “Most social analytics tools stink.” It was reassuring for me to hear this from others in the field and I heard essentially the same sentiment in multiple sessions in the two days I was there. I would agree with this in most cases and I have also found most social tools to be extremely overpriced. Working directly with social APIs whenever possible certainly seems like the way to go. It saves money in the long run and allows for greater flexibility. Win win!
    • And while maybe not useful but particularly amusing, “BIG DATA – It doesn’t refer to font size.”
  • It was great to have a break from the normal day to day and attend eMetrics. I’ve personally been inspired to write a few more blog posts on various analytics topics so more on that soon. See you next year Boston!