Progression towards Project Management...

[beercohol]

I am a project manager (still learning!!) who does not come from a techncial background (I am mainly from Account Management and Customer Service alhtough I have limited understanding of technical issues)

The one point I can never understand is why there seems to be an insistence that PM should work in or come from an IT background....

It looks as if the Team Managers are supplying the tech/business interface for you, and supporting you well.

Software development is a bit of an animal. Domain expertise for the PM is less important for other types of IT projects. For business process change, infrastructure, ITIL Service Management stuff, life tends to be much more tame, and the Business Analysts and other SMEs are there to help.

[Tensai]

The one point I can never understand is why there seems to be an insistence that PM should work in or come from an IT background.

Because techies have been known to bull-tulip from time to time (shocking, I know ) and having at least some technical knowledge is important to be able to determine if you're being fed a line.

Much of your point hinges on the definitition of a PM, which can be anything from "a BA with a calender" (to quote my learned friend) through to a full programme manager. The skills needed for each are different though there is some overlap.

My 2p.

[beercohol]

..."a BA with a calender" (to quote my learned friend)...

I have to second that one. It is by far the best 'real-world' description of the all-too-common PM. I hope that I can use this expression without being busted as having stolen it from our esteemed board poster!

[Maca]

Yep, the problem lies in knowing which PM type you need for a particular project. Unfortunately that's something that relies on the senior management knowing a bit about their business.

When they don't get lucky, things turn ugly near the delivery date and you see the "grownups" go into CYA mode.

[BA to the Stars]

It could be worth going down the BA route to gain experience before making the lap to a PM. You tend to work closely with PM's and do get quite a good insight.

There does tend to be more opportunities for BA's and it is a good string to have to your bow

[beercohol]

I have to second that one. It is by far the best 'real-world' description of the all-too-common PM. I hope that I can use this expression without being busted as having stolen it from our esteemed board poster!

I used to be like this when I was a young and arrogant coder.

My attitude stank at times. I wasn't helped by the high rates I was being paid, and it was before the great Bangalore-rush of the 21st century.

I find nowadays, I need to keep up my coding 'chops' to be able to see through the manipulations of coders who are like my former-self.

Of course, a great many coders are not like that, but too many of them still are for it not to matter.

[original PM]

I currently have 2 BA's working on Projects for me - they do good BA work but could not manage their way out of a paper bag!

The BA's here have quite a specific document to fill in to try to enable them to ensure they gather all requirements - however the problem with this is that if something falls outside of this document it would get missed unless I question it.

Here is a question
Does having standardised paperwork standardise the project or restrict it because everyone just goes through the motions without actually thinking about what they are doing?

Is it better to have a clearly defined goal and use the skills of those around you to ensure they understand the goal and let them come up with the best way to achieve the goals?

Because techies have been known to bull-tulip from time to time (shocking, I know ) and having at least some technical knowledge is important to be able to determine if you're being fed a line.

I agree with this but ultimately it is very difficult to tell when you are being fed a line and when the techie is genuinely telling the truth - some knowledge of what they are doing is always useful but if you are working on a project for cutting edge software or something being written in new language then it is unlikely that you will know more than the developer.

Do any PM's get hold of any code written and try and go through it to identify if the techie has been spot on or telling a lie?

[malvolio]

A while since I did a pure s/w dev job as a PM, but the control for the coders was to put them on to first-line support for the application until the call rate had dropped below a certain rate. That incenitivised DIRFT like nothing else, since they couldn't go on to the next project

As for BAs, I agree that too rigid a paper system is counter-productive and risky, but you do need a template to work with. That's the strength of people who really understand UML and its underlying approach - sadly that's not me!

[themistry]

Do any PM's get hold of any code written and try and go through it to identify if the techie has been spot on or telling a lie?

I very much doubt it. If they did, I'm not sure how credible they would be as a PM.

TM

[beercohol]

Do any PM's get hold of any code written and try and go through it to identify if the techie has been spot on or telling a lie?

Not needed as a rule, but can be very useful periodically to make sure a developer is not spending his coding time on his plan B rather than getting his actual work done. The secret for getting this data without having to know about code itself is to use Visual Studio Team System and run a code-churn report. It can be a real shocker to learn that a developer spent 4 days looking busy and only having changed one line of code (which was a comment rather than actual code).

This can indicate several things.. He may be distracted with personal issues on his mind, may be procrastinating, may be preparing to walk, may not have a clear understanding of what he needs to be doing, may be burned-out.