An analytics practice has some unique challenges as far as project management goes. They are accountable for delivering quality data, but there are many elements out of their control:
- once you deliver technical specifications, you have to “hurry up and wait” until developers have questions or are ready for validation
- documentation and validation often happen on “moving targets”, where the site map or functionality may be in flux right up until they are released
- release cycles rarely include a window of time with a stable site for the Analytics team to perform validation
- projects rarely exist in a vacuum- they usually need to meld with a global solution which is itself often a work-in-progress
- an analytics project may involve many deliverables, with many audiences:
- Site Map/wireframes
- Business Requirements for reporting
- Solution design
- Technical Specifications for IT
- TMS Engineering
- IT Implementation
- IT QA/Validation
- Report QA/Validation
- Push to production
- Distribute reports, provide insights, and take action
Without an official process or flow in place, it can be easy for things to slip through the cracks.
Because of these external variables, both Agile/SCRUM and Waterfall methodologies have some major drawbacks. You may need to be writing technical specifications before a design is complete; taking an iterative approach may be too resource-intensive; the analytics team may not be deeply embedded enough to collaborate with developers in real time. Some of these difficulties can be alleviated by improving communication within your org, as discussed in the second post in this series, but the most significant thing you can do to help streamline your initiatives is to have an established process in place, to be sure that all the necessary tasks are completed in the right order by the right people. You may not be able to always adhere to it, so plan on some flexibility, but it can be a good exercise to merely look at your process and document “this current project is an exception because [fill in reason] and we’re going to account for the deviation from our process by [fill in alternative]”.
Take this example user flow. In grey are examples of deliverables or decisions following a single sample reporting requirement (track a new form’s ID):
When visualized in this way, it may become easier to establish what kind of timelines you need when working with developers, clarify who is going to update the global documentation, or ensure that QA/validation procedures are followed. Cognetik can help set up and document these governances practices, but we’d also love to hear from you what you’ve found works well, or what struggles you’ve encountered.