What do Data Analysts think about working with Project Managers for BI projects? What makes a good manager and what are some signs of a poor Project Manager?
These are our top three characteristics. And notice they have more to do with philosophy than skills like who can build the longest Gantt Chart.
- Vision,
- Project understanding
- Realistic expectations
- Having a sense of solidarity with the team, win together, perform together, not be somebody who would throw the team under the bus
- Having an understanding of the application is very important. If possible, the project should be trained as any other user of the application, and be able to experience it as a user would. We’ve worked with teams where the PM had no understanding about the application and it made them unable to set realistic expectations. Over time, this became a major liability and cost them the trust of the team.
- Agile is a well-known standard in any IT environment. It’s becoming socially unacceptable for BI project managers to not know Agile. A good PM focuses on the work and how to get it done, doesn’t pressure team members to do the impossible, takes the time to listen and understand what you’re telling them, helps to remove obstacles, stands up for the truth, and doesn’t make tasks “57% complete”.
In one case I had a BI PM, in the finance vertical, who was extremely helpful. He was very savvy, understood the politics in large corporations and really lead the project to a successful outcome (and around several challenges). I’ve also worked with PMs with software development backgrounds who pushed antiquated waterfall approaches in BI and this had a really negative impact on the team. The PM, in this case, was respected and influential with leadership – but was not democratic with the team, and led everyone in the wrong direction. Given his influence, we went down the wrong path even faster and further before we could recover (which included switching out the PM).
- It’s not important for the PM to have extensive technical knowledge. They’re responsible for delivering good work on the proper timeline, not the tech.
- Teams of analysts expect the requirements to be laid out, and any reference info that you can find attached to the requirements.
- Requirements are everything with a BI project. Having them complete and at the proper level of details is essential to success. Not hearing about a “must have” feature until late in development is what ruins schedules and frustrates work teams. Also, don’t worry about having super specific requirements docs.
- Devs don’t want to read them. Especially for dashboards, requirements should be as specific as they need to be to communicate concepts. We don’t need three paragraphs describing what a filter control does. A PowerPoint with sketches and notes is often more effective than a 50+ page requirement doc.
- Be creative with requirements. Take out your phone and snap photos of people’s whiteboards with critical requirements on them. Some people are more verbal, some are more visual. If a client just drew you something for an hour, you’d better take a photo of it and share it with us, don’t try to document it in words. You’ll get it wrong.
- Finally, resourcefulness and attention to detail are also appreciated. If the PM does not know where something is, they can at least include a link to a contact who might know.
- Good PMs don’t make the analysts stand around waiting for more work. Have a handful of tickets ready to go, because while you’re busy in other all-day meetings the team will be idle, waiting for more assignments.
- A good BI PM always assigns out a reasonable amount of work, just enough to keep people busy plus a little bit more. This makes maximum use of people’s time and avoids analyst time being wasted resulting in more work done in less time and far fewer nights- and weekends-worked at the end.
- Analysts and Devs, myself included, can be dramatic. Expect it. Don’t get offended. But if you treat us well and make our lives easier by setting us up well we will move mountains for you.
