Photo by Drew Graham on Unsplash

I recently had a great conversation with a CEO about making team members wear too many hats, meaning, specifically trying to have one person play multiple roles in an IT project. He highlighted to me his own experience with two company-wide projects that he oversaw over the last few years. Here’s what he shared:

  • First, there was an enterprise software project wherein the business analyst was really more comfortable as a project manager. In fact, they generally served the team as a project manager, but since they had participated in some business analysis training, they were nominated for this particular project as a BA and a project manager. Two roles in one. This person was able to schedule the meetings, keep the project plan, and collect general requirements, but he said the business left their requirements sessions feeling like they had been in an order-taking kind of environment. The project, unfortunately, did not go well because there was a lack of true insight into the business team’s true problems and needs. Now, the business analyst/project manager did the best that they could. They were simply tasked with too much, and the CEO took for granted that business analysis and project management were simple tasks. When you put too many roles on one person, their rate of success will simply not be as high.
  • Then, some time later, there was a project wherein he assigned a long-time business analyst as the dedicated analyst on a company-wide software project, with a separate project manager to help steer the ship. The BA had worked as a business-focused analyst for most of their career and was a dedicated analyst on the project. The project manager was overseeing multiple projects, but had a clear role in this one: to manage the implementation plan. It was a better experience. The CEO said that the business walked out of their requirements sessions empowered and excited. The business analyst had gotten to the true heart of their needs, and the business team was looking forward to the project outcomes. The project manager was able to do what they did best: keep the project moving forward while removing obstacles to success. The project, in the end, met its objectives.

This CEO told me he had learned some important lessons from these projects. These may seem like obvious points, but we’ve all seen them happen:

  • Don’t force multiple roles into one
  • Don’t skimp on resources when you have a critical enterprise project
  • Always try to put career-dedicated resources on critical projects

Having a dedicated business analyst, especially, added weight and validity to internal customer concerns. Having a well-versed project manager provided project structure and clear project goals. While it may seem economical for someone to be able to solicit requirements as part of their other responsibilities (such as managing the project), it’s not a replacement for true due diligence, and it is certainly not a cost savings.

Often, companies like to skimp on the BA role, perhaps to save money or time. It never ends well. If the business team is not happy, the project goes south and it is an inevitable waste of money, time, and staff resources. It’s akin to hiring a someone who professes to dabble in surgery instead of a professional surgeon: you’d never do that, right? So why settle for someone who has done a little of everything in IT and hope for the best in your project, meanwhile investing thousands of dollars?

The main difference between the PM/BA hybrid and the career-long BA, from his perspective, was that the latter really penetrated to the heart of business “needs” versus “wants” and then prioritized those needs. They also drummed up excitement about the project. The PM/BA hybrid he hired didn’t have the skillset to unbury the true business challenges. It’s true: collecting requirements is certainly a science.

According to the PMI Pulse of the Profession 2014 report on Requirements Management, “47% of unsuccessful projects fail to meet goals due to poor requirements management.” This makes sense when you look at another related PMI stat: “fewer than one in four organizations (24 percent) report doing well in recognizing and developing skills needed for effective management of requirements.” Further, the report says, “perhaps more concerning is that one out of three organizations (34 percent) is not doing very well or anything at all in the critical area of skills development specific to requirements management.” Bad news, and that was only four years ago.

As a business analyst, I am certainly organized and can coordinate a project, but I would never state that I am a dedicated project manager. I play to my strengths as an analyst. Simple moral I have learned for sure: there is a risk in trying to do too much, though that seems to have become an expectation of many companies. Ideally, the project manager will run the project and ensure the team stays on task, while the business analyst will ensure the project sees success from a business perspective. Together, this team can make the project a victory. The PMI Pulse of the Profession 2014 Report further identifies that “only 46 percent of organizations believe there is good collaboration between their project managers and business analysts, yet, 68 percent of organizations indicate this collaboration is essential for project success.”

The CEO ended his comparison with a bit of regret: if he had only known then what he knew now, he would have managed his teams differently. It’s something to consider.

Are your projects filled with hybrid roles wherein the same person is wearing too many hats? How is your company managing resources and requirements for those enterprise projects that are deemed critical for company success? Can you really afford not to have dedicated roles on your project team?