Posted by: Jeff Timmins | May 6, 2014

Should RM perform PM tasks?

Should a Release Manager perform Project Manager tasks in addition to their normal tasks?

Since I’ve taken the title of Release Manager in 2007, my role seems continually connected to the role of a Project Manager.

At parties I’d hear – “What do you do again?” from non-technical people with a blank look to which I reply “It’s like a Project Manager.” When applying for a job I’d get the question – “What would you say are the differences between an RM and a PM?” When reviewing lessons learned from a previous Release I’d hear – “Things were missed because no one was managing the overall calendar” and I reply “where is the PM for this project?” but they just look at me (the only RM in the room) as their PM solution.

I agree there are similarities to the RM & PM roles and I think a good Release Manager needs a few PM tools in their belt. I also believe that an experienced Project Manager can add value to a company that produces Software – especially if multiple teams contribute to a Release.

This leads me to the question “should a Release Manager perform Project Manager tasks when they already have a lot of other tasks to accomplish?

  • The easy answer is “No” – focus on what you need to do in order to complete your assigned tasks to protect your yearly review.
  • The hard answer is “Yes when it makes sense.” Saying it another way, “Yes” when it is required to reduce the Risk for one of the applications/solutions you support.

I remember a simpleSAMLphp update to be applied to Servers supporting multiple solutions and all of those solutions having different Release cycles. The plan provided by the people running technically projects was to deploy the update to all the QA Servers in the company, then deploy to all the Staging Servers, then to all the Pre-Prod Servers and finally to all the Production Servers. My reaction was “Hold on, this doesn’t look right” and I proceeded to tell them I wanted to stagger the updates to align with the individual solution’s Release cycle. Fortunately they wanted me to schedule the updates so I got my way. I took it upon myself to create a schedule (taking the role of a Technical PM) that aligned the simpleSAMLphp update to already scheduled code updates. This allowed the QA team to verify one solution at a time in progression of environments before the change went to Production. The previous plan would have added the simpleSAMLphp update to an environment in the middle of code testing. This could have caused a scenario where code was being verified in Staging with the update but it would be deployed to Production without the simpleSAMLphp change included. This leads to invalid testing results and possible confusion when code works in one environment but fails in another.

Because I was able to act as a Project Manager for this update it took longer to get the change to Production but it was done with minimal Risk instead of high Risk. Sadly I received a lot of negative comments (mostly behind my back) because of this plan because I acted “out of turn” for what a Release Manager was suppose to do. Even worse, my manager didn’t see the benefit of what I had done so he agreed with the negative comments.

Would I do it again – oh yes, I would repeat those actions again and again if it was the only way to reduce Risk for the solutions under my care. That is a big part of my job – reducing the Risk of change!

How about you?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: