There is a common belief among most project managers that digital analytics projects are difficult to manage. Digital Analytics project management differs from most other field’s project management in that a digital analytics implementations and reports are never really a completed project.
Every phase of a digital analytics project has a start date and an end date, but the requirements and updates will never go to an end state. Roles and responsibilities assigned in a traditional way seem to result in too much rework, and the traditional waterfall methodology does not seem to work for controlling the project.
Digital analytics projects are ever changing and dynamic. These characteristics make project management for digital analytics challenging and unique; they are also a key reason why agile methods are appropriate.
The idea of a traditional digital analytics project management is pretty much the same as the Waterfall methodology for software development:
- Gather Business Requirements from our stakeholders to define the KPI, metrics and dimension.
- Start tagging the website and collecting the required information.
- Build reports and do some analysis using those metrics and dimensions. In order, to improve our KPIs. In other words, dive in the depth of an ocean of data to find the rare gem and email or present it with the report as an insight in order to drive actions.
“The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.” ~ Wikipedia
Here is what a digital analytics project looks like in a “Gantt chart”:
This model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily identifiable milestones in the digital analytics process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses.
This traditional model can be suited to projects where business and marketing analytics requirements are fixed and the technology is clearly understood.
1. Agile Software Development
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in 2001 when the Agile Manifesto was formulated.
Different types of agile management methodologies can be employed such as Extreme Programming, Feature Driven Development, and Scrum.
Any software method is considered agile as long as it adheres to the four principles of the Agile Manifesto, which values:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
For this particular case study, we have used Scrum, an iterative incremental framework. We used 7-days iterations and emphasized close working relationships between the business and the project team.
Agile methods break an entire project into small increments that vary from a week to six weeks.
These short timeframes are termed as iterations or sprints that have minimal planning and do not directly involve any long- term planning.
Each iteration is completed by a team through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing, when a working product is demonstrated to stakeholders.
An iteration may not have enough functionality to make a full release of the product or project, but the goal is to have a release at the end of each iteration.
Multiple iterations may be necessary to release a product, to add a feature, or to complete an entire project.
In Scrum, this concept is referred to as delivering something that is “potentially shippable,” meaning it is a finished product that if need be could be delivered to the customer as is even if all the features/functionalities are not built into the particular version. In concept, it is solid enough by itself to either be shipped or to have additional code built on top of it without breaking what has already been built.
2. Agile Team Structure
Within the Scrum Framework, three roles are defined:
- The Scrum Team
- Scrum Master
- Scrum Product Owner
Each of these roles has a defined set of responsibilities and only if they fulfill these responsibilities, closely interact and work together they can finish a project successfully.
The Scrum Team
Within the Scrum Framework all work delivered to the customer is done by dedicated Scrum Teams. A Scrum Team is a collection of individuals working together to deliver the requested and committed product increments.
To work effectively it is important for a Scrum Team that everyone within the team
- follows a common goal
- adheres the same norms and rules
- shows respect to each other
When setting up a new Scrum Team one always has to keep in mind that no new team will deliver with the highest possible performance right from the start. After setting up the team, it has to go through certain phases as described by the Tuckman-Model: Forming, Storming, Norming, Performing.
How long it takes until the Scrum Team is in the Performing Phase depends on the team, and yet it normally takes about 3 Sprints until the teams is mature enough to deliver their results in a predictable way.
Characteristics of a Scrum Team
Scrum Teams always have the following characteristics:
- Team members share the same norms and rules
- The Scrum team as a whole is accountable for the delivery
- The Scrum Team is empowered
- It is working as autonomous as it is possible
- The Scrum Team is self-organizing
- The skills within the Scrum team are balanced
- A Scrum Team is small and has no sub-teams
- The people within the Scrum Team work full time in the team
- People are collocated
Rules & Norms
Of course, the environment and organization defines some of the norms the teams have to follow, but some rules and norms are developed internally during the Norming phase. This set of common rules is quite important. Otherwise, the team members would have to constantly waste valuable time to switch between different value systems and rule sets. Examples for such norms and rules are:
- Time and location of the Daily Scrum Meeting: 3 minutes per team member to discuss yesterday accomplishment and today in progress tasks. If it’s a 6 members team, the meeting duration is 18 to 20 minutes.
- Projects and tasks description: The team can decide which description to use. In my experience I tried those two naming conventions and they work very well:
<brand> – <website> – <project-name>
<website> – <category> – <project-name>
Agile Tools
To implement an Agile culture, we will need a list of compatible Agile tools. Generally, Agile tools are known for their flexibility and ease of use.
There is a full blog post explaining An Agile Trello Workflow.
This is my prefered one. Agile teams tend to choose and customize their web analytics tools. Don’t forget, we are promoting flexibility ( over processes), in other words, there is no absolute “Agile” tool that fits every specific need.
I simply advise to choose what is right for the team.
Accountability
The Scrum Team as a whole is responsible to deliver the committed delivery in time and with the defined quality. A good result or a failure is never attributed to a single team member but always the result of the Scrum Team.
Empowerment & Self organization
The Scrum Team has to be empowered to define:
- What it will commit to deliver at the end of the sprint
- How the expected results have to be broken down into tasks?
- Who will perform the task and in which order they are performed
Only if the Scrum Team is empowered to decide these things it will work with the highest possible motivation and performance.
Balanced set of skill
Individuals within the Scrum Team will most certainly have specialized skills and focus. However, to achieve best possible performance it would be optimal to have a balanced set of skills.
To give you an overview, in our “CRM & Analytics” team, we are:
- Two CRM specialists.
- One marketing data specialist.
- One Digital Analytics specialist.
- One Marketing manager.
- One conversion Rate Optimization specialist.
Only then, the Scrum Team will be able to deal with the ever-changing challenges and can act as autonomous as it is possible.
On one hand, this means that a Scrum Team should be multidisciplinary right from the beginning. On the other hand, this also means that each team member should learn a little bit of each other’s specialization, e.g. a if required to finally reach the committed goal a digital analytics expert should also perform or write a retention strategy.
Therefore, this also means that within the Scrum Framework there is no differentiation between e.g. “analytics” and “crm”; they all share the same title “Scrum Team Member” even if the primary skill is not to define the KPIs.
Size Of The Scrum Team
Scrum Teams are small. The ideal size is 7 +/- 2 people.
If the team is larger the communication overhead gets too large and the team should be split into multiple Scrum Teams. These Scrum Teams should be coordinated and communicate with each other but otherwise work independently.
Collocation
To minimize unnecessary communication overhead each Scrum Team should be collocated. If work has to be spread over multiple locations, independent Scrum Teams should be created.
Responsibilities Of The Scrum Team
The Scrum Team and each of the team members has certain responsibilities, which have to be fulfilled:
- They have to breakdown the requirements, create task, estimate and distribute them. In other words, this means that they have to create and manage the Sprint Backlog.
- They have to perform the short Daily Sprint Meeting.
- They have to ensure that at the end of the Sprint potentially shippable functionality and previous week commitment is delivered.
- They have to update the status and the remaining efforts for their tasks to allow creation of the next sprint objective and commitment.
1. Join The Data-driven Revolution
It is never too late to join the revolution. As Digital Analytics experts, we were the essence of this revolution. If you remember, 10 years back, we (Ok, I was not an expert yet☺) hated that “HiPPO’s” are the only decision makers in the business world. Avinash Kaushik (Digital Analytics Leader) expressed an urgent need for a Data Driven Culture.
Luckily, today, we are right into this revolution, we are working in digitally democratized and transformed businesses. Digital analytics projects exist to accomplish multiple goals for multiple divisions and levels of the organization with continuous insights and recommendations. Today, everyone is a data-driven and decision maker.
I know this could be really demanding. Now we are the source of every piece of new information to collect or analyse. You are not a report generator or datamonkey anymore. You cannot continue doing so. So, better to be Agile and prepare yourself for this.
Now imagine you did not prepare yourself for this. With the following Waterfall methodology, will you be able to fulfill all the requirements for all those departments?
Of course not.
With this spreadsheet or any look alike plan, it will take you 10 weeks to start working on another single project.
On the other hand you could be using a Kanban setup instead. When you receive a project, you can add it to the backlog column. Right away, its tasks are candidates for the next week’s sprint.
What is better than meeting every week to Inspect, adapt your priorities, and share the progress with your stakeholders?
2. Better Management And Governance
Digital Analytics governance is the art of managing the business requirements and their changes over time. In this data-driven era, every department and employee have a different requirement and they are always changing. We get a lot of new types of analysis.
By meeting every week and every single day, we are well prepared and flexible to manage all the requirements changes in time. By addressing the appropriate changes to our next sprint.
“Responding to change over following a plan”
–from the Agile Manifesto
Sometimes you are requested to do the same “shopping cart analysis” for different departments.
In a Waterfall methodology there is no way to serve two different projects or departments in the same week. You only can start a different project if you walked down the ladder and completed the previous one.
What a waste of time.
But when you are an agile team you can easily manage the two projects in the same sprint and benefit from the luxury of doing two similar analyses in the same time. When it’s time to deliver, In the same room, you can invite both stakeholders to provide your insights and recommendations for better collaboration and benefits.
3. Collaboration Over Silos
In the traditional setup the team bears the full burden of ensuring timelines are met, complete scope is delivered, budgets are managed, and quality is ensured.
Agile acknowledges that there is a broader community involved that share the responsibility for project success. This community includes the business owners, marketers, product owners, executive sponsors, technical experts, project managers, and others.
Frequent collaboration between the communities is critical to success. Daily collaboration within the digital analytics team is also critical. In fact, establishing a collaborative team workspace is an essential ingredient of successful Agile projects.
Thanks to the flexibility of your Kanban, meetings are more of value and exiting if you can make changes quickly and collaborate in a weekly or daily base. What is better than providing value and flexibility to make people collaborate and forget the traditional departments silo’s?
“Customer collaboration over contract negotiation”
–from the Agile Manifesto
4. Fail Fast And Adapt
Today, every expert is a data-driven tester. Which is awesome. But it has a side effect. Websites are always testing changing designs, text, conversion paths. and other elements. Which make collecting and comparing data a very challenging task.
Examples of common practices:
- You feel happy; you have tagged all your form submission clicks. After two months, you run your monthly submissions report but something unexpected is happening. There are many zeroes showing up in your report and it does not make sense; we had tons of visitors that month.
After hours of investigation, you go to the form page — boom, the form is not the same anymore. It is a new form with different design and different fields.
- Your business starts a new-targeted microsite to acquire new users. Of course, this will open another digital analytics tagging, reporting and analysis project. After just two weeks, you and the marketing team find it’s nor performing at all; it was not successful and put on hold. Instead you’re moving to test affiliates traffic to acquire new visitors.
How to deal with this? How to make sure that we are having all our reports setup correctly? How to collaborate with every person who is using data?
Well, I think you already see the solution coming from Agile.
Because our projects will continue to fail. We should accept failure as an option and try to fail as fast as possible to move forward.
Fail fast in Scrum is a strategy to try something, get fast feedback, and then rapidly inspect and adapt or terminate before more money is spent.
Some myths and misconceptions seem to prevail among other Digital Analytics practitioners and experts that I have talked to about this agile style. Some misunderstanding of agile development made it evident that myths and misconceptions abound even among the most senior practitioners.
Agile Analytics is not:
1. A wholesale replacement of traditional practices
I am not suggesting that everything we have learned and practiced in the history of the digital analytics is wrong. We were not living in hell, guys & gals, we are just moving forward. You always can build “Business Requirement Documents” and “Implementation/Tracking Guides” for every single new project.
The important part is you will need more flexibility when it comes to defining or gathering the requirements, updating the tags, making new analysis and reports. In other words, your documents can be updated at any time. Even when you are already in the implementation phase.
Why? Because there are no phases, only iterations and flexible projects.
2. An excuse for ad hoc behavior
Some have mistaken the tenets of agile development for abandonment of rigor, quality, or structure. In other words, “hacking.” This misperception could not be farther from the truth. Agile is to focus on frequently delivering high quality and high-value. This means that testing and data quality assurance are critical components of all projects. They are added as tasks and allocated the full attention needed.
Iterating and moving fast is Agile, but never with the price of your work quality.
Hand-Picked Related Articles:
* Adapted lead image: 
Public Domain, pixabay.com via getstencil.com
Comments are closed.