Join Doug Rose for an in-depth discussion in this video Review a typical project, part of Delivering in Data Science Sprints.
- According to the Project Management Institute, there are over 16 million project managers in the world. That's a lot of project managers. By comparison, the research firm IDC estimates that there are over 18 million software developers. That means that's there's almost one project manager for every software developer. If you are a software developer that shouldn't be much of a surprise. Long time developers usually speak fluent project management. You might ask about the software requirements, or scope creep. You probably know a little bit about Gantt charts and other project management plans.
Many developers have internalized project management. They think about requirements, scope, and schedule as being part of software development. This is true even though development can happen in many different ways. There's a natural tendency for these developers to follow sound project management practices. That can be a pretty big challenge for your data science team. If members of your team come from a project management background, then they might try to apply these practices. The problem is that data science teams don't work like typical projects.
Remember that these teams are exploratory. That's the science in data science. Let's think about a typical project. Imagine that you're running shoe website needs a new server. The first thing that a project manager will do is create a project charter. This is usually a quick one page memo that says what the project will accomplish. Something like, "this project is to set up a new dedicated server for the running shoe website". If the charter is approved by the sponsor then the project manager will create a project plan.
This plan will document the project's scope, cost, and schedule. In this case the scope of the project is purchasing a new server. The project will end when the server arrives. The scope, cost, and schedule are all balanced constraints. If you change the scope, then the cost and schedule will change. If you decide to overnight the server, then the cost will go up and the schedule will shorten. The scope, cost, and schedule are all balanced in this iron triangle. So what does this have to do with data science teams? The short answer is, nothing.
Good project management has different goals and processes than data science. Yet that doesn't mean that it will be absent from data science. There's a good chance that someone will drive your data science team to use these project management principles. Many organizations are so used to project management, that it's hard to imagine spending money without the familiar scope, cost, and schedule. Project management is the tool that they're used to using. I once worked for an organization that was deeply invested in project management.
The project management office was one of the most powerful groups. Some of the stakeholders would ask, what's the scope of your data science project. The team never had a good answer. They were trying to create new knowledge and find insights that never left anyone who asked this question very satisfied. They would also ask when the team is scheduled to deliver these insights. Again the team didn't really have an answer. They were still looking through the data, it wasn't feasible to set a date on when they would find the most valuable insights. If you're working on a data science team, you'll almost certainly run into questions like these.
If it's just a few project managers, then it probably won't be too much of a challenge. If the person who's sponsoring your project is asking these questions, then you might have a real issue. The best thing you can do is to try and communicate the difference between project management and data science. At the very least, make sure that everyone on your data science team understands the distinction. Try to stay away from project management language like scope, cost, and schedule. Then over time, you might get your audience to adapt to this different mindset.
This course shows how to structure your work within a two-week sprint. See how to work within a data science life cycle (DSLC)—a methodology for cycling through questions, research, and reporting every two weeks. Explore key practices to help your team break down the work so it fits within a two-week sprint. Learn how to use tools like question boards to encourage discussion and find essential questions. And most importantly, learn how to grow your team's shared knowledge and avoid common pitfalls.
- Defining data science success
- Determining project challenges and criteria for success
- Using a DSLC
- Iterating through DSLC sprints
- Creating a question board
- Breaking down your work
- Adding to organizational knowledge
- Avoiding pitfalls