Project management scares many analytics consultants. Through my career I’ve seen fewer and fewer subject matter experts with project management skills. Yet, it is critical to any analytics initiative success. In this blog, I will offer some ideas and hope to start a conversation around this subject.
On a high level, there are two main project management methodologies:
- Agile / Scrum
While we will not go into each in detail, I will point out the main difference.
An agile project management method is built around collaboration across disciplines to produce an incremental release of a product. Agile uses sprints of two to six weeks at a time. The product features included in a sprint release should be defined in the sprint planning before a sprint starts.
A waterfall project management method plans the product in its entirety and the team moves from discovery, to design, to development, ending with deployment. Typically, it will be longer in time and a mid-stream change in scope or features can be very costly.
In the past have been asked to provide an implementation timeline for the complete product while the client is following a 2-week sprint agile project method. This is like asking an orange tree to produce an apple.
Understanding the project management method your team or client uses is essential. It will shape your approach and how often you and your team will touch the specific product feature. Using a scrum method with such a short sprint will increase your scope, while using a waterfall method will reduce your scope but increase the cost of any changes down-stream. Knowing this and the details of its effect will help you better manager your client expectations.
Wait, who is my client?
Well, your client is the end user. Whether that is a team member in your group, a different team within your organization, or your main contact client side.
One of my best laughs was receiving a new implementation scope of 40 hours for a client trying to redesign an entire site, and move their Adobe Analytics implementation to DTM. We invested the full 40 hours in discovery, reviewing the current SDR (Solution Design Reference) and identifying the project scope. The full project estimate was 430 hours to account for the client project management method and level of complexity.
How do I create a reasonable and realistic estimate?
How do I create a project timeline / plan?
When I am building a project estimate or plan, I follow these steps:
- List the milestones
- Create the WBS (Work Breakdown Structure)
- Estimate and Schedule the work over time
- Resource the plan
List of Milestones:
Back in 2001, while I still was in TV production, I attended Conway School of Broadcast in Canada. Throughout this training, we were taught how to man a 60+ track soundboard. This thing was overwhelming! I love the first concept our teacher provided: work with each track separately, do not think of the full board at once. That was a relief to me.
I still use that concept in many aspects of my career. When I am building an estimate or a project plan, I think about it one part at a time. Take an implementation project as an example:
- Define the scope: What business questions do you need to answer, see the requirements gathering blog
- Map that scope to variable: create the solution design
- Implement a section such as marketing tracking
- QA the implementation
- Bug squashing
- Second round of QA
- Client review and approval
- Live QA
- Bug squashing
- Second round of live QA
- Client review and approval
- Hand off
These are very high-level steps that should be taken to complete an implementation. Most implementation consultants knows this. Yet, they tend not to think this way when they try to estimate or plan an initiative.
Create the WBS:
Now that I have listed the high-level milestones, I will break each one to simple task level line items. This is called WBS, or Work Breakdown Structure, in the project management language. Then I will estimate each step.
Estimate and Schedule the work over time:
Should you use an expert opinion to estimate the work, or ask the team to estimate the tasks they will work on?
Often time I see an estimate of 60 hours to complete an implementation. But that estimate is based on an expert opinion and not on reality. This is the main cause of scope creep for many engagements I’ve seen.
I prefer the team estimate since my client deserves respect and honesty. Provide a detailed estimate/plan and I guarantee you, they will go for it, budget permitting. Clients need to see how much work is involved in producing a product, then and only then they will understand why it takes so much effort.
Remember to take into consideration project management time, and the effect of the project management method in use.
Resource the plan:
Well we are coming close :). The next step in building your plan is to add resources. Having the appropriate resource work on the specific task, and taking into consideration their availability against workload, holidays and PTO.
Very quickly you will find this step changing the delivery date. So, ensure that you do this step before you commit to a delivery date.
How about client management?
You will notice that we addressed much of the client management during the steps above. We started by collecting the client requirements, educating them, respecting them by providing a realistic estimate, and throughout the process you are obtaining their review and approval.
This is just the technical side of client management. I find it very beneficial to find a common ground and genuine interests that I share with the client. Given that we are relational beings, it goes a long way in having a conversation outside of project tasks that my client and I enjoy.
Lastly, there is no such a thing as over-communicating. Be specific, communicate as frequent as you need to inform the client.