Analysts are often wonderful technical problem solvers but poor project managers. Scoping out timelines, budgeting, and managing stakeholder relationships are not among the hot new skills advertised by university data science programs (or included in responses from ChatGPT for that matter). Without effective project management, your dreams of building tools that improve efficiency and help lead to data-driven decisions will fall short.
When I first started at my current organization, there were many opportunities to make an immediate impact by automating some of our processes. One of the most common deliverables we produce is a housing market analysis, which describes how supply and demand affects local housing markets. This information would then help local government make decisions about how to prioritize resources such as investing in senior housing or homeowner repairs. At the time, these market analyses was done “by hand” in an Excel workbook: data was manually downloaded, cleaned, linked, synthesized, and visualized in a flurry of several hundred mouse clicks across dozens of spreadsheets.
These were some of the key lessons I learned from my first data project automating this process that might be helpful for early career analysts working in small organizations:1
The first steps in developing effective data tools: asking good questions and listening
When faced with the possibility of an early win like this, it was tempting to whip up a new Git repository and start automating the housing market analysis in RMarkdown. But I was quickly slowed down by a lot of unanswered questions. My hope was that RMarkdown reports would one day replace these complicated (and fragile) Excel workbooks, but I didn’t have a complete understanding yet of how the Excel workbooks were being used by the team. How was I sure that the RMarkdown reports would be able to meet those same needs, even if they did save a lot of time?
I started out meeting with each of my stakeholders (in this case the project managers who were taking the outputs from Excel and developing a clear story about the housing market, usually in a presentation) and asked questions such as:
What are your expectations of the current Excel deliverable?
How does the current format fit into your current workflow? (I.e. what do you do with the data after you get it?)
What is missing from the workbooks that would help you meet your goals?
What struck me was that in many cases their answers were different from my assumptions and also among each other. I now had a much clearer picture of what elements to include in the RMarkdown reports and had built trust with the end user that their needs were being heard early in the process.
We ended up revisiting these conversations while prototyping the RMarkdown reports and were able to agree on some of the tradeoffs that came moving away from Excel. For example, in the old format, project managers could easily copy charts from Excel to Powerpoint. With RMarkdown, project managers had less “access” to the underlying data. So I added a download functionality so project managers could still make their own charts.
Setting the limits on your project
One of the biggest challenges that emerged from these conversations was how to adapt our analysis to each of our clients’ unique housing markets. For example, one client might be a college town with a significant student population that skewed the data, or for another client simply a lack of good data on rents and vacancy in rural communities.
With each project, there was pressure (from myself as well) to make the RMarkdown reports flexible enough to account for these scenarios. But once the scope of the reports was agreed to, there was clear understanding among the team about the limits of what the report was analyzing. By bringing stakeholders into that conversation, there was better organizational understanding about what the reports could and couldn’t do.
Maintenance (technical and scope)
Analysts might be familiar with the technical maintenance you’re signing yourself up for (or future employees) every time you create new data tools. On top of changes to open source code and software updates, there might unexpected changes to data sources that affects how the analysis should be interpreted.
What is less discussed is the maintenance of the tool’s scope. Will the goals that apply to your data tool be the same one, two, or five years out? Who is in charge of reviewing those goals with the team? Scope maintenance involves periodically reassessing the objectives and requirements of your tool to ensure they still align with the organization’s needs.
Footnotes
I’m emphasizing small organization here because the roadmap to incorporating new tools into an organization could look very different for a large organization with disparate stakeholders. I had the benefit of having close relationships with the stakeholders for this project and working within a nimble organization that could adopt it quickly without too much bureaucratic headache.↩︎