Intercompany development initiatives are increasing like never before, owing largely to the advancement of data transport technologies like Web services and EDI and the proliferation of ERP platforms that make it possible to share distributed applications between companies. The more complex the applications, the greater the need for development teams to work together between the partner companies sharing the applications.

This extended teaming is of invaluable benefit to the development process because it enables an enhanced design process, a stronger platform for maintenance and upgrade, and knowledge transfer between teams. But these benefits won’t come about if you don’t have clear lines of authority established to bring the project together in the first place.

Manage together
Before distributing authority on a major development project, agree to share it. Discuss the project from top to bottom with your counterpart in your partner company, and reach an agreement to share the decision-making and keep one another completely informed. For example, you might agree that each of you should tell your people that any project e-mail or other communication addressed to one of you should be copied to the other.

Strive for equality, even when it isn’t there
Did you initiate the project? Is your company the one pushing the new application? And, most importantly, is your company the stronger partner in the relationship?

If you answered yes to any or all of these questions, you need to make an effort to leave the power politics to the people upstairs. Whether your counterpart sees it this way or not, your troops may feel that you’re the big dog, and the other guy is the little dog. You can accomplish a great deal by discouraging this perception among those who will do the actual work.

Even if you’re the more powerful partner, you should approach your counterpart and the other team as equals. Share decision-making power as liberally as possible, and make decisions together when you can. Even if your companies truly aren’t equals in the project, you should strive to establish as much equality as you can, especially at the hands-on level. This will pay huge dividends in cooperation, team spirit, and the willingness to go the extra mile to make the application a success on both sides.

Preserve existing authority chains
As far as you can, you should try to limit procedural changes to enhancing the chains of communication. The idea in distributing authority is not to alter current structures but to broaden them by putting enhanced reporting procedures in place. Your team members won’t be reporting to new authorities so much as sharing what they’re reporting with more people. In a cross-company project, “distributed authority” should really be more about distributed communications than disrupting the existing chain of authority. That way, existing authority is empowered instead of threatened or bypassed, and those in authority will find their day-to-day influence enhanced.

While you may want to exchange team members at certain points, try to keep actual lines of authority and accountability as stable as possible. You want your counterpart’s people to keep you informed, and vice versa, but you don’t want to create the impression that your team now has two bosses instead of one.

With e-mail and other communication technologies, keeping people informed is easier than ever. But when it comes to letting your people know where to go to ask permission or report a problem, you want to lessen confusion, not increase it. Don’t make changes to the existing authority structures unless they’re absolutely necessary.

Introduce the users and empower them
If you’re going to redistribute authority, the place to do it is among the users who will contribute to the project. Why? Because synergy among users will buy you more than the synergy of blended teams. You’ll go much further in advancing application function, design, and maintainability on both sides if you bring the users from both companies together and give them broad input in the design process. Of course, this means keeping them well informed, involving them in testing, and allowing them to review the evolving system at every stage of development.

There’s another important factor here. If you give power to users—be it veto power on design issues or the authority to request repeated tests—then team members on both sides should understand that this authority is temporary and is no threat to their usual comfort zones. This will help reassure them that things will return to normal after the project is done, and that it won’t result in a permanent reshuffling of the internal pecking order.

Don’t sing solo; sing in the choir
There are two final points. First, there are inherent checks and balances in reporting to senior management in tandem with your counterpart in the partner company. You’ll each add important details that the other might miss, and you’ll catch each other’s mistakes. You’ll also present a unified front to senior management, and inspire confidence that the joint project is well in hand.

But you can go a step further. Where possible, meet jointly via teleconference, or, if geography permits, hold actual get-togethers. Include as many parties from both sides as possible in meetings where team-level discussion will occur, and extend this openness to presentations in the project’s later stages. Try to create an atmosphere of one big happy family, even if it’s somewhat exaggerated. Nothing makes team members feel included like including them. The most you’ll lose is a little telephone time or a few sandwiches. But the goodwill and team spirit you’ll gain could make all the difference in the final product.