At some point in the first month of his joining the engineering team as the Program Manager, Senthil started to wonder whether he might have made a bad career move. The team was just getting ready to deploy the newest release of the tool that the technology giant's global consulting organization used to manage resource assignments and a decade of frustrations seemed like it was about to boil over. He had yet to meet his key business partners because they worked 12 time zones apart, but the emails he read from them made a strong case to disband his group and farm their work out to vendors. They wanted to stop the deployment of the release that was due to go into production by the end of the week and cancel funding for any remaining work.

With 5 years of experience working in IT at this company and many more years working at other companies, Senthil knew how hard it would be to turn around a situation like this. Clearly, there was a long history of disappointments that were clouding the current situation and he wasn't sure that there was much he could do to change things.

He understood from his team that they had carefully and rigorously gathered requirements, managed the scope of the project and in fact delivered exactly what they had promised, on time and on budget, but with every release, the business seemed to grow more frustrated. In fact, many of the countries that had on boarded to the new tool in the last year had since abandoned the effort and reverted back to using Excel. Nobody was happy about this, but so far, no level of process control, change management or requirements modeling had proved effective in reversing the trend.

Since Senthil was relatively new to the team, he hoped that his business partner would give him a little leeway to try to bring some changes to the team, but he wouldn't have long. The first few phone calls were pretty rough. They quickly turned into a litany of all the things that had gone wrong and how little the IT team seemed to know about the business, how difficult it was to manage IT and how unpredictable the results were. Finally, he agreed to hold the release back from production and she would give him six weeks to resolve all the critical problems. Senthil wasn't sure it was possible, but he didn't see any better alternatives at that point.

Just around that time, he attended a two day class on Scenario Focused Engineering, a set of principles and practices that would eventually grow into Design for Business Value. He and his team learned how to use personas and user scenarios to elicit the most important process requirements. They brainstormed, built prototypes and tested them with users, then brainstormed some more and tried again.  They learned about confirmation bias, measurement and how innovation grew from diverse, highly functional teams.

The process was both obvious and yet unintuitive. The promise they saw was that they could transform from order takers, trying to micromanage the requirements they extracted from the customer to ensure they wouldn't be blamed, which never worked anyway, to a model where they were leading the design process, drawing the business in and learning by testing before they actually wrote any code.

The temperature in their relationship with the business warmed dramatically in the first week. Rather than being asked to write abstract requirements, the business was able to see and test how the proposed changes would support the process before any code was written. Rather than speculate on how a requirement would be transformed to a feature and be disappointed when it inevitably turned out different, they could redirect the team when a feature tested out to be difficult to use, hard to understand or otherwise ineffective in use.

Following simple principles of design, allowing room for innovation, considering the big picture but starting small and moving fast, and creating a process that required IT to lead and innovate, the business actually felt more in control. When they gave feedback, they could see it reflected in the changed designs the following day. And even better, IT was showing up with delightful new designs that the business never would have thought of.

Within one year, the team had recaptured all of the countries they had lost and grew their total user base by over 30%. The business was no longer lobbying to dissolve the IT team. They were polite and civil in their communications and clearly respected the expertise that IT was applying to help solve their business problems. Cycle times for finding resources were dropping and user satisfaction improved by over 120%, the largest increase of any application in the portfolio for that time period.

18 months into the project, Senthil reflected back on the remarkable transition that he helped manage and tried to quantify the improvements.

"The most important improvements," Senthil estimates, "have clearly been in the trust and confidence IT has earned with the business. We collaborate more effectively, even across multiple time zones. Even though we talk less about roles and accountabilities, we all have common expectations about who will do what. I would say that the quality of business partnership has gone from a 3 to 9 on a scale of 0 to 10. And the only reason we aren't at a 10 is because of the time zone differences.

"But it's more than just learning to treat each other with respect," he continues. "IT has really earned our keep. We've taken on more accountability and made it easier for the business to work with us. The quality and usefulness of the requirements we end up with have gone from a 3 to an 8 because we are able to test the designs before we build the spec. That allows us to clarify and refine requirements that looked fine until we actually tried to implement them.

"That in turn, led to a dramatic drop in the cost of defects, which meant that we could ship more in each release. The amount of engineering effort dedicated to fixing defects and responding to CRs has dropped from 23% to just 3%. We can ship in a single release something that used to take us four releases to get right. And the work we had to spend in the second, third and fourth release was never planned, so those fixes ended up cannibalizing capacity from those future releases.

"In a nutshell, we save the most time and money from not doing the wrong work. And personally, I think it's a lot more fun to work on a team that is recognized and appreciated for the business value it delivers. Now, instead of the toxic environment we had before, everyone's good intentions have a chance to surface. It's a great place to work.

"One final thing I want to say is that, even though I had a lot of experience already when I learned the principles behind Design for Business Value, incorporating them into my daily work was a real transformation for me. I feel like it unlocked a whole new world and gave me the tools to be far more successful for the rest of my life."