TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Project Management: Do Less by Committing to More

Agile leaders focus more on the continuous delivery of high-priority value to business stakeholders and less on making sure each worker is always busy. We explain how your BI program will benefit by limiting developer multi-tasking.

• July 30, 2013

By Ken Collier and Lynn Winterboer

[Editor’s note: Lynn Winterboer and Ken Collier are leading a session at the TDWI World Conference in San Diego (August 18-23, 2013), Agile BI: Road Mapping, Chartering, and Release Planning. We asked them to explain why running too many concurrent BI projects is counterproductive and what best practices they suggest to maximize productivity.]

Ben and Susan are each a DW/BI director at their respective companies; each leads a department of roughly the same size. Both have the staffing necessary to organize three dedicated, cross-functional teams. Ben’s department is organized into dedicated teams while Susan has functional skills “pools” from which project teams are staffed. Both directors are planning for the coming year and have a similar set of 12 projects to schedule.

Through collaboration with business stakeholders, product owners, project managers, and the program management office (PMO), Ben has a prioritized backlog of funded project requests to schedule into the calendar. With help from technical leaders, he has completed some high-level project sizing and assigned durations of two, three, or four months per project. Projects longer than four months are divided into multiple phases, each designed to fit into one of these smaller time periods. This ensures that long-running projects do not block other projects by dominating the department’s capacity.

Ben assigns a dedicated team to each of the first three projects in the backlog. He then estimates when each team might be free to start its next project, continuing in this manner until he has a reasonable program plan for the coming year:

Because Ben continuously pulls from a program backlog, the whole process takes less than an hour of Ben’s time, and he is comfortable sharing this project road map with stakeholders and the PMO. This company’s agile culture includes an agreement that once a project is started, the team will stay focused on that project until the project timeframe is finished. Adaptation to project reprioritization does not affect projects that are already underway. Because business and management stakeholders are involved in the prioritization process, there are no surprises about the program schedule. Everyone also understands that the program backlog is always evolving based on the changing needs of the business.

Meanwhile, Susan is also doing resource planning for her department. She has met with each of the BI team’s key stakeholders to get their input on priorities for the year. She’s heard passionate explanations from each about why their top priority projects are important to the company, such as “I need sales pipeline analytics ASAP so I can ensure the marketing team is ready to support our key industries!” (from the VP of sales and marketing) and “I need net profit margin per product so I can report accurately to our investors!” (from the VP of finance).

Susan understands the importance of each of these projects, and wants to get them started as quickly as possible. Moreover, her CIO is focused on maximizing personnel utilization, desiring that every team member be utilized 100 percent on project work. Susan believes if she gets team members started on more projects sooner, and has them spread across multiple projects, her CIO and stakeholders will be confident she’s doing everything she can to focus her teams appropriately. Therefore, she structures each project to have a dedicated core team of two developers with the part-time support of product owners, project managers, data modelers, testers, and business analysts. Several of these projects are expected to take 6-12 months to complete, so Susan needs to run at least six projects concurrently in order to meet the urgent needs of the business.

As Susan’s delivery strategy gets underway project team members plan in two-week iterations for the multiple projects to which they are assigned. This means that each team member is attending at least two, and sometimes three, planning meetings every two weeks. They are also attending multiple daily stand-up meetings, iteration showcases, and retrospectives. Project managers and product owners are only able to devote cursory time to assist on each project, and they often feel disconnected from what’s actually happening. The core developers dedicated to each project are frustrated because they cannot count on having the support they need from data modelers, testers, business analysts, and others. This is further complicated by the fact that there doesn’t seem to be any common time when the entire project team can work together.

Every team seems to over-commit on each iteration, failing to finish stories as planned. In part this is caused by the significant overhead incurred as team members switch from one project context to another (approximately 20 percent per additional project, per Weinberg, 1991).

Susan failed to account for this waste in her resource plan. This triggers two side effects. It is evident that the projects will not finish on time, and teams’ (and Susan’s) ability to accurately predict when each will finish is nebulous. Each team is cutting testing corners under the duress of over commitments, which will cause increased maintenance/support issues.

As much as Susan tries to create a great culture and work atmosphere, people in her department are unhappy. They are stressed by the job pressures and often feel like hamsters on a wheel, running fast and getting nowhere. There is a general lack of collegiality in the BI group and people often blame their colleagues when things go badly. Many staff members have remarked on the difficulty of trying to do too many things at once, but Susan doesn’t think they understand the pressure she is under to meet the needs of the business.

Consider the differences in the directors’ situations.

Big Themes

It is often counterintuitive that dedicating a team to one project at a time will better satisfy stakeholders, yet agile teams that focus exclusively on one thing at a time are able to deliver value more quickly to their organizations because:

• Starting projects earlier does not ensure they will be finished sooner
• Project multi-tasking has an unseen penalty cost that will further delay finish dates
• Focusing on maximizing utilization over project completion has unintended consequences

Resources

Brown, R. (2010, June 29). Multitasking Gets You There Later. Retrieved June 20, 2013, from InfoQ: http://www.infoq.com/articles/multitasking-problems

Cohn, M. (2009). Succeeding With Agile. Boston: Addison-Wesley Professional.

Weinberg, G. M. (1991). Quality Software Management Volume 1: Systems Thinking. Dorset House.

Lynn Winterboer teaches and coaches DW/BI teams on how to effectively apply agile principles and practices to their work. She is the founder of Winterboer Agile Analytics, and can be reached at Lynn@LynnWinterboer.com.

Ken Collier is the agile analytics practice lead for ThoughtWorks, a company specializing in custom software and solutions development. Ken can be reached at KenCollier@theagilist.com.