In his landmark 1975 book on software engineering, The Mythical Man Month, Fred Brooks (the manager who led development of IBM’s original mainframe operating system OS/360) set out to describe why software projects are almost always behind schedule and over budget. He concluded that the limiting factor of any software project is the communication between the individuals engaged in that project. He goes on to assert that adding manpower to a late software project makes it later because each additional individual causes a significant increase in the amount of communication necessary to make the project run.
In the vast majority of technology projects, whether they’re infrastructure, network, or apps development, it’s rare that the challenges faced are actually technical challenges. Perhaps if we’re engaged in high-end scientific computing or trying to build a new artificial intelligence system that does something no one has done before, we’re facing real technology challenges. But for most of us, the problem is one of coordination and communication. We have the technological capability to accomplish whatever it is we’re trying to do, and our challenge is to get the information into the hands of the right people.
Despite being almost 40 years old, Brooks’ book is surprisingly relevant to the modern IT environment. What’s interesting is that almost all of his conclusions have remained relevant – because it’s not about computers but about how humans interact with one another. When working on a technology project, everyone has to make decisions. Far more often than in most areas of human endeavor, these choices will affect the other people working on the project, which will collectively change the outcome of the project – timing, quality, and price.
An outsourced infrastructure or network environment (or even an insourced one) has many of the same challenges as a software development project. During the procurement process, a pursuit and negotiations team is brought in to develop a solution for the client. Most pursuit teams have a group focused on the technical solution being built, a group responsible for financial provisions and pricing, and executives who negotiate the MSA and overall deal terms and structure. One of the biggest risks during the procurement process is that the solution gets out of line with the financials, or that the solution gets out of line with what’s actually needed within the client environment. Some of the most significant business case problems occur not due to financial miscalculations but because of disconnects in solution and service scope.
After a solution is negotiated and agreed upon, a transition team comes in to move the client to the agreed solution. In many cases, most of the negotiations team goes away and the transition success is a function of how well the created solution is communicated to the transition team. And then, when the transition team has completed its effort, a steady-state team takes over. Again, a series of handoffs occur, so continuity and communication are the order of the day. Finally, once a provider has fully transitioned, it must interact with other service providers or internal IT organizations.
This situation occurs over and over again in miniature throughout service delivery. A project team meets with the customer to determine the infrastructure architecture that will be used for a new application. An implementation team needs to take the handoff from the team that did all the design work to stand up what was agreed upon. Ultimately if there’s a problem with infrastructure, some steady state team will need to understand how it’s architected in order to solve that problem. The finance team will need to understand what was stood up to be able to bill it.
The opportunities for communication or responsibility gaps affecting end customers are legion. The remedy for these problems is high quality communication. If we had a set of omniscient individuals and were able to somehow talk them into doing IT service delivery for us, all of these things would work perfectly. Unfortunately, we’re largely stuck with normal humans who only know some things – not everything. To the extent that we can make communications between these individuals flow better, we will achieve better results.
At heart, cross-functional services are about improving communication inside of an organization. The person who installed an application knows what server it’s on, but for any given person in the organization trying to solve a problem, it’s very helpful if there is an up-to-date CMDB record with that information. Likewise, if there’s a recurring issue with an incident, having an up-to-date known error database makes it so that anyone in the organization can solve the problem a second time rather than the just the first person who solved it the first time.
Traditional monolithic outsourcers and internal IT organizations both struggle with cross-functional services. It’s a set of disciplines not directly related to technology, and as a component of IT that is not customer-facing, it often ends up on the low end of the priority totem pole. Everyone realizes that this will cause problems in the long term, but immediately all of the focus must be on customer application X. Additionally, when choosing a service provider, one also has to pay an awful lot of attention to their technical capabilities. It would never fly to say, “They lack the skills for service delivery and incident resolution, and they don’t have enough capital to refresh my hardware, but you should see the fantastic set of reporting tools and processes they have.”
Luckily we don’t have to get our technical service delivery and our cross-functional processes and reporting in the same place. We can stand up a multisourcing service integrator (MSI) to provide the cross-functional services and a set of technical tower providers to provide services like mainframe, server, EUC, etc. In addition to the benefit of being able to hire a specialist in cross-functional services, it also solves some incentive problems (e.g. the firm calculating charge-back or SLAs does not stand to gain anything if the numbers are overstated).
This model is more complex to stand up than a monolithic outsourcing. Time has to be spent exploring how the parties will interface with and support each other, a series of OLAs will need to be written, integration sessions will need to be held. But because the effectiveness of the communication environment is such a strong predictor of the success of the whole environment, in general once stood up, an environment with an MSI will run better than one without. Much like a modern airplane is more complex to construct than an early airplane but goes much farther and is quite a bit safer, the services integration model of sourcing takes some effort to set up, but in the long run is more efficient and produces results.
– Chris Payne
27-Apr-2014 – [bio]
