Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?

share|improve this question
    
I think your question may need a little work. The question is a little incomplete and possibly too technical for this forum. –  allnightgrocery Dec 19 '12 at 14:59
    
I assume this question is a subset of this one: pm.stackexchange.com/questions/8286/… –  Tiago Cardoso Dec 19 '12 at 16:25
    
Am possibly a lazy reader but so far I have not yet seen any methodology on applying agile approach to ICDs. The problem is of course who is going to mediate N(N-1) ICDs among N teams and how it's going to work... –  Deer Hunter Dec 19 '12 at 16:39
    
@allnightgrocery: (quite a bit) of details about my project are here: link –  mrkafk Dec 20 '12 at 17:56
    
@Tiago Cardoso: yes. Should have included the link.. –  mrkafk Dec 20 '12 at 17:58
show 2 more comments

5 Answers

up vote 5 down vote accepted

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 team that will be using the deliverable
  • The team that will be producing the deliverable
  • The team that will be providing the input going into the deliverable

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

share|improve this answer
    
you're a goldmine! I have to say heartfelt thanks! It starts to come together I think (work package, ICD maybe + kanban + responsibility + tailoring and active oversight you mentioned in another thread). –  mrkafk Dec 20 '12 at 18:38
add comment

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.

share|improve this answer
1  
A very good answer to a rough question! –  Tiago Cardoso Dec 19 '12 at 16:26
    
"Either way, if you don't agree to intra-team requirements, you are not managing the work." - you nailed it I think. –  mrkafk Dec 20 '12 at 18:14
add comment

Yes, 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:

  • Format(s) of the data.
  • Method of transmission (file, SOAP, REST, other).
  • Batch sizes if data will be transmitted in batch.
  • Expected response time (especially for interfaces accessed for OLTP).
  • Availability schedule.
share|improve this answer
add comment

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.

share|improve this answer
    
The reason I'm thinking about forcing the teams to do it is that when I floated my idea calling it "contract" (completely spontaneously without reading any background info), the idea was sent such a barrage of flak I can't even find the pieces. –  mrkafk Dec 20 '12 at 18:17
    
Flak in the air strongly suggests an XY problem. I suspect that the problem isn't quality, it is leadership. The teams seem to perceive that their interests are in tension. Which suggests to me that "force" will exacerbate the problem, rather than solve it. Best of luck! –  Mark C. Wallace Dec 20 '12 at 18:38
add comment

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.

share|improve this answer
    
There's a problem of "internal perspective" here: even with lots of good will, people tend to take that their [data format|API|problem definition|whatever] is correct and it's the other team or person that should change theirs. Also when teams A and B change their method of communication it has impact on teams C and D and possibly E. Nasty problem we have (lots of cross-cutting concerns among subsystems and problem domains). –  mrkafk Dec 20 '12 at 18:11
    
Your comment reinforces my answer on your other question. Sounds like you need a cultural change agent. [Here's the question I'm referring to pm.stackexchange.com/questions/8286/… –  Mark Phillips Dec 20 '12 at 18:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.