Nelson's Ship in a Bottle on the fourth plinth at Trafalgar Square, London, by Yinka Shonibare © Elizabeth Harrin

Students coming to study in London for the new university term will quickly realise that in the capital you generally do not assume positive intent. In fact, Not Assuming Positive Intent is the default.

• You assume that other commuters will fight you for the last tube seat.
• You assume that your pockets will get picked in a crowd.
• You assume that your council will make a large proportion of its money from unfair traffic fines.
• You assume that foxes will rip open your bin bags and spread your rubbish all over the streets.

London natives are hardened by poor public transport, cuts to local authority spending and the expectation of negotiating crowds of tourists watching street entertainers (Edinburgh also suffers from this).

However, in the office, project managers should assume positive intent. People do not come into work to do a bad job. Things go wrong on projects – we know that. But generally this is because the processes fell down, communications failed or the responsibilities were not clear. It is not because people deliberately do stupid things in order to trip you up.

Positive intent means assuming that project team members are genuinely interested in doing a good job. People try to do the right thing within the confines of organisational culture and process. They might not be very good at their job, but that is a different issue.

On a project, assuming positive intent means treating people as adults. Don’t follow up because you think they won’t do the tasks that you have given them. Follow-up because you want an update. Don’t work on the basis that people will do the minimum amount possible therefore you have to be on their backs all the time. Assume they will do their job to the best of their abilities.

Assuming positive intent has helped me create project teams with a mature outlook to their work. How far has assuming positive intent worked on your organisations? Let us know in the comments.

Oh, and I dictated this with the Dragon NaturallySpeaking application for iPad which is another example of why iPads are great for business.

 

Related posts:

1. Consultation on positive discrimination Kingsley Napley sends the womenintechnology.co.uk network a quarterly update on employment law, with a focus on how it impacts women in the workplace. One particular...

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.

Changing working relationships is often more about culture than concrete tasks, but there are some things you can do to smooth any blips in the way that project managers and business analysts work together.  Here are four tips:

Roles and responsibilities matrix
Have a roles and responsibilities matrix for the project.  If you are a BA and there isn’t one for your project, get your project manager to do it.  There’s an interesting debate on betterprojects.net about roles and responsibilities matrices.  For me, they are a useful starting point for who does what, which can help ensure that everyone is clear about what is expected of them.  They can also act as professional development guides, so a PM who wants BA experience, or a BA who wants PM experience, can see what the other role involves and who is doing it, and some development activity can be built around that.  However, writing it down on paper will not mean people will abide by it.  Worst case scenario, it creates a ‘that’s not my job’ mentality, with people hiding behind the matrix.  Still, it can provide the opportunity for a helpful debate about who does what, which should avoid some of the “What does a BA do again?” questions.

Know the goals of the project
Common goals are such an important thing on the project.  The difficult thing is that often people will get different things out of the project and as such their personal goals might not be aligned to that of the project.  Even so, you should strive – PM and BA together – to ensure that the whole project team is clear about the outcome and goals of the work to be undertaken.  It makes teamwork a lot easier when people know what they are working towards and can clearly see how their contribution fits in.

Balance “schedule/budget” with “quality/stakeholder satisfaction”
Project managers care about schedule and budget.  It’s unfair to say that we don’t care about quality and stakeholder satisfaction, but we can lose sight of those elements.  As a BA, challenge your project manager to keep quality and stakeholder satisfaction always in the foreground.  There is no point delivering a project on time and under budget if the end product is rubbish.  Sometimes project managers are so driven by dates and money that we forget that the result has to be a useful, workable solution for our customer, meeting all their functional needs.  Remind us!

Value the contributions that everyone makes
Valuing the contributions that everyone makes sounds all fluffy, but in reality it’s about the professionalism and respect that comes with knowing you are pulling for the same goal.  It’s also about not doing someone else’s job.  Tell people to back off and let you get on with it if they tread on your toes.  And most importantly, share your exasperations.  At the Business Analysis conference where I gave a version of this paper, we asked the audience how many of them had issues in their working relationships with their project managers.  A generous proportion of them put up their hands – and kept them up when we asked if the problem was the other person’s fault.  Interestingly, very few people had done anything about it.  Nothing changes unless you talk about it and work to fix it!  Whinging to the cat when you get home won’t make your working relationships with your colleagues any better.

Missed 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 value

Related posts:

1. 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...
2. 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...
3. 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...

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 worry: it’s not that bad!

The differences in the ways that project managers work and the ways that business analysts work means that it’s not always easy to work together.

For example, project managers don’t like working with business analysts who insist on the slavish application of the Business Analysis Book of Knowledge.  You must tailor your methodology, choosing the bits that apply to your project.  To be fair, we don’t like the slavish application of any methodology: PMBOK, PRINCE2 or anything else.  Don’t complete methodology process steps for the sake of it.  If it isn’t relevant, don’t do it, whatever ‘it’ is.  It will just be a waste of your time and not valued by the rest of the team.  Learn to pick and choose from your methodology and only use what makes sense in the context of your project.

We don’t much like lots and lots of detail either.  That isn’t to say that BAs shouldn’t do it: after all, someone has to.  BAs care about quality and stakeholder satisfaction and this is evidenced by the detail required in functional analyses, swim lane diagrams and use cases.  What I mean is that we don’t really want to hear about it.  Tell me what the requirements are and I will trust that you have run the workshops to get it right.  I don’t need to live through a blow-by-blow account of your customer interviews.  This ties in to the communication point I mentioned last week: it’s all about tailoring your communication to the audience who is receiving it.

Finally, we don’t like an ‘I just need to…’ attitude.  I’m sure you have all worked with someone who wouldn’t give up a task until they were completely sure that everything was validated, ratified and signed off in blood.  In a modern, agile, business, that doesn’t wash.  Sometimes, good enough is, well, good enough.  Don’t strive for perfection in tasks where it doesn’t matter.  Apply the Pareto principle: sometimes that final 20% won’t make a significant enough difference.  So drop it.  In order to hit those OTOBOS principles, you need to take the approach that you have to start a task at some point.  Being held up by ‘I just need to…’ people means frustration and slipped milestones for everyone.

Next week I’ll be talking about how to improve the working relationships between project managers and business analysts.

Missed previous instalments of this ‘working together’ series?
Read part 1 here:  the triple constraint
Read part 2 here: what project managers value

Related posts:

1. 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....
2. 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...
3. 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...

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 managers value in our working relationships with business analysts.

Project managers see BAs as architects.  They are detailed, they decide on and build solutions, they work in a methodical way.  There are often multiple iterations to their work while they strive to get the ‘right’ solutions for the business and the customer.  Project managers like solutions.  We like things all neatly tied up and ready for us to implement.  We’re impatient in the analysis phase and we just want to get on and roll out the BA’s great invention.

We also like communication.  It’s not a good idea to keep all your knowledge to yourself.  It doesn’t make you more powerful, it just makes you difficult to work with.  And everyone wants to work with people who are easy to work with.  So ‘do’ communication.  Find out what the project manager wants and give it to them: weekly written update, phone call a couple of times a week or – heaven forbid – a daily log of activity.  Personally, I think this is overkill but it does depend on the type and scale of the project, and whether or not you are a contractor.

Allied to communication is accurate estimates.  We know it is hard when a lot of BA work relies on interviews with and validation from end users.  It’s fine to give estimates in a range:  4-6 days, 15 days +/- 30%, and so on.  It’s even better if you can provide estimates that say that work is due to finish at 3pm on Thursday afternoon, but in real life that’s rarely possible.  The reason that this is so important to us is that we normally have people scheduled to do things with whatever the outcome of the BA task is.  For example, when a functional spec is complete it will be passed to a techie to produce the technical spec.  Good estimates help project managers to plan dates and resources.

On the subject of planning, project managers appreciate it if you hit milestones.  There are very few reasons why you wouldn’t be able to hit a milestone, and there is nearly always something a PM can do to make it easier for that milestone to be reached.  For example, we can provide more resources, do other tasks in parallel, or – worst case – move the milestone to a more realistic date and reorganise everything else around it.

With that in mind, we appreciate early warnings.  If you know you are not going to hit a milestone, tell the project manager as soon as you can.  With notice, we can move things around – or provide help to get tasks back on track.  There’s often very little we can do at the last minute, apart from standing there and watching while our carefully constructed plan falls apart, before pulling ourselves up by the bootstraps and designing a new one.

Business analysts often have a much broader and deeper view of the business than project managers, and spend a lot more time with business people.  Early warnings also apply to risks and issues: if you notice something, please tell us.  Getting a risk on the register early gives us all more chance of doing things to make sure it doesn’t materialise.

Even so, we’d prefer that there weren’t any risks or issues and that everything was right first time.  This is often a problem for business analysts (and everyone, actually) because so much of the role requires input from end users who are not themselves right first time.  We value a ‘right first time’ attitude, even if it isn’t practically possible, because rework and changes are costly and complicated.  While we can nearly always accommodate changes, it is a lot easier to write in that key piece of software functionality that the users must have at the beginning, rather than realise we left it out with three weeks to go.

So, to summarise, project managers value:

• Solutions
• Communication
• Accurate estimates
• Hitting milestones
• Early warnings
• Right first time.

Essentially, it boils down to things that help us keep the project on schedule and on budget – those critical elements of OTOBOS.

Next week: what project managers don’t value when working with business analysts!

Related posts:

1. 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...
2. 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...
3. 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....

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:

1. 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...
2. 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...
3. 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....