The Executive View: Beyond the Methodology
November 2014 • Presentation
This TSP Symposium 2014 presentation describes using CMMI methodology and Team Software Process training to solve critical business problems.
This presentation was created for a conference series or symposium and does not necessarily reflect the positions and views of the Software Engineering Institute.
On my first day as the executive of a large delivery organization, both my client and my manager described the challenge ahead by describing our past performance: abysmal. Poor quality, late projects, budgetary overruns, and an unprofitable business model. We were under intense pressure to improve fast, and we needed to make radical changes quickly and discontinuously.
We leveraged tools from the CMMI methodology and Team Software Process training to fight this battle, but we didn't start on a journey to seek certification. While that was a result of our journey, our approach went beyond the methodology to drive superior performance. We focused on using these powerful tools to solve critical business problems.
We created a Pareto of everything that was wrong with our development organization. We focused on the biggest problems until we hit the 20% of problems that represented 80% of our pain. As we solved the first bar of the Pareto, quality, we also made huge dents in the second bar, on-time delivery. By the time we hit our 20% marker, we had addressed several other problems as well. First Time Quality improved by 66%, on-time delivery improved by 30%, budgetary overruns dropped by 37%, attrition dropped by over 30%, and profit increased by 12%.
Our client and our management acknowledged these improvements, for a minute, and then quickly turned their attention to the next 10 problems. I made a realization—we live in a world of Paretos. Your client, your leadership, and your team will always have a Pareto of what needs improvement. As an exceptional leader, you need to be aware of the Pareto and constantly manage the 20%. That is, are you dealing with imperatives (e.g., cost, schedule, quality, attrition), or are you dealing with nice-to-haves (flexibility, thought leadership, more speed, more profit)? All are equally important from your client's perspective, but from a software-engineering excellence perspective, fixing the imperatives is a survival skill; fixing the nice-to-haves will set you apart.