Project manager route or business analyst?

[aussielong]

Ermm, bollocks.

FWIW the best PMs I've used have come up from Support, not coding. Comes from having to deal with mutliple (and usually conflicting) priorities whereas coders' problems tend to rather more linear. They also get a much better insight into the business impact of their decisions. I'd much rather they were looking after a £15m spend that people who simply follow a spec sheet...

I see the problem. You are thinking that developers as implementing a spec. That's not the job i'm doing. That's the sort of task you outsource isn't it...

The developers make or break the project. But the PM takes the winnings.

I guess there is a distinction to be made between coders and developers.
80/20. The 20% of devs that are successful do not need BAs to do their analysis. And most of the time, they do not need managing either. At the lower end of the scale, you do need a BA and a strong leader.

[malvolio]

I see the problem. You are thinking that developers as implementing a spec. That's not the job i'm doing. That's the sort of task you outsource isn't it...

The developers make or break the project. But the PM takes the winnings.

I guess there is a distinction to be made between coders and developers.
80/20. The 20% of devs that are successful do not need BAs to do their analysis. And most of the time, they do not need managing either. At the lower end of the scale, you do need a BA and a strong leader.

Erm, bollocks?

Developer or coder, you are still only part of the delivery mechanism. Go back up the tree a few steps and see where the business need comes from, who does the cost justificaiton, the projected ROIs, works out comparative priorities, synergies and a dozen other dependencies, then works out the reosurces and what is likely to go wrong and what to do when it does. Then you find someone and ask them to build "this" fairly trivial piece of the overall jigsaw. That could go to a developer, or to a BA to develop a spec for a coder. It's still only 10% of the whole.

You're mixing PM with team lead every bit as much as I'm apparently mixing coder and developer (and with over 15 years in dev up to senior AP level before I went back to Service Management, I think I know the difference...). Programme/Project management is not about IT, that's merely the enabler to a wider business change programme.

[TykeMerc]

Erm, bollocks?

Developer or coder, you are still only part of the delivery mechanism. Go back up the tree a few steps and see where the business need comes from, who does the cost justificaiton, the projected ROIs, works out comparative priorities, synergies and a dozen other dependencies, then works out the reosurces and what is likely to go wrong and what to do when it does. Then you find someone and ask them to build "this" fairly trivial piece of the overall jigsaw. That could go to a developer, or to a BA to develop a spec for a coder. It's still only 10% of the whole.

You're mixing PM with team lead every bit as much as I'm apparently mixing coder and developer (and with over 15 years in dev up to senior AP level before I went back to Service Management, I think I know the difference...). Programme/Project management is not about IT, that's merely the enabler to a wider business change programme.

AbsoFrickin'lutely.

I'm sad to admit that at least 90% of the people who wave their Project Manager titles about have absolutely NO clue when it comes to actually managing a project. I'm not in the slightest bit surprised how few of the contributors to this thread have ever worked with a decent one.

I have had the good fortune to have worked with and for a fair few decent PM's in my time and learned a lot in the process and like every one else I've had my share of Gantt Pilot PM's to whom the epithet clueless would be overly generous.

Stakeholder management is the real key to me and the stakeholders include all of the technical teams (BA's are part of the technical input to a project), Business, Management, Users the lot. Managing expectations manages requirements, specifications, risks, deadlines, opportunities, cost, quality, time, resources and any other deliverable you care to name.

As a profession Project Management is still relatively speaking in its infancy, we can only hope that it will mature and force out the incompetents. I get very frustrated by the abundance of people that call themselves Project Managers when at best they're Project Admin, Team Leaders or optimistic man Managers of various flavours.

[NickFitz]

I get the impression that a number of people are talking at cross-purposes in this thread.

It seems that some are coming from the direction of seeing application development as something that exists merely to serve some Line of Business requirement (i.e. "The folk in the back office need a system to support xyz activity for the purpose of allowing the business to improve its capabilities in abc area") whereas others are approaching it more from a product development perspective (i.e. 'We're going to make something new and bring it to market").

Personally, I find it unlikely that somebody coming from a background where product development is seen as merely an adjunct to the primary purpose of the business would be able to cope well with the alternative situation where producing the application is the primary purpose of the business.

Perhaps this explains why so many apparently experienced PMs - and indeed BAs - are so useless when there's a product to be made, rather than a business need to be met. It probably works - or rather fails to work - the other way around, too; I'm certainly not attracted to the idea of churning out boring LOB applications, as long as there are interesting new things to be created.

Maybe that's why I prefer being just a coder - I could do all the BA/PM stuff, but it seems that most of that work involves sitting in meetings with managers all day, and why would I want to do that? As it is, the understanding of business and project requirements that I bring to the humdrum task of actually making stuff stands me in good stead, and still allows me to end the day with the feeling that I've achieved something more than establishing a tenuous consensus among the heads of several different departments all desperate to protect their own little fiefdoms in the face of inevitable organisational change. YMMV

[Sockpuppet]

Just say feck it and join the boomed world of logistics.

[malvolio]

It seems that some are coming from the direction of seeing application development as something that exists merely to serve some Line of Business requirement

Thank you - you've started my day with coffee all over the keyboard...

Unless your company is in the business of producing application code for resale, that is probably the narrowest, most blinkered viewpoint I've seen in months. A company can survive without IT; IT will not survive without a company.

[Fairly New graduate]

Ok so my topic has gone right off the mark, anyone care to take it back?

[original PM]

Having deliviered a number of projects including brand new products and changes updates to existing systems I can concur with Mal on this.

IT development is normally part of any project due to the reliance on IT to drive the majority of the business processes - but I cannot think of any project where IT development is the sole workstream - even if you look at software development there will still need to be a sales and marketing angle, after sales support etc etc.

However IT is often one of the main places where money can be spent on a project and is one of the highest risk areas.

This is why when I run a project I will always try to involve developers in the whole process as if they understand what they overall goals of the project are then they have a better chance of giving a better estimate of time required and also will have the ability to spot mistakes or inconsistencies in any technical documentation they are reuqired to develop from.

And to the person who said PM's take the credit that is rubbish - if the project goes well the team take the credit - if the project goes badly PM takes the blame. - It is the same as it should be in any team within a business (sales, service, accounts etc) If team works well manager has done a good job but team have actually delivered - if team fails manager has done a bad job and so should take the blame for the problems and try to make it right.

Problem is in many companies there is a blamecentric culture and managers will be the first to pass blame over to staff to cover their own butts and therefore never learn from their mistakes.

[aussielong]

The problem is that developers are perceived as nerds/cowboys by the business, by default. Because of that, we don't get the same respect as a BA/PM.

You cannot build the products without devs. But we can build products without PMs and BAs - check the open source movement for instance.

[TykeMerc]

The problem is that developers are perceived as nerds/cowboys by the business, by default. Because of that, we don't get the same respect as a BA/PM.

You cannot build the products without devs. But we can build products without PMs and BAs - check the open source movement for instance.

Absolutely correct developers can produce products in isolation, however how many products can you afford to produce in the hope that you meet a business need with a market large enough to pay for the development investment?

One of the reasons that developers get the "cowboy" epithet from the business is because ad-hoc development like you described rarely meets the business requirements and so the business ends up footing the bill for an unsuitable solution. With proper agreed requirements a developer has a specific target to aim at and add value to. Good requirements need the skills of Business Analysis to produce.