My project consists of 5 sub-teams and I think that what most people under-appreciate is subsystem communication.
Do you think that teams using (or even being forced to) contracts between them to specify input data, output data and possibly communication protocols/calls would be a good idea?
The answer is an unequivocal yes. If the input came from an outside vendor, you would certainly have an agreement in place in terms of quantity, quality, specs., costs, whatever. Why would it be any different if the input came from a source internally?
Now, by contract, most would assume some type of paper agreement with signatures. Some teams could require such a thing, e.g., if you were crossing organization divisions, while others would require a simple verbal agreement and handshake. Many team charters can also capture rules of engagement, as well, to a certain level.
Either way, if you don't agree to intra-team requirements, you are not managing the work.
You don't need contracts. You need clearly defined requirements documents for each of the deliverables being produced. These should be written collaboratively by at least three teams:
The end result should be a series of overlapping documents that provide clear accountabilities for delivering necessary requirements and outputs for each deliverable.
This collaborative document should be reviewed by the PM and his team to ensure there isn't any gold-plating going on, the deliverable is within scope, the quality and acceptance criteria are clear, roles are defined, etc etc. A good example is the work package template from PRINCE2. You can get this and other templates [here].1
It starts to come together I think (work package, ICD maybe + kanban + responsibility + tailoring and active oversight you mentioned in another thread).
– LetMeSOThat4U Dec 20 '12 at 18:38Yes, you certainly should have a written specification of outlining the interface between the sub-systems. This will form the contract between the teams involved. Both (all) should be involved in the writing of the specification. Depending on your documentation style, this could be a wiki page or other online document.
Some of the things I would cover include:
I can envision the problem to which you refer, and I agree that it may be worth proactively solving. (Proactive solutions involve governance/political capital/stakeholder management. In some environments, political capital and governance are extraordinarily expensive, so it may actually be long run cheaper to plan for failure and solve the problem retroactively).
On the face of it, this is either a quality problem or a risk problem. Team A feeds Team B; Team B needs to express the desired quality standards, and team B needs to plan to mitigate the risks if the quality standards are not met. As @David Espina says, if you're not managing (intra team) requirements, you're not managing the work. If we're talking protocols, inputs and outputs, then the common desire for an excellent result compells us to share very detailed information about expectations.
Does that involve a formal SLA for the teams? That depends on the relationships involved. If the teams are close and cooperative, then a formal SLA may actually inhibit innovation and improved quality. I get nervous when you introduce the term "forced to", because I think the cooperation is probably more important than the actual quality of any part. If you don't have the intent to cooperate and to make each other look excellent, then you may have an XY problem, but perhaps I'm reading too deeply there.
Jumping off the Agilish tenant of focusing less on the documentation and more on the people, rather looking to a contract to specify what is needed, focus on setting up an environment that encourages open, consistent and accurate communication.
Fortunately, given system decomposition we would not have to have 20 contracts. It would be like 5.
– LetMeSOThat4U Dec 20 '12 at 18:07