It can help you get hired, move up in your profession, and show dedication to your chosen career path. It can be a catalyst for cohesion within a PM infrastructure or project management office (PMO). It can give everyone a common language to use. It can show your project clients that the organization is dedicated to real success because your project managers are certified and ready to succeed on the projects they are managing for them.
While this is great – and I would never stand in the way of anyone's certification aspirations... in fact I've helped hundreds follow that path already – it isn't likely how you're going to manage projects in the real world. I've been managing projects since shortly after the first PMP certification testing took place in October 1984. But in every organization I've been in and worked with PMP processes and concepts weren't the norm or of any major importance – project success and customer satisfaction has been the emphasis and that isn't likely to change. PMP is great to have, but it's like algebra... you might not actually use the knowledge very much in real life. It may get you a $20k raise or a better job elsewhere earning more... no doubt about that. But usage will likely be minimal. It's more of a paper and resume thing.
Gaining PMP certification is not likely going to change that much about how you manage projects or how your organization manages projects. It certainly hasn't for the dozens of organizations I've worked with as an employee or as clients. I've experienced this personally, and I've seen it stated elsewhere that 98% of the day-to-day project management activities don't require anything they teach in a course, as PMBOK and other frameworks often really only work best on mega projects when they are use. But when you run hundreds of small projects, all you really need are an organization, people skills, and common sense. The real skills that make or break a project manager is the emotional intelligence to know which tool to use at the right time, including a deep respect and appreciation for human behavior and group dynamics.
So, let's talk “Real World” project management and business analyst responsibilities in that real-world PM arena. Yes, some of these overlaps with the PMBOK and PMP certification requirements, but let's move beyond that and talk about what is going to be expected of business analysts in the world of day to day project management and leadership – in most organizations.
Client leadership is a key responsibility of the business analyst. The project manager will oversee the engagement, status report on it, and be the primary and central point of formal communication on the project. But from a pure daily delivery team <==> customer communication standpoint, that will likely be the business analyst. Or at least it should be - if there is a business analyst assigned to the project. And I believe you should have a business analyst proposed on every project possible as they are needed as a key customer facing resource and as a leader of the tech team on the project. There are not enough hours in the day for the project manager to completely cover these two roles and most project managers are not prepared or experienced enough technically to fully serve the role of tech team liaison. The business analyst on a tech project would be – or needs to be.
While status reporting is a key responsibility of the project manager, it will also fall under the responsibilities of the business analyst throughout most project engagements. Why? Because sometimes – in the absence of the project manager – they may act as sole lead on the project and at the very least will likely be somewhat of a co-lead throughout... though their leadership role is likely to be more informal and adhoc. Being able to create, update and lead meetings from a project status report will be one of their PM real world responsibilities.
The project manager on any engagement will lead many to most of the more formal meeting sessions like weekly status meetings, quarterly quality review meetings (if applicable), project kickoff meetings, lessons learned sessions, etc. But the business analyst is going to lead many team meetings and less formal – as needed – customer meetings to review information, customer requests, informal status updates and similar discussions. Meeting facilitation is definitely a real-world responsibility for the business analyst on the project. Know how to prepare an agenda, distribute in advance, take detailed notes and follow-up after the meeting with notes and information / results asking for feedback to ensure that all info is correct and that everyone has left meetings with the same ideas and on the same page. Anything else other than complete and common understanding for all participants can lead to re-work and missed deadlines and assignments.
The business analyst will serve as the primary liaison between the tech project team and the project manager. To say they lead the team may be a stretch... as that overall leadership will fall to the project manager. However, day to day interaction, leadership and discussion with the project team will be a primary business analyst responsibility in real world project management. The business analyst – to be effective in his role – must possess and convey the leadership type qualities that demand a project team's cooperation and respect such as honesty, integrity, follow-through and dedication to common goals and quality results.
Summary / call for input
I realize that this is just a few of the many real world and somewhat unwritten but understand responsibilities of the business analyst on any tech project engagement. These are mine from my own experiences on projects. Readers – what are your thoughts on this list and what would you add to this list from your own experiences? Please think about your own list from past projects and share with others here – let's discuss.