The Corporate IT PMO was created in mid-2006 and its initial focus was basically to get 'containment' on all IT project initiatives underway and transition them to a new release life cycle model that aligned with a new 'matrixed' organization structure.The PMO began to manage projects as part of a larger portfolio with dependencies versus many separate initiatives that frequently collided with each other.The IT organization began to mature into a project and process based culture.Projects were driven through a phased and partially iterative life cycle approach that resulted in several deployments, but usually with some level of drama along the way (SWAT teams, added resources, escalations to leadership and the inevitable finger-pointing when issues arose).Challenges remained, but there was now an approach to managing major pain points; the front end of the life cycle (priorities, initiation, alignment of teams), lengthy release cycles, cumbersome change control, minimal metrics and subjective status reporting.

In October 2008, Todd Wilkes, VP of Healthcare Informatics Application Development, shared some early successes his team was experiencing after introducing Lean-Agile principles and coaching from industry experts, with Bob LaPorte, VP of Corporate IT Application Development. LaPorte's interest was peaked and he decided to leverage the same experts to present an overview of Lean-Agile to his leadership team, which included directors of Application Development, Business Analysis, Quality Assurance, and PMO.

Prior to the Lean-Agile transition,Premier had been using a modified waterfall methodology with overlapping phases and a series of code drops into QA testing followed by User Acceptance Test cycles and then deployment. While having reasonable success, they knew there were many opportunities for improvement –

• Communicating status across a portfolio of more than a dozen project teams in a language that was not meaningful to Business stakeholders
• Prioritizing and working on items based on technical limitations and resource availability versus being driven by business value
• Escalations to senior leaders due to long release cycles or missed commitments
• Difficultly in tying budget spent to value delivered
• Cumbersome change management processes due to length of release cycles and shifting market needs
• Late feedback from customers on what was developed causing rework and deployment delays

Susan DeVore, then COO and now President and CEO of Premier, was challenging her employees to ‘think and act’ more like an enterprise. She was encouraging breaking down the walls of Premier’s business unit silos and working more as unified teams with common objectives to deliver innovative solutions that would ‘wow’ their hospital members (customers). The Program Management Office easily made the connection between Lean-Agile principles to Susan’s call and to the Core Values of Premier –

• Innovation =Understand what is ‘valuable’ to the Enterprise and let the Team find a way to deliver it quickly, with high quality and obtain early feedback.
• Passion for Performance = Eliminate waste, reduce cycle time, deliver high quality
• Focus on People =Respect, Empowered teams, self-managing, self-improving
• Integrity = Full transparency of all work through visual controls

In this particular instance, when it was apparent that the transition was to a system that aligns teams with disciplined practices to discover business-driven priorities for development, the PMOquickly stepped up and took accountability for driving execution and learning during the first pilot.The pilot Scrum Master was a senior program manager who had demonstrated a passion for empowering teams, with the required discipline to understand why the principles worked, and then trust and stick with a process.

It became clear that Lean thinking would provide a solid foundation to get various functional groups to focus on what was missing: clear prioritization of objectives and projects, initiating project work at the right time, and team collaboration.

Transition Planning and Roll Out

LaPorte understood early on that benefits and impacts would have to be carefully weighed for each enterprise area within his span of influence, and it started with his leadership team. Lean-Agile principles and practices were presented in exploratory sessions, and each of his directs was encouraged to present concerns and specific challenges within their current structure. After several sessions, it was agreed that the roll-out should be owned by the PMO, and the next step was to assess current and future projects to find a good pilot candidate for the Lean-Agile transition within CITS.

The results of the assessment were presented back to the leadership team, and a consensus was reached for the pilot, based on the recommendations of the assessment findings. The approach that came out of the pilot selection was to bring the team and its product managers to a five day boot-camp training session. Current and planned requirements were used to frame the course activities, with the goal to come out with an iteration planned and ready to execute at the end of training. The intense training covered principles, practices, and created a working product road map that had work decomposed into small enough increments to be consumed by the team's first 10-day iteration.

Selecting a major program (referred to here as "Supply Chain Product") to pilot the approach took courage, because this is one of the most critical programs within the CITS portfolio. The payoff was quickly achieved from a transition management perspective, because the organizational reaction to the visibility of the success was that other business units requested moving to Lean-Agile at a much faster pace than originally planned.

With the aggressive demand for Lean-Agile from the business units came the opportunity to pilot and learn standard practices in different fields-of-use within the organization. Examples include different types of development/delivery work flows including application arenas that integrated different skill sets, operational support teams, data teams, and architecture teams. As more pilot teams were staged and trained, focus was given to each group's unique challenges, and different practices were staged and rolled in for focus. For groups that were mostly driven by unplanned work, kanban software delivery techniques were utilized to bring visualization to flow by giving management the ability to see the impact of too much work-in-process. These groups still pulled from business-driven portfolios, to ensure that the limited work queues were filled with the highest valued business opportunity. In total, approximately 90 people were trained and ten Lean-Agile teams were initiated over a 6-month period.

One of the key principles that the PMO focused on was transparency. Visual controls that clearly show the flow of work (from discovered business need to delivery) through the Lean-Agile organization were created and managed with daily discipline. The organization began to look for visual bottlenecks that, in the past, were hidden by the sheer volume of opened work. As queue sizes were limited, impacts from any delays were immediately visible, and the organization had clear view of any waste and began to focus on clearing the bottlenecks. Examples included subject matter experts who were typically kept busy with their specialty, through the expense of opening up future work (and slowing down flow of higher priority solutions). This is where the PMO realized their calling and value to the transition. The organization began to form around the flow of work to a state of validated business-prioritized increments, and impediments were now the focus of process improvement. Boards began to appear with colored cards that showed consistent status of every project in-flight, and allowed transparency into what was being worked in real time. Although resistant to the discipline to maintain the boards, teams and managers soon began to value the safety that the transparency afforded--if they were in trouble, management could help, instead of interrogate.

 

Figure 1: Visual Controls: In one of many agile spaces, rolling whiteboards display work-in-process for each program and planned work for future iterations so that anyone can see up-to-date status.

It should be mentioned that this conversion was harder for some than others. There should be an expectation set that asking managers to forgo efficiency at the individual level ("keeping people busy") is a hard move for some to make. Lean guides us to look at efficiency at the enterprise level (optimize the whole). Efficiency at the individual level is mis-applied, and often creates more work-in-process and hides delays. It seems paradoxical that using SME's to complete work outside their area of expertise can improve enterprise efficiency, but it does because it keeps the amount of opened work in check. By utilizing cross-functional teams to help complete small increments end-to-end, the chance for discovery of errors later is greatly reduced. Overall architecture and integration is maintained with each additional increment, as opposed to legacy thinking that SME's should only do work within their area of expertise. The hidden waste in this thinking is revealed later because keeping people busy delays integration until late in the life cycle, which is where most projects uncover hidden problems too late to recover. The PMO took this principle to heart, and created visual controls to show efficiency of completing work at higher levels (done from the point of view of the customer). This visible flow became the focus, and this helped guide the transition so that completing small releasable features trumped keeping individuals efficiently tasked in their specialty.

As more teams were transitioned to the new process, the PMO began to collect and manage standard work that Project Managers performed on a daily, iteration, and release basis. This new process documentation outlined activities that require attention during various Lean-Agile iteration activities, such as visual control practices, facilitation and agenda for sprint demonstration, sprint reviews, and sprint planning sessions. As the group matured, a standard set of dashboard items began to emerge that each program made visible to the entire organization. These charts began to appear outside LaPorte's office and his executive dashboard was born.

 

Figure 2: VP’s dashboard. The view outside of Bob LaPorte’s office. LaPorte is VP of Corporate IT Application Development. Each program in flight updates these charts which show daily progress for each iteration, and progress against each release plan. From this view, the flow of work through the entire organization can be viewed, as well as any bottlenecks.

The dashboard view soon migrated to Sharepoint, and the PMO began driving their bi-weekly program status by reviewing each team’s velocity and flow, with a goal of working to clear bottlenecks as soon as they were discovered. In early sprints for the C-Suite Dashboard team, they struggled to achieve a solid velocity because they had yet to breakthrough their thinking on swarming and stories were left incomplete at the end of the sprint. They were effectively splitting team focus on two priorities, one to complete a maintenance release which was primarily test tasks and development of the next new feature. It was a tough sell to the product owner, but the team eventually put their full focus on the highest priority - completing the maintenance release. They stopped working on Release 2 and all hands were on testing. They were able to deploy the maintenance release one sprint later and resume work on the new feature the following sprint.

 

Figure 3: Snapshot of the PMO online dashboard that gives status on all agile projects as well as the story points required to achieve each release, and each team’s progress against each release (story points per iteration = velocity)

Ultimately, these dashboards gave visibility to the overall Value Stream by showing business initiative release plans that used velocity (story points completed each sprint) to predict release opportunities. As teams matured and velocities began to converge, budget spent (simply the burn-rate of the team) was shown against prioritized features. This powerful chart helped focus business stakeholders on respecting the managed queues of work and only feeding in high value project requests into the pipeline. When teams were put in a state of thrashing because of multiple stakeholders not working together to prioritize their work, budget spent would bubble up as applied to lower priority items, and quickly bring awareness that organizational capacity was being spent against lower priority work.

 

Figure 4: Feature profile chart. With all the information now available through the standardized use of features, estimation using story points, and velocity, detailed analysis charts can show cost of story points required for minimal release, and incremental ROI.

Bringing it together (Case Studies)

Below are descriptions and outcomes from four programs that were involved in the Lean-Agile transition. Their challenges and outcomes are common patterns observed when organizations are committed to trusting the principles and commit to improvement.

Supply Chain Product - Long Release Trains to Sprints and Incremental Releases

This team had been suffering from the 'long release train' approach and multiple stakeholders with differing priorities. It was one big long list of scope trying to make the next train since they knew there wouldn't be another train for 12+ months. The classic 'holding all scope hostage' until the last item was done regardless of priority. The product owners quickly aligned to one prioritized list because they knew the team would have something deployment ready as quickly as possible due to clear focus.This product had strong technical leadership and development team maturitywhen it was selected for the pilot, but they really knocked the ball out of the park quickly as they embraced the new Lean-Agile principles.The team delivered four releases in the first ten months of using Lean-Agile!

Field Force Product - Stakeholder delight

This project was a neat success story for a few reasons. First, it was a project newly underway in development, and it was somewhat of a surprise request (with a fixed date) from a key Business stakeholder to replace an existing tool created by resources outside of IT. After seeing the early Supply Chain Product successes, the Development team thought this would be a perfect project to transition to Lean-Agile given the aggressive timeline. So, the team attended the next training session where they were able to create a product backlog and their first sprint plan. Then this team was off to the races on delivering incrementally demonstrable work to the Product Owner. After the first demo, the product owner quickly realized that he had not done a good job of defining requirements and they were venturing down the wrong path for the solution. Why is this a neat success story then? Because the team and the product owner figured this out on Day 10 and were able to correct themselves, getting better sprint after sprint. The product was 'right on the money' when it was deployed and this product owner became an early champion for what he calls the 'best development process he has seen in his eight years with Premier'. Pretty neat.

Value Product - Rapid start-up

This is a poster child for getting it right from the beginning. It was a brand new product for Corporate IT.The team was able to start from day one using Lean-Agile.IT was already speaking a common language with the Business, so the product owner team immediately started working to create a prioritized 'product backlog' of features and stories and a very clear 'release plan'. Every two weeks the team had something to demonstrate and product owners were with them every step of the way. The team wanted to keep collaboration at an optimal level and pushed for team co-location even though the move to new collaborative cubes had been delayed. They helped modify an existing workspace for themselves so they could work together as a team. As they learned more through each sprint and adjusted feature size estimates, the product owners adjusted release plans based on new discovery to ensure and an on time launch of this new product.

C-Suite Dashboard - Impact Analysis

As noted earlier, Corporate IT began their Lean-Agile journey after learning of its' successful use in Premiers' Healthcare Informatics unit. For the first time in the history of Premier, the two development teams were using the same methodology. If Premier was going to 'think and act like an enterprise' this would be a huge advantage in developing cross-unit solutions like the C-suite dashboard. This Corporate IT team quickly jelled after their early hurdle and embraced the principles of Lean-Agile. They had achieved a solid velocity and were incrementally delivering against a prioritized product backlog when they received a request for work from Informatics. The impacted product owners collaborated and reached agreement on priorities. The new features were added to the backlog, sized and broken down into stories ready for the next sprint planning session. The two teams were able to align quickly due to a common methodology. They easily collaborated on features, stories, validations strategies and sprint plans. In a sense, this was an early pilot for providing an 'enterprise' solution for Premier.

 

 

Summary amp; Lessons Learned

To summarize this transition, we offer these focus areas and the observed outcomes:

Focus Areas (Drivers)	Outcomes observed
Leadership buy-in across 3 enterprise areas (business, management, team) through assessment and training Visual Controls, managing queues (work in process) Coaching, Standard work practices	Business engaged, continuous planning, continuous prioritization Management: Leading--not controlling,Flow-focused, managing work--not people Team: incremental delivery, collaborative behavior, quality focused

A fundamental takeaway from this experience report is that a large IT division was able to transform its practices to be more business driven. From the top, DeVore had challenged the entire enterprise to get aligned so that a stream of high value products and enhancements could continuously "wow" its members. This vision aligns perfectly with the goal of Lean-Agile software approaches, which structures an organization to focus on delivery of smaller, high value increments of features and enhancements. Faster time-to-market is achieved because less time is wasted on lower priority items, and delays are reduced because of clear visibility into the flow of work through the enterprise. Higher quality has been achieved because the organization is now driven by validation of working applications without the usual delays seen between the time when applications are written and when they are tested. The fact that the product owners see regular demonstrations of products has been a big win both in terms of reduced cycle time and eliminating waste.

The transition was led by the PMO, who quickly adopted standard work and visual controls as pilots extended across different IT areas and business units. Using a repeatable pilot readiness assessment followed by focused boot-camp training, consistency was maintained and learning from each pilot was used to continuously improve the practices in each of the three enterprise areas. Although Lean-Agile teams are self-managing and self-improving, having a group like the PMO focused on the whole enterprise and able to coach the teams and managers proved to be very beneficial in this transition.

---

About the Author
Kelley Horton is Director of the Corporate IT Program Management Office for the Premier Inc. healthcare alliance (www.premierinc.com). She has program management and process improvement expertise with over 15 years of experience in creating and leading Program/Project Management offices for product and application development organizations as well as implementing and improving Software Development Life Cycle (SDLC) processes.