Comments on: BAs and PMs working together (part 1)

By: Elizabeth

Elizabeth — Mon, 28 Dec 2009 15:57:18 +0000

Hi Steven. It’s great to have someone who has seen it from both sides – it’s been a long time since I worked as a business change analyst. I agree that flexibility is the most important thing, and it is all about finding the balance. Too much change means you’ll never deliver anything and not enough change means running the risk of delivering something that isn’t fit for purpose.

By: Steven Mulhall

Steven Mulhall — Mon, 28 Dec 2009 13:45:40 +0000

Having worked as a BA and PM myself, I often feel that as a PM, we have locked in scope and moving forward to acheive agreed benefits and the BA is moving the goal posts.

And as a BA I feel that we are ensuring we are doing the right thing over just doing the thing right.

Both views are correct and a flexible approach is needed by both parties.

The BA should be flexible about time allotted to task and the PM about changes to requirements, a plan should not be set in stone.

We know how much of a moving target things can be and planning in most environments can be tough, to deliver quickly and the right thing to the business or to market is difficult but requires flexibility to ensure there is a chance.

By: BAs and PMs working together (part 4 | A Girl's Guide to Project Management)

Mon, 07 Dec 2009 05:38:48 +0000

[...] previous instalments of this ‘working together’ series? Read part 1 here: the triple constraint Read part 2 here: what project managers value Read part 3 here: what project managers don’t [...]

By: BAs and PMs working together (part 2 | A Girl's Guide to Project Management)

Mon, 23 Nov 2009 05:33:40 +0000

[...] BAs and PMs working together (part 1) [...]

By: Glen B. Alleman

Glen B. Alleman — Wed, 18 Nov 2009 03:33:16 +0000

An alternative, used in the US Defense and Civil government domain is: Cost, Schedule and Technical Performance. Technical Performance is more than the computer systems performance.

Technical Performance is the resulting “product or service” measures against the requirements. The two fundamental measures are: Performance and Effectiveness.

This is a Systems Engineering paradigm, but can be generalized to many domains and contexts within those domains.

The issue with scope is there is no real unit of measure in the absence of the Technical Performance Measure (TPM). So the resulting product or service can be “on scope” but not perform as required. This is common for commercial IT projects.

Here’s some background

http://www.acq.osd.mil/pm/old/Old%20Papers/Papers%20-%20Govt/TPMs/tpm/index.html