Project manager route or business analyst?

[TykeMerc]

Now you've started me thinking maybe I should bail out of dev work and go the BA route myself!

Almost all of the BA's I worked with at my last gig had come from development in some form. The head BA who also did the department resourcing and some of the Programme Management was a developer first as was a very young (27) but very capable PM.

[Bluebird]

Where possible the software developers should be included in the requirements gathering phase...

Of course if you are gathering requirements, you may not as yet have an outline solution design, and therefore involving developers is limiting your potential solutions

[TykeMerc]

Of course if you are gathering requirements, you may not as yet have an outline solution design, and therefore involving developers is limiting your potential solutions

Not necessarily, having software developers available as part of the requirements gathering team does not imply an IT solution will be inherent to the solution design. I've had developers state clearly that new development would be a workable but sub optimal solution on many occasions.

[tim123]

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.

I agree (almost entirely) with what Nick said.

I think you read what he said too quickly and invented too much of your own into it (or just over emphasised his use of "merely"). Or perhaps you snipped the bit with the problem, IMHO there is nothing at all wrong with the bit that you left.

ISTM that there is a huge difference between a development that is intended to serve a purpose and a development that is THE PRODUCT for sale, the latter is not just restricted to a piece of software that runs on a PC.

Your comment is ridiculous when viewed from a company where the product is the development of an IT product (using the term in its expanded sense). It is ABSOLUTELY impossible for this type of product to exist without IT, because it's (by definition) inside the flipping product.

tim

[tim123]

What I was trying to say is that a BAs scope is not just about software and systems implementation - BA's get involved in process improvements and solutions that don't involve hardware or software of any nature.

I understood what you were trying to say.

What I am saying is that this role does not transfer to every company as you seem to imply that it did.

For some types of company, the only thing that you can do to improve the product is to improve the IT within the product. Because of the nature of the product, there is no scope for any other type of product improvement.

I accept that it is often possible to improve the methods that the team use to perform their development (at its simplest lets say, by the use of a CM system), but to me that's not the task of a BA, that the task of the Development (Software/Hardware) Manager.

Tim

[mailric]

I think most of these posts just prove the worth of a decent BA and PM.



Some people will just never get it.

[TykeMerc]

I understood what you were trying to say.

What I am saying is that this role does not transfer to every company as you seem to imply that it did.

For some types of company, the only thing that you can do to improve the product is to improve the IT within the product. Because of the nature of the product, there is no scope for any other type of product improvement.

I accept that it is often possible to improve the methods that the team use to perform their development (at its simplest lets say, by the use of a CM system), but to me that's not the task of a BA, that the task of the Development (Software/Hardware) Manager.

Tim

To an extent there's a fair bit of talking at cross purposes here, you've got developers who work for pure software houses turning out product which is obviously almost pure IT and several PM's who are used to implementing multiple IT systems at or for customers where the situation is obviously far from pure IT and in fact quite often isn't IT at all.

Much of my recent PM work has been ERP related and therefore complex modular installations requiring all sorts of stuff from infrastructure through software, training, BPR, customisation, configuration, data migration, interfaces and even outright bespoking. I usually get contracted by the user rather than the supplier side too so my perspective is based on the complete life cycle from the client end.
The requirements for these projects are far from being a simple (or complex) software spec and need BA's, extensive Business input and vendor technical staff to produce, review, revise agree and then design a solution part of which is usually IT.
To a software house a BA is of more limited use in product development than they are in implementation phases, module selection, testing, training, BPR advice and software exploitation all make use of the BA's business focus.

[tim123]

To an extent there's a fair bit of talking at cross purposes here, you've got developers who work for pure software houses turning out product which is obviously almost pure IT

Actually I'm (and perhaps others are) coming from a direction where I develop software that forms the controling part of a "boxed" product sold to a customer as a non essential purchase.

Think: Mobile Phone, Digital Set-Top Box, Sat Nav, Telecommes Switch or even a complete Aeroplane.

I defy a BA to "process out" the "technology" in these developments and still leave a viable business case for the development.

Though I agree that there is some scope to change the technology.

tim

[malvolio]

Sorry, but even if you are king if software developement in IT Dev Corp, doing nothing but turning out IT stuff with no other component but other bits of IT and celebrate IT day along with al the other geeks...

There is still a business element to get your carefully crafted product from your workstaion to the outside world. There's also a business element to prove there's some point in writing the damn IT thing in the first place.

My clent has a single production line a third of a mile long that does nothing but turn out plasterboard. But there's quite a lot of business activitiy going on to work out what to do with all that plasterboard coming off the line at 20 mph, 24 hours a day...

It might be a trivial element in some organisations but there is always a business component, and some poor benighted fool with a PM hat had to put a bit of effort into making it happen.

[tim123]

Sorry, but even if you are king if software developement in IT Dev Corp, doing nothing but turning out IT stuff with no other component but other bits of IT and celebrate IT day along with al the other geeks...

There is still a business element to get your carefully crafted product from your workstaion to the outside world. There's also a business element to prove there's some point in writing the damn IT thing in the first place.

My clent has a single production line a third of a mile long that does nothing but turn out plasterboard. But there's quite a lot of business activitiy going on to work out what to do with all that plasterboard coming off the line at 20 mph, 24 hours a day...

It might be a trivial element in some organisations but there is always a business component, and some poor benighted fool with a PM hat had to put a bit of effort into making it happen.

I never said that there wasn't.

All I said is that a solution which replaces the "technology" with a "process", isn't possible (if you are to have an end product to sell) and saying that the person employed to do (your bit) above should also be looking for this replacement, is a nonsense.

tim