Seeing the Big Picture: Solution Design for Large Applications

We were approached to help a Fortune 100 company design a new expert-staffing application. Their problem was not unusual:

• Expert resources, billable on external projects, weren’t getting matched to new work fast enough.
• Client work was being delayed by days with missing resources causing lost revenue and dissatisfaction.
• Resources that were assigned weren’t always a match for the skillset needed.
• Highly-skilled resources sat on the bench underutilized.

We knew that large IT projects were risky, according to research by the University of Oxford and McKinsey: “..half of all large IT projects—defined as those with initial price tags exceeding $15 million—massively blow their budgets. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns.”

Rather than focusing solely on features, functionality, scope, budget, schedule, or even change management we knew that whatever solution was created would have to operate within a system-of-systems consisting not only of the technical architecture – but a “human architecture” of the firm’s culture consisting of behaviors, incentives, pressures and habits.

We identified the stakeholders in the system within the application and met with them individually and in groups. Although most participants, by habit, focused on technical wish lists and features they wanted in a new app – we quickly identified that their ‘mental-models’, the perceptions they had about the system and how it worked was as much responsible for driving low tool adoption as any set of features itself. We began identifying system archetypes aligned with the mental models of sales, staffing managers, senior leaders, expert staff (the billable resource), and the managers of expert staff.

What we realized is that seemingly unrelated pressures and incentives enacted by leadership had created a cascade effect that led to low tool adoption as everyone instead used “personal networks” reached by phone and email to place technical staff than the existing tool. Some leaders suggested a punitive approach to tool adoption, but we pointed out this would likely just create unintended consequences elsewhere in the system.

Instead we recommended adjustment to leadership pressures and management responses. This served two benefits. First it could help avoid the costs and risks associated with a ~$15m new technology application. Additionally, these pressures and incentives were creating many more unintended negative consequences unrelated to technology in other areas.