In these early days of a new century, distributed systems are growing through the business world like vines, unstoppable and inextricable. If you or your clients aren’t yet being pulled into the ERP universe of cross-company systems, the changing nature of business will probably push you in this direction soon.
As a consequence, project teaming between companies is increasing, as many consultants will attest. The flow of data is being turned up: That’s why Web services, EDI, and other data transport technologies are proliferating at such an incredible rate. These are bridges, and they are springing up exponentially, but between companies of long association, bridges are often not enough. Aqueducts are required as ambitiously integrated applications (particularly in supply chain relationships) call for mutual project participation between development personnel in different companies.
If you’re going to team up with another company, team up well. Here’s a list of considerations that supervising managers should tackle together in configuring projects to be shared across company lines.
More on cross-company cooperation
Be sure to read Scott’s article “Distributing authority helps cross-company projects succeed.”
Get the users together
The role of the user in system design has clearly increased by a couple orders of magnitude in the past decade, and will rightly continue to do so. Consider what you can do to optimize user participation in a cross-company project. Getting extensive user input on either side of a shared application is well and good, but you must consider the synergetic benefits of getting both user groups together in the same room.
In the supply chain example, it could be that your primary distributor’s frontline people could benefit not only from knowing about order changes as they occur, but also about order errors as they are reported, whether or not purchase order revisions result. Maybe they track these things and it’s useful for inventory. You might never have learned this if stakeholders hadn’t sat down and talked about it. The point is, create the opportunity. Get senior management to spring for a two-day conference, complete with lunchmeat and cheese.
Manage by consensus
If you want truly productive and synergetic teaming, then do some personal teaming as well. Get together with your analog in the partner company and discuss the project in detail, not for the sake of project plans, but for the purpose of identifying tasks and decisions that you can oversee together. Since you’re going to ask people on both sides to work together, be certain you avail yourself of the same opportunities and benefits. Agree that it is more about mutual success than pecking order, and be willing to relinquish some authority if necessary in order to create an environment where the flow of ideas prevails. If you’re the lesser partner in such a team, be willing to take on a bit more if your analog offers it in this same spirit. You’ll not only generate more discovery in the development process, but you’ll each provide a positive example to your respective shops.
If the design doesn’t get you, the maintenance will
It’s an axiom of development work that the ability to maintain and upgrade a system is as important as the system’s initial business fitness. For this reason, it’s important that you put some knowledge transfer in place not only for design purposes, but for downline maintenance as well. Each team should loan members to the other to optimize the transfer of in-house expertise in both directions. Perhaps geography will necessitate the use of e-mail, etc., rather than physical presence; but even so, it’s to your mutual benefit to pair team members across company lines.
This isn’t just important from the standpoint of design. Maintenance and upgrades in the future will be far smoother if each company has some detailed knowledge of the other’s inner workings on the shared application. This sharing will enable faster troubleshooting and unearth possibilities in system enhancement that might not occur to anyone on one side of the fence or the other. Just as getting the users on the same page is a boon, so can be the blending of developers.
Pair up team members by their dialects
If you decide to share team members across company lines, you may wish to depart from your usual policy. If you’ve used the extreme programming practice of pairing programmers, then you are used to creating such teams on the basis of personality compatibility, breadth of knowledge, depth of experience, etc.
The point of such pairings is the sharing of system expertise, not hands-on skill transfer. So there’s no point in putting people together because they have different skills, or different skill levels, in hopes of some cross-pollination. What you want instead is knowledge of the IT side of each other’s business processes. It’s a given that both experience and perspective will differ between such team members, so your best bet as a manager in creating such teams is to minimize communication barriers, particularly the technical ones, up front. To that end, it may be best to team up such people on the basis of the similarity, and not the differences, in skill sets.
Putting two programmers of common background together becomes a plus, not a minus. They will spend less time explaining themselves on coding issues and decisions, and more time discussing design particulars and the overall system impact of their work, and in this case, that’s what you really want. You don’t care about making better programmers here, as you do in XP—you care about creating systems expertise, for the sake of future maintenance.
The teaming described above operates by different rules than the teaming you create in-house. For better or worse, there’s more of it on the horizon. New issues will come up that you’ve never had to deal with among your own people, such as the distribution of authority. Communication conventions will require some modification, and your efforts to optimize your resources to get a good result will be less certain. But some forethought today will make you more skilled in this kind of project tomorrow. Be flexible enough to consider entirely new ways of teaming, and be the best partner you can be with your counterparts among your allied companies. It will come back to you someday, and probably someday soon.