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.

In terms of releasing the code and separation of responsibilities, should it be the project manager or the release teams that inform the business of the releases? I believe it should be the release teams job. Here are my reasons why.

  • In our ALC, the release documents are written up prior to sign off.
  • We do two releases a week.
  • We run multiple project teams (6), and I would like a standard way of informing the business.
  • It requires less communication between groups, as the release team can just release instead of phoning the PM to ensure things have been sent out, etc.
  • I think part of the release is informing the business directly. It gives people outside IT more of a view of the teams worth.

EDIT- Let me add some details, the "development updates" - are added to the tickets prior to sign off, the release team just collates the information from the tickets - When there are problems with the release we roll it back immediately. Another detail is that the release team is sitting with developers, the PMs and tests sit in a different building.

share|improve this question
add comment

3 Answers 3

up vote 2 down vote accepted

Responsibility vs. Appropriate Task-Performers

While the project manager is responsible for facilitating effective communications within the team, and between the team and the rest of the organization, that responsibility doesn't mean the project manager has to be the task-performer. It is perfectly acceptable to delegate that responsibility, or to encourage the team to develop new processes or side-channels that ensure routine communications are as effective as possible.

share|improve this answer
add comment

It depends. Who informed the business before? If it was the release teams, then it makes sense to keep let them do it.

An important detail is missing from your argument. If another team is responsible for the release, all the information in the flow will be at least second handed, and in case of emergency an additional step will always be required. Imagine that something goes wrong during the release. The release team might have a clue about a possible solution, but they'll definitely need help from the development teams. If the business sends feedback, it will be - not intentionally - filtered/altered by the release team, so there is good chance to increase the number of discussions to clarify things.

For six project teams a whole release team seems a bit too much, however I know that customers like to have only one point of contact (either a person or a team). I suggest to ask the project manager of the team who is responsible for the integration to be the point of contact, and make all the teams equally responsible for the releases.

share|improve this answer
    
Thanks for the input! This assumes that feedback is done though the release team, Feedback is still done through the help desk and the PM. The release team just collates the info on the ticket and sends it out. Also the release team is required more for SOX compliance then out of necessity, however when doing trying to move to continuous deployment model, it has proven quite useful. –  Chris Greeno Jan 27 '13 at 9:49
    
I have to ask. Does your release team do devops tasks? –  Zsolt Jan 27 '13 at 13:00
    
"develops tasks"? The release team just works on the release process and automating the release process. The also do a bit of work on the ALC and automating it as well. –  Chris Greeno Jan 27 '13 at 22:41
    
I meant this: en.wikipedia.org/wiki/DevOps –  Zsolt Jan 28 '13 at 6:24
    
thanks for that link, it was very en-lighting, I have read about when Yahoo bought Flickr but have never heard of DevOps before. Can recommend any books on this subject? –  Chris Greeno Feb 2 '13 at 16:57
show 1 more comment

Whoever can best articulate what business value was delivered should do that communication. The business team's eyes will glaze over if you just send a list of tickets deployed. They don't want to hear the technical mumbo jumbo.

We created this Product Owner role and it is working out very well. My recommendation is that you create this new role. Here is a link that describes the role of the product owner: http://www.scrumalliance.org/articles/44-being-an-effective-product-owner In the meantime, assign this responsibility to the person who can best extract the business value from the list of tickets and articulate it well.

share|improve this answer
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.