Product Transitions or problem transitions

As a PM responsible for enhancements or maintenance of a product, that has been recently acquired by your org. You need to think twice before making any commitments. During an acquisition, in most cases the potential revenue or profit that can be generated takes precedence over the technical or engineering aspects.

The engineering team gets to have a look at the product from under the hood, only when it gets transitioned, and they are proclaimed to be responsible for the same in the future.

 

It is the PM’s core responsibility to check on the following before making any commitments on maintenance or enhancements.

 

a) Ensure that all of the necessary source code and rights to use / modify the same is available

b) Ensure availability of engineering & User documents,

c) If any third party components are used, check that the required licenses are available and support contacts are established

d) Allow for the engineering team to look under the hood, and get a good grip on the same.

e) Allow for the QA team to check on the quality and confirm that behaves the way it was expected, or whatever is mentioned in the user guides and marketing brochures are actually true

e) There will be push from all stakeholders requesting for updated product with fixes or enhancements at the earliest.

f) Resist the temptation to make any commitments (wishful thinking never helps)

 

If you are pushed to commit, indicate all of the above as risks of high impact and shout as loudly as possible (in writing), it’s ok if nobody listens to you, as long as you have evidence that you did shout.

A Case for Reqmnts. Engg. Group

If Organizations have a Process Group, Program management Group, Systems engineering group… why not a Requirements engineering group.

 

If projects are subjected to Cost and schedule over runs, one of the top causes for the same can be attributed to Poor Scope definition. So is it not imperative that organizations give due importance towards Collecting requirements and Analyzing them. (Thus enabling successful projects)

 

This would require specific skills set which would include VOC collection, interviewing, facilitating brainstorming, negotiating, and knowledge on latest technical advancement. A bit of domain understanding would be an added advantage.

While the above set of skills are about collecting information, the next set of equal importance is about the ability to clearly communicate the same in written form.

This requires the understanding of different visual representation and appropriate use of such options which include, use case scenarios, flow or process diagrams, sequence diagrams, data dictionaries etc.