People are rightfully skeptical of buzzwords and facile trends in organizational management. For every successful launch of a Six Sigma campaign, there’s a workforce somewhere groaning about another mandated management “retreat,” or a cosmetic rearranging of office chairs with no fundamental change in the way things get done.
"Some of the key features of agile are increased transparency, the ability to shift directions, and measuring productivity"
I want to share my experience with using agile project management to manage an entire portfolio of work, because the positive results may go a small way toward restoring the good name of institutional self-reflection. The principles of “agile” have moved far beyond their origins in efficient software development among teams, and deeper into questions of business workflow management, productivity, and customer responsiveness.
Some of the key features of agile are increased transparency, the ability to shift directions, and measuring productivity. Before undertaking work, we estimate how long it will take, and at the portfolio level, I can see quarter by quarter how much we complete. I can give the rest of our leadership an accurate picture of our true capacity.
How does this work in specific examples? This year’s organizational strategic plan placed a heavy emphasis on data-driven decision making. That’s a great objective, but it also meant they were asking for a lot from IT. Using agile project management techniques, I had good data on what our capacity was to do the work. My management team estimated the work required under the new plan and compared it to prior years’ work. We made a solid case for adding a position in data sciences to meet the increased demand. It’s important to align how I spend resources with the organization’s strategic objectives. By tracking the work this way at the high-up, portfolio level, I can say here’s how much we’re spending on different organizational priorities. And it is lightweight: instead of estimating individuals’ hours spent for each feature, we estimate at the team and project level. Managers get feedback on their estimation by comparing historical estimates against the amount of work each project required to complete.
Agile works well in our environment, a multi-location mental health organization with various IT components that face administration, providers, and clients. There are some kinds of business projects where work is commoditized— project management for residential construction comes to mind. How to build homes generally comes with a lower degree of uncertainty: builders use waterfall project management, projecting the entire schedule for construction prior to starting to build. Ask them how long it will take for your new home, and they can answer “six months.” Because so much of what we do in healthcare IT is new, agile is a good fit. We make a much rougher estimate of the work and we continually reprioritize. Work is organized in such a way that you can always stop at the end of an iteration and you will still have delivered something of value by chopping things up into one releasable feature at a time. Even though someone in management might have said, “I want these 10 things on my wish list,” it’s possible that when they get their first three, they are satisfied, and it’s time to rethink priorities.
Our first big success with agile was in implementing our electronic health record. We’d been customizing an old EHR for 12 years; it was time for a replacement. We couldn’t recreate 12 years of customization in an implementation. We embraced an agile concept of “minimum viable product.” Our approach was to get something useable delivered as soon as we could. Everyone would be able to do their jobs, even if it lacked some of the features and enhancements from before. There were workarounds, but staff were able to get things done. We then began a release cycle where each month we released the highest value enhancements. What would help the greatest number of people; what would help us meet new external requirements? As part of that process, we convened two groups of stakeholders: the recipients of the enhancements and our organizational leadership.
The first stakeholder group ensured the work completed met the end-users’ requirements. We’d do a two-week sprint and meet with end-users to show them the results, making sure that we captured what they were asking for. By getting feedback before a feature went live, we made sure we didn’t get too far of course, that we weren’t releasing something that failed to solve the problems at hand.
The second idea was organizing a work queue. Every month we met with VPs across the organization. We’d ask them to advocate for prioritizing their work ahead of other projects and have a discussion on which were important and which could wait. Instead of just me making the decision on what’s important, we had feedback, input, and transparency. The entire organizational leadership made decisions about where to focus our time and effort.
A natural question is why doesn’t every organization use agile all the time? One answer is that a lot of people don’t really manage projects that tightly. They do their work and try to do their best, and work gets prioritized based on who the squeakiest wheel is. At the same time, bigger projects end up getting over-planned. People pretend to know too much about how it’s going to play out. They map it out in painstaking detail and pretend to know exactly how much time people will take to get things done.
At the CIO level, it’s been tremendously valuable to me to invest in a consistent tracking methodology for all the work we’re doing. It wouldn’t be possible to do as much as we’re tasked with without putting this organizational structure in place. It allows me to look and report on the status of as many as 60 different things without knowing it off the top of my head. And it allows me to set realistic timelines for when work will get done, while still allowing us to be nimble and adjust, which is important with everything going on in healthcare these days.