Agile Development for Healthcare Business Intelligence

by Laura Madsen

Doing more with less should be the tagline for most healthcare organizations today. The pressures of keeping the bottom line stable and regulators/auditors at bay has driven most organizations to do the absolute bare minimum with their business intelligence (BI) deployments. Even the large ones that are growing are still squeezing the turnip. Showing value and tangible deliverables is the name of the game. As a result, agile development is becoming a more appealing option to many of these organizations. Even though as an industry healthcare organizations usually aren’t the first to sign up for a process that actually accepts a certain amount of error and fluctuation, many of them have traded that risk for the opportunity to see incremental value of a larger investment.

Data warehousing and business intelligence are really perfect playgrounds for agile development. The concept of constantly changing business requirements is no more evident than when you hand over a report that a user asked for only to get “That’s great, but can I get this?” The user isn’t trying to drive you crazy. It’s just that without having a tangible piece of data to respond to, they don’t know what they need next. It’s why many organizations just build cubes and hand them over in response to the “just give me the data” request. But, in reality the users don’t just want the data; and even if you can give it to them, many of them wouldn’t know what to do with it anyway.

With agile development, you have the opportunity to quickly deliver smaller pieces of information so your business users can say “That’s great but how about this?” earlier in the project life cycle. That reduces re-work cycles and frustration among both the delivery team as well as the business.

There are some “gotcha’s” though, such as estimating level of effort and creating smaller functional teams. The one that always frightens information architects is the idea of building something before we really know what we are delivering. But, in today’s world, the risk is probably worth it, particularly if you are able to deliver value-added content while still holding true to some information architecture best practices.

Your List of To-Do’s

If you are considering doing this, here are a couple things to keep in mind. First and foremost, pick up your copy of Ralph Hughes’ book Agile Data Warehousing. It is an excellent and pragmatic guide to agile development for data warehousing. I suggest reading it in its entirety prior to embarking on your agile adventure.

Take the time to communicate to all the stakeholders about agile development and what it means for the project. It’s important that they understand before the work begins that the process and deliverables will look and feel different during the life cycle of the project. They don’t necessarily all have to be on board, but they do have to be willing to give it a shot. Ensure that any communication about the agile development concept includes not only the benefits, but also some of the challenges. Painting too rosy of a picture will only get you in trouble in the long run.

The idea of “agility” isn’t to trade off quality, but to reduce turnaround time and re-work. The best way to do that is to make sure you are connecting closely with your end users. Locate your team so that they can easily have conversations with the business users. That will reduce the time it takes for questions (from your team as well as from the business users) to be asked and answered.

Finally, one of the most challenging parts of agile development (for me) is the idea that things will fluctuate over time. I can’t point to one documented set of deliverables with a list of stage-gate deadlines to get me there. What I can tell you is that in two weeks, we will have a piece, and in two more weeks we will have a bigger piece.

I have completed a couple agile projects in healthcare. None of them have turned out the way that I thought they would. What was really positive about all of them was that I learned a lot of project management. The reason for this is because in order to deliver in an abbreviated time frame you have to remove all barriers to productivity as quickly as possible. So, when I played the role of “project manager,” I would spend hours tinkering with my project plan; but when I was a lead on an agile team, I spent time reviewing deliverables and discussing my needs and requested modifications. I actually pulled my head up from my computer screen. Revolutionary.

One recent “revolutionary” agile project comes to mind for me. The organization has had a lot of changes, and they felt that data warehousing (DW) and business intelligence were a cure for what ailed them. Approaching it as a key market differentiator, they were prepared for the bumps that came with a DW/BI deployment; but just when we were about to pull the trigger, the fear of failure took over. So as an antidote to that, we simply said, “Okay, let’s deliver value as quickly as we can…how’s two weeks?” We designed the rest of the project around short sprints with incremental deliverables. I can’t tell you how it turned out; we are still working on it, but the objections to starting the project were removed when the promise of tangible content in weeks, not months, was communicated.

Another project I was a part of a few years ago attempted to undertake an agile development process. We had daily stand-ups, had a Scrum Master in charge of the project, had some method of mapping tasks with sticky notes (he swore it was better than a project plan). About halfway through the project (already late and over-budget), our Scrum Master left the organization, and our project, in absolute chaos because no one else knew the basics of Scrum. Another contingent of project managers took over and created an 86-page Visio diagram of all the steps that needed to occur in order to get a project completed and a release out the door for our data warehouse. We went from agile to docile in a New York minute.

For as many horror stories of agile development, there are also many great success stories. Like the time I spent two weeks in a developer’s cube and completely modified our BI tool based on a specific set of focus group feedback. The project was fun and it was completed on time and under-budget.

I highly recommend that if you work in a healthcare organization and you have been pressed with how to do more with less, you consider agile development. Do your homework and walk in with your eyes wide open. In two weeks, you could have the start of your next data warehouse release.

Advertisements

About Andy Painter

A passionate Information and Data Architect with experience of the financial services industry, Andy’s background spans pharmaceuticals, publishing, e-commerce, retail banking and insurance, but always with a focus on data. One of Andy’s principle philosophies is that data is a key business asset.
This entry was posted in Business Intelligence, Data Warehousing, health care and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s