Skip to main content

Author: Emily McCreadie

How Do You Manage an Offsite Business Analyst?

Do you, as a manager, actually know what your employees are doing on a day by day basis on client site? Are you aware, until their performance appraisal, of what projects they are working on and what tools they’re using to get the job done?

I am in a situation faced by thousands of consultants around the globe. How do you fairly represent your day to day job to your manager? I either end up:

  • ‘Bigging myself up’
  • Talking my achievements down

And always…

  • Getting positive but mostly useless feedback from clients

Let’s address them one by one.

Having worked on one or more projects for months, a BA (should) know each and every one of them inside out. A BA (should) know all of the things that went right/wrong, hopefully produce a lessons learned report that you (should) be able to recite in your sleep. So when describing your role in this project of course you’re going to sound knowledgeable, efficient, and demonstrate a level of understanding that would make the Dalai Lama feel queasy.

But is what you achieved as impressive as it sounds?

At this point it’s down to the manager to delve further. They have most likely been a BA at some point in their career and should know how to make you squirm!

But this is a performance review, not an interrogation!

Of course it’s not… that is why it shouldn’t come to a performance appraisal for you to know what your employees are doing. Even if you’re based in a different county you should still be able to pick up the phone at least once a month. This not only helps employees ask that annoying question about timesheets, but also feel a bond to the ‘mother ship’ and discuss that Christmas Party (did you hear what Lisa did in the boardroom?!).

At the end of the day, there is no point in exaggerating. Your manager should have regular enough contact with both the consultant and the client in order to understand what is expected of both the project team and individual employees. The same should apply for ‘talking yourself down’… there is no place for modesty in a performance appraisal. Unless you don’t like pay rises of course…

What about feedback?

It’s so rare for your own colleagues/manager to provide honest feedback why should your client? If you’re not up to the job they can just send you back to the dogs bench.

Unless I ask for feedback on specific areas I would generally receive a paragraph saying that I turn up to work on time, I do everything that is expected of me and I have a great relationship with stakeholders. Oh, and I’m really good at organising people’s leaving presents…

Surely companies should have a template for feedback provided to clients to enable them to answer honestly and fairly about the consultant? Or is it up to the consultant to have enough common sense to do it themselves?

For each of the consultant’s project related SMART objectives there should be a measure which a client can comment on. The feedback can then be sent to the manager, the consultant or both.

How many requirements document did Lisa churn out in 2013? Who’s Lisa and what’s a requirements document? Oh dear Lisa, I think we need to talk…

This all boils back to the way that your company performance manages you and your fellow employees… I just hope for your sake you’re not your company’s version of Lisa.

Don’t forget to leave your comments below.

Technology: Choice or Chosen?

Once upon a time a consulting firm bid for a high profile, fixed price project using Platform A.

I realize that I have only started reading this fairytale story but how on earth has this bid included a technology choice when they are yet to do the analysis?

The clients were delighted, as were the consulting firm when they won the > 15M contract. “And now for the real work to begin!” declared the (first) Project Manager.

The Business Analysts swooped in and worked their magic on high-level design documentation and a long list of prioritized requirements. “Wonderful” declared both the (first) Project Manager and client.

This really is a fairytale story!

It was then time for the developers to descend. They began gnawing away on a prototype on day one. “Finito” they finally declared. So off they trotted to proudly show the client what they were in store for.

Uh-oh, I feel trouble brewing…

“We never liked Platform A, we just wanted to see if we would like it more once we had seen what you had done with it…but no, we still hate it” stated the client matter-of-factly.

“Why is this? We think it suits your requirements down to the ground” quietly demanded the (first) PM.

“We have used it before, I just don’t like it, isn’t that reason enough?” declared the client, with a stomp of his foot.

The opinion of only one Stakeholder was enough to represent all interests?

The PM huffed and puffed and… was told to go and work in Siberia.

Not quite as dramatic as blowing the house down, but I’m sure it had a similar effect.

The project team were back to square one and without Project Manager, so in his place stepped in the Program Manager.

* Program Manager enters project*

Discussions were being held while the BA’s finished off their low level design documentation. It was decided that Platform B would be used instead. Unfortunately I was not privy to these discussions, however, I do think it was no coincidence that this technology was an area that the consulting firm were keen to gain experience on as the lead Technical Architect was Platform B’s biggest fan.

Did they push the client into making this Technology Choice or was there a fair analysis?

The project team and developers were then trained in Platform B and unleashed straight onto the client with some difficult questions to answer having not been exposed to the product in a working environment before.

*Expensive Contractors enter fixed price project*

The developers cracked on, the testing team were formed, the UI specification was underway… it all seemed to be back on track.

 * (Second) Project Manager enters project*

Relationships were formed, confidence restored and bridges built.

The fairytale ending?

The developers then realised the massive pitfalls of Platform B (in relation to the project requirements, not as a product) and they now had to learn Platform B’s bespoke coding language as the customisation needed was so vast. The Project Manager was not impressed with the timelines given, neither was the client.

“Why are we using this product in the first place?” The client repeatedly asked.

Tumbleweed…

The End.

Although this project has had its highs and lows I am pleased to say that it did come together in the end, neither on time nor to budget, but it did come together. Sadly it was without the fairytale ending of another piece of work.

There is no reason to point fingers or hold one person accountable when ultimately projects are a team effort. However, I do think that the team were misled in two respects:

  1. The bid team had proposed the use of a Technology before fully understanding the requirements of the project
  2. There was no analysis of other products which then provided the client with a solid reason as to why that product was chosen and which boxes it ticked

Based on my knowledge and experience I feel that it is inappropriate for bids to select a product before requirements are gathered. If I were a client I would be wary of a consultancy second guessing what the best product would be without considering other options and ‘seeing their homework’.

There are pros and cons to being partnered with a software house. In one respect you can add benefits to your clients by passing on reduced costs, more well-informed consultants resulting from reduced training costs and access to a wealth of knowledge. On the other hand they may have hidden agendas and feel compelled to sell you said software or have quotas to meet to remain a certain level of Partner.

In a perfect world I would undertake a requirements driven Technology Choice analysis and use the chosen technology to determine the software development house / vendor.

Clients take note: demand a full Technology Choice exercise, it can make or break a project. Analysts, colleagues, friends or competitors may suggest a solution that has worked for them but only a comparison specifically for your project requirements will represent the best choice and deliver real benefits.

Don’t forget to leave your comments below.


Emily McCreadie  is a London based business analyst working for BSG (Africa)’s London operation. She is interested in evolving methodologies, requirements elicitation and innovation in the workplace.