BAs and PMs working together (part 1)
About a month ago I spoke at the IRM UK Business Analysis Conference 2009 about how project managers work, and how business analysts and project managers can work together more successfully. As you can imagine, telling a room full of BAs that project managers don’t want to hear all that detail and analysis paralysis was received with a few sucking-on-the-teeth moments. There was a heated discussion at the end of my presentation.
If you weren’t there, don’t worry, you can be part of the debate here! Over the next four weeks I’ll be writing about the key things I discussed in that presentation, starting with an explanation of what project managers care about most: the triple constraint.
Business analysts don’t always understand where project managers are coming from. We have odd and sometimes ridiculous demands, and we walk around with Gantt charts a lot. It’s not hard to understand what motivates project managers – we just don’t bother to take the time to explain it. At all. To anyone. And then we do get very upset when people don’t understand the value that we bring to organisations (BAs: does this sound familiar??).
Project managers see themselves as navigators. We see the big picture and we want to get there as fast as possible and as cheaply as possible. We spend all day thinking about OTOBOS – or we should do, if we are any good at our jobs.
OTOBOS is also known as the triple constraint: on time, on budget, on scope. The confusion is that as project management as a discipline has evolved, so has the triple constraint, and now it includes other factors bringing the number up above three. Generally these are:
- Time
- Budget
- Scope/Requirements
- Quality
These are the ‘normal’ four. Some commentators include:
- Risk
- Customer satisfaction
as an additional two items, meaning the ‘triple’ constraint actually includes six things. No wonder project management
Even though the
“Will it deliver on the day we agreed?”
“Will it cost what we agreed?”
“Will it do what I want?”
That’s OTOBOS: on time, on budget, on scope. And if you are doing that, you are getting something right.
Over the coming weeks I’ll be writing about what project managers value in their working relationships with business analysts – and what we don’t. The final part of the series will look at how we can improve workplace harmony between PMs and BAs!
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.
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.
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.
Hey great topic.
I am looking forward to this!
Thanks for your comments, Richard. I think that goes to show that you need to agree your success criteria and measurements upfront with the rest of your project team and especially your sponsor. Because everyone has a different view of what is important to them!
I would say that requirements, customer satisfaction and quality are all included in scope.
This is because quality is mostly about how closely you adhere to your scope/requirements, while customer satisfaction is just another requirement to be satisfied.
Risk should also also included in scope/requirements. My example for this would be a start up ‘project’. If your sponsor/investors are happy with a 50% chance of failure then delivering a safe, boring, low-value product that will break even but stands no chance of being bought for $200,000,000 won’t meet the requirement – whereas a giant smoking hole that almost made it to greatness would.