Systems Archetype: Shifting the Burden to the Intervenor
There is a special case of Shifting the Burden which I am especially familiar with because I have worked as a consultant for many years: Shifting the Burden to the Intervenor.
The problem may occur when an organization decides to rely on outside competence to solve an internal problem. The problem may be solved. The catch is that the competence to deal with the internal problem now resides outside the organization. This makes the organization vulnerable if the problem occurs again.
"The organization" may be a company that outsources development work to a consultant, or outsources a part of their infrastructure to a subcontractor. Departments within an organization are also vulnerable. They may (not always voluntarily) let another part of the organization take over an important function, only to find that the other part of the organization is not able to process requests quickly (usually because of queues), may not fully understand the requests (development department vs. IT department), or may see some political advantage in not fulfilling a request.
A company needs to get a new product to market fast. There may be an economic, or strategic need, or political pressure. The company outsources development to consultants, quite often from several different companies. The consultants are done on time (well, this part usually does not happen,) but the knowledge about how the system works resides in the heads of people from other companies.
When the company needs to maintain the application, or develop a new version, it does not have the capability to do so in an efficient manner. The people who worked on the original project has dispersed, and now work on other projects, for other customers. Assembling the original team, or even a fraction of it, is not possible.
The total cost, over a few years, of outsourcing the work may be far greater than keeping the necessary expertise on staff.
Any situation where outsourcing is considered should raise an alarm. That does not mean that outsourcing is always bad, just that the consequences should be explored thoroughly. One way to do that is with a Future Reality Tree (FRT).
As with Shifting the Burden, I would like to stress the importance of making appropriate (I.e. measuring the right thing is more important than measuring with great precision.) measurements once an outsourcing plan is under way. In addition to the measurements mentioned in Shifting the Burden, it is a good thing to keep a close eye on code quality. If the quality of the code drops, development costs, in current and future projects, will rise dramatically. I have seen many companies where management are not aware of the implications of poor code quality. Software projects at these companies are always extremely expensive, deadlines are often missed, and the return on investment of the projects is much less than it could be.
Shifting the Burden to the Intervenor is often built right into the organizational structure. The most common structure today is the functional organization. In functional organizations, work is divided according to functions. For example, there may be specialized departments for IT services, methodology, and so on. This causes a number of problems, but the one we are concerned with here, is the loss of competence in software develpment departments. I have worked in development projects where nobody knows how to set up a web server, or a database server, or other important pieces of equipment. What happens is that the project organization is forced to make a request to the appropriate department, and then they will have to wait until the request is processed. In this way, even a relatively simple job can stretch out several weeks, months, or may never get done at all.
There is no "grunt work" in software development. Writing software is all about designing highly complex systems, and writing very detailed specifications describing those systems. The grunt work, building software according to design specifications, is something compilers and interpreters do, never humans. Every developer in a software development organization is a knowledge worker, must be regarded as such, must be expected to behave as such, and must be treated as such. (For more on this, I recommend you read the classic Peopleware, and the more recent (2001) Slack.)
Organize to optimize the value stream (flow organization), not to keep people busy (functional organization)! Both Lean and Theory Of Constraints have proved, both empirically and theoretically, that this is the best way to go.
Description
The problem may occur when an organization decides to rely on outside competence to solve an internal problem. The problem may be solved. The catch is that the competence to deal with the internal problem now resides outside the organization. This makes the organization vulnerable if the problem occurs again.
"The organization" may be a company that outsources development work to a consultant, or outsources a part of their infrastructure to a subcontractor. Departments within an organization are also vulnerable. They may (not always voluntarily) let another part of the organization take over an important function, only to find that the other part of the organization is not able to process requests quickly (usually because of queues), may not fully understand the requests (development department vs. IT department), or may see some political advantage in not fulfilling a request.
Example
A company needs to get a new product to market fast. There may be an economic, or strategic need, or political pressure. The company outsources development to consultants, quite often from several different companies. The consultants are done on time (well, this part usually does not happen,) but the knowledge about how the system works resides in the heads of people from other companies.When the company needs to maintain the application, or develop a new version, it does not have the capability to do so in an efficient manner. The people who worked on the original project has dispersed, and now work on other projects, for other customers. Assembling the original team, or even a fraction of it, is not possible.
The total cost, over a few years, of outsourcing the work may be far greater than keeping the necessary expertise on staff.
Early Warning Symptoms
Quite often, management is aware that outsourcing may cause long term problems. However, the short term gains are over-estimated, and the long term costs are under-estimated.Any situation where outsourcing is considered should raise an alarm. That does not mean that outsourcing is always bad, just that the consequences should be explored thoroughly. One way to do that is with a Future Reality Tree (FRT).
As with Shifting the Burden, I would like to stress the importance of making appropriate (I.e. measuring the right thing is more important than measuring with great precision.) measurements once an outsourcing plan is under way. In addition to the measurements mentioned in Shifting the Burden, it is a good thing to keep a close eye on code quality. If the quality of the code drops, development costs, in current and future projects, will rise dramatically. I have seen many companies where management are not aware of the implications of poor code quality. Software projects at these companies are always extremely expensive, deadlines are often missed, and the return on investment of the projects is much less than it could be.
Shifting the Burden to the Intervenor is often built right into the organizational structure. The most common structure today is the functional organization. In functional organizations, work is divided according to functions. For example, there may be specialized departments for IT services, methodology, and so on. This causes a number of problems, but the one we are concerned with here, is the loss of competence in software develpment departments. I have worked in development projects where nobody knows how to set up a web server, or a database server, or other important pieces of equipment. What happens is that the project organization is forced to make a request to the appropriate department, and then they will have to wait until the request is processed. In this way, even a relatively simple job can stretch out several weeks, months, or may never get done at all.
Management Principles
Don't outsource your brains! While many managers in knowledge organizations know this, as a general principle, they are sometimes a bit confused about where the brainpower in their organization resides. They believe it is with them. Not so! Nor should it be. Knowledge organizations have most of their brain power at the base of the organizational structure, by the power of sheer numbers, if nothing else. (Besides, good managers want smart people to work for them. If I ever start a company again, I'm going to make damn sure I only hire people smarter than me.)There is no "grunt work" in software development. Writing software is all about designing highly complex systems, and writing very detailed specifications describing those systems. The grunt work, building software according to design specifications, is something compilers and interpreters do, never humans. Every developer in a software development organization is a knowledge worker, must be regarded as such, must be expected to behave as such, and must be treated as such. (For more on this, I recommend you read the classic Peopleware, and the more recent (2001) Slack.)
Organize to optimize the value stream (flow organization), not to keep people busy (functional organization)! Both Lean and Theory Of Constraints have proved, both empirically and theoretically, that this is the best way to go.
Comments