This post is second in a series about best practices for how business intelligence teams can execute faster.
How productive is your team? Is your team working on the business’ priorities? Do bug fixes and manual system operation crowd out new development?
Measuring productivity is difficult. As a developer, I often looked at requirements and knew how long it should take to code. As a development manager, I routinely added between 50% and 100% to developers’ estimates. As a project manager, I added 50% to the development manager’s estimates. This was not because the estimates were wrong (most of the time), but because they related to different scopes.
A developer often estimates based on the effort of sitting down to write code, assuming environment is ready, the requirements are agreed upon, the sources are known, and the developer had a good night’s sleep. A development manager has to plan for overhead around tracking status, requirements changes, environments not being ready, and workload not matching the team’s skills. A project manager knows about project overhead, changes to requirements or even major goals, missing staffing, or unexpected large problems.
Understanding productivity requires two measures:
- Work tracking. A single place that reliably tracks all major tasks performed by the team. Often this is categorized between a bug tracker and an enhancements list.
- Time tracking. Measure hours spent. Large enhancements should have hours tracked directly, bugs and ongoing work should be divided into two or three categories.
We suggest you start by measuring productivity over a three or six month period.
Teams are often surprised to discover that peak output is several times higher than average output, but also that sometimes weeks pass with no new development. Having accurate productivity measures is fundamental to alignment.
Of course BI teams want to work on business priorities. The devil is in the details. Complexity is driven by multiple customers, mutliple developer skill sets, and the need to balance near-term and investment work. Having multiple customers requires the ability to trade off and prioritize between marketing and inventory, or new reports vs. new sources. Multiple developer skill sets raises the challenge of matching the need to skills. Should a data request be answered with a new dimensional model and a simple front end or a complex report? Near term work benefits the business directly. Investment work, like performance tuning, training, software upgrades, improved reliabilty, and general data quality efforts are required to keep the BI enviroment operational, but do not immediately benefit end users.
End users often perceive BI teams as slow or unreliable because BI project managers can not reliably predict how long projects will take, or explain why project deadlines have to change. Understanding what the team is working on, and what the capacity of the team is, allows project managers to make good predictions about deadlines.
Being closely aligned also prevents mangement by developer stress level. Teams that do not have good work tracking have no way of limiting the amount of work they promise to do. Instead, requests pile up until delays become unacceptable. Team members work extra hours, end users get frustrated, and corners get cut.
Project managers with good information can align work with business need by making tradeoffs in the the form of: we can deliver feature X, but it will delay feature Y 10 days.
BI managers need to ensure that the are building the capability of the BI system and team as they continue to deliver on short term needs.
Managers often enter into “technical debt“. Pressing needs force compromises, quick fixes, and shortcuts. Being able to work quick and dirty is a good thing. It makes the BI environment better serve business needs for timeliness and cost-efficiency. However, technical debt accumulates into a burden that prevents future produtivity. Symptoms of high technical debt are data quality problems, being more than 1 version behind in a key software tool, significant time spend on bugs and help desk requests, and user complaints about the system being difficult to use.
It is up to project managers to plan for and justify investment in BI capabilities. These investments have the effect of paying down technical debt. Project plans should include time for:
- Performance tuning
- Software updates
Larger teams can devote people full time to investment activities. Both smaller and larger teams should have formal project activities around capability investment.
Project managers can deliver BI faster by understanding productivity, using that understanding as a foundation for alignment with business needs, and balancing rushed work with ongoing investment.
by Tom Victory, Principal Consultant
© DecisionPath Consulting, 2011