BAs and PMs working together (part 1)
About a month ago I spoke at the Business Analysis Conference 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 jargon is so poorly understood outside our immediate colleagues.
Even though the jargon has evolved, most sponsors and stakeholders haven’t. They are still mostly concerned with:
“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!
Related posts:
- BAs and PMs working together (part 3) Last week I wrote about what project managers value when working with business analysts. This week I want to focus on what we don’t. Don’t...
- BAs and PMs working together (part 4) In this final instalment of the ‘working together’ series, I’ll be looking at how to improve the working relationships between project managers and business analysts....
- BAs and PMs working together (part 2) Last week I wrote about the way that project managers work, and how this relates to OTOBOS. This week I want to explain what project...
Tags: business analysis


![Validate my RSS feed [Valid RSS]](valid-rss.png)

9 people have left a comment on this post
Twitter Comment
BAs and PMs working together (part 1): About a month ago I spoke at the Business Analysis Conference about how .. [link to post]
– Posted using Chat Catcher
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.
I am looking forward to this!
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
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.
2 Trackback(s)