Business Analysts and Project Managers are special people
Business Analysts and Project Managers occupy a unique position in the table of IT elements both as discrete roles and also natural owners of other elements, Requirements and Projects, respectively. There is Testing, but no ‘Testers’, ‘Development’ but no Developers or Programmers, and ‘Design’ but no Designers. In this release there is no place at all for Consultants, IT & Programme Managers, Architects, Business Rules and Usability specialists, and, to be honest, 1,001 other roles, job titles and disciplines involved in technology projects and change initiatives. However, this post will explain why these two groups are notable.
I would classify ‘Bee-ays’ and ‘Pea-ems’ as functionaries, they bring a set of transferable skills, tools and techniques to the party and tend to perform a generic function that is similar across industries, technologies and organisations. Customers, Users, Developers and Designers are more likely to be technology- or domain-specific
(Ed. this is not a hard and fast rule, but the author’s personal interpretation).
BAs and PMs can be self-styled as specialists or generalists, technical or business, and, significantly, they can sometimes be the same person. Other ‘hybrid’ roles exist, such as Analyst/Programmers, which have an extended or enhanced remit, so not 2 roles bolted together.
Separate posts have covered some of the key features of a Business Analysts role and Project Management activities, so I will concentrate on the overlap.
Top 7 Things that Business Analysts and Project Managers Do
- Bring generic skills to a variety of similar situations. Use appropriate tools and techniques depending on the context, although this may mean challenging the status quo. For example; requirements elicitation (BA) may involve one-to-one conversations, multi-disciplinary workshops, data analysis, process mapping etc. Project progress monitoring and reporting (PM) may be linked to activities in a detailed task-level plan, by exception, or highlights and lowlights only.
- Communicate between technical and non-technical (Business) people.
- See the big picture, for example overall Project aims and objectives rather than the narrow design or implementation of a single element, although attention to detail is important as well.
- Provide continuity. BAs and PMs can be involved at every stage of a project’s duration, sometimes referred to as ‘life-cycle’, from conception to completion, whereas others may come and go as required. In the absence of Project or Programme Office, it may be the responsible of the BA and/or the PM to know where important things are kept (including the skeletons!) and why key decisions were made.
- Support the process, but be agnostic. For example, where there are conflicting priorities it is important that PMs and BAs defer to the Customers, Stakeholders or agreed positions, or otherwise act as an independent arbitrator.
- Be responsible for the overall quality of the things being produced, but not normally creating the end product or service itself. That’s not to say that the work of each group is a luxury or unimportant. Projects – even Lean and Agile ones – can easily fail without the necessary attention to the process (‘doing things right’ rather than slavishly ‘doing the right things’), budget, dependencies, acceptance criteria etc.
- Think and act independently. There can be whole teams and hierarchies of BAs and PMs on larger projects and programmes, but more often than not (especially when a ‘hybrid’ role exists) our hero or heroine is out there on their own.
So far, so good, but sometimes this apparent good fit may cause problems with conflicts of interest and a doubling of the workload. Even if the PM/BA is confident and skilled in both disciplines, having two or more people working together can be a very productive partnership and provide a useful check-and-balance that can act as the conscience for the project’s overall well-being.
As always thank you for your feedback and comments or sign up for the email newsletter to hear about new posts and content.
Tony
@ITelementary
(c) 2015 Antony Lawrence CBA Ltd.
Agree with your post Tony. From experience of undertaking a BA/PM role there is a need to change hats. Also users/customers understand the PM more than the BA role so there can be pressure to jump straight to the PM work. I know some people have strong views that the roles should be separate but I think they work quite well as a joint role. Especially where you are a small team, everyone can bounce ideas off each other.
Thanks for your comments Gill. As with most things, I suppose it depends on the attitudes of the people involved and the context. True about BA role not being very well understood. Did you read my post, ‘I am a Business Analyst’? I have to constantly explain what I do, even to industry insiders…and I haven’t really got an ‘elevator pitch’ that doesn’t confuse people more or send them to sleep 😉