FedEx Day - A Surprise Result
At Mashey, we are huge fans of Atlassian. We use Jira for project planning, roadmapping, backlog and sprint management. We tie into Confluence for technical documentation and release notes, and even for our internal wiki. In our early days we used Trello for organizing projects and tasks, and for collaboration with customers. Now that Atlassian acquired Trello, turns out we have been in the Atlassian family in some shape or form all along!
About a year ago I read Drive by Daniel Pink and was deeply intrigued by the topic of FedEx Days (now called ShipIt) which, ironically, were invented by Atlassian. I found the concept perfect for Mashey. These short bursts of autonomy were something of a perfect medium between Google’s 20 percent time and companies that say they are invested in personal development, growth and fun, but don’t actually do anything to support their teams in that.
Introducing FedEx Day was a big moment for us. We are all creative problem solvers which works very well for building and delivering our Nirvanalytics Solutions, but it’s always within the constraints of customer needs. This was our chance to finally break free of shackles of customer requirements and build stuff for ourselves, because we thought it was cool and not because it had an economic return.
Following is a synopsis on one FedEx Day project that was carried out with myself and our VP of Customer Success, Jason Nelson. What we walked away with was very different from what we set out to build. It was almost like we were going apple picking and we ended up on a charter boat in Brazil fly fishing for peacock bass and also picked up some apples.
The Problem Manage a consulting engagement sucks.
Buyers often don’t know how to judge value in a project until it is finished. They don’t know what people are working on for the project, when, or how they are performing compared to budgets. In a desperate attempt to manage the spend, they request annoyingly detailed invoices which they then copy/paste into Excel for further dissecting. Then they dig through their email to find the contracts or a Statement of Work that has the budget outlined, but can’t find it for some reason because it’s been archived due to Mr. IT’s arbitrary email inbox limitation of 2GB since “email is not for storage”. It’s a mess.
Consultants deliver everything as promised, including the greatest documentation ever because they Made Documentation Great Again. But the documentation is in a PowerPoint from the training and handoff session, or in a Word document they sent to the customer “a while ago”. Consultants like doing what they do best - building solutions - not the mundane tasks associated with organizing and structuring their project and making sure the customer has everything they need in a clear and concise way. No one’s happy.
The Solution Build a way to see everything that's happening with your professional service providers. Specifically your analytics partner, which is hopefully Mashey. (Contact us here to join the Mashey family.)
This new approach to information dissemination should center on 3 principles - easy, productive, and organized. It should be easy to get the info you’re looking for - searchable for everything from a phrase in documentation to a video call transcript. It should be productive for the people using it. They should be able to get their answers 10-20x faster. It should be organized in a way that you have everything you need, nothing you don’t, and a few things you hadn’t thought of.
Features should include - Ability to search, everything - Access to Project Plan, schedule, and key contacts - Live traceability of current pace to budget - Open book on time sheets to allow anyone to see who’s working on what and when, up to the current time - Access to all key documents and agreements, from Master Service Agreements and Statements of Work to code repositories and documentation - Ability to chat with Mashey at any time to request a change or to request help
While our pie in the sky dream was a full-on software product with multiple integration points, the scope of the FedEx Day was limited to just the key analytics components. - Budget Tracking - Project Management Activity - Benchmark Measurements - Invoice Details
What We Walked Away With Defining what to build, organizing our thoughts, designing our outputs and making it production ready was just like a mini customer project. Our ability to work the way we knew would yield the best results was subtly different from how we’ve worked in the past, and different from how customers expect us to work. And the results were awesome!
To demonstrate this, we will go a couple layers deep into the scoping phase of this project.
Question 1: What do we want to measure? Why?
Here’s our first swing at the list 1. Invoice Tracking - invoices sent over time and current statuses 2. Budget Tracking - current budget breakdown and actual versus budget 3. Time Entries - full detail on time entries from our time tracking system (Harvest) 4. Project Management - details on how much time is spent on project management and if it’s enough for the project at hand 5. Billable Ratio - How much work is done that is billable to a project versus written off (mostly for internal Mashey use) 6. Contracts & Agreements - easy access to key documents like agreements and tax forms 7. Travel Expenses - breakdown of project travel spend 8. Cost Management Scenario Builder - what-if scenario builder for increasing, decreasing, or changing the mix of capacity, expertise and delivery speed
The benefit of this step is that we were able to think about what Mashey needs, what our customer might care about, and what we are trying to accomplish by providing that information.
Question 2: What’s critical for delivery and what’s the order of priority?
We learned that the order in which we thought of the ideas was basically the same order as what seemed most important. This is a natural and common phenomenon - humans have a great ability to think most about the thing that is their biggest issue. We want this solution to solve the biggest issues so that worked out well.
We determined that #1-#6 were all pretty important so those made it in the Minimum Viable Product (MVP). Since #7 was so simple, it also made it in since it would be super easy to solve and would provide a lot of value. The rest could wait.
Question 3: [For each topic] What questions do we want to answer?
We will drill into Topic #2 Budget Tracking for this example. We determined our questions to answer were: 1. What’s my remaining budget? What’s my Total budget? 2. What have I spent my budget on so far? 3. What hasn’t been invoiced that impacts my budget? 4. What options do I have for budget management? 5. Where is my current agreement paperwork?
Question 4: What is the order of priority of the questions?
Again, these landed on the whiteboard in more or less the same order as the priority, though this didn’t happen for every topic. And we scratched off one that wasn’t feasible right now. Our list ended up as 1. What’s my remaining budget? What’s my Total budget? 2. What have I spent my budget on so far? 3. What hasn’t been invoiced that impacts my budget? 4. Where is my current agreement paperwork?
*Question 5: How should the question be answered? * This comes down to the visualization of numbers, the data. No need to go into detail here since the topic is widely covered elsewhere. You can find a good consolidation of this information and some useful links here.
Question 6: Is there anything, techncially or politically, that would prevent us from accomplishing this build?
We identified a few things that needed attention to make this really work in a clean way. - Update and consolidate a customer description - Remove projects and customers that were not in use - Add a way to link invoices to projects
To scope and organize at this most important level, all you need is a white board, a marker, an eraser, a camera and a few beers. Sticking with the example, here is the high fidelity mockup of the Budget Tracking component.
Let’s check out this masterpiece for a moment.
Dashboard/Topic List - The right side has a ranked priority list of the topics we needed to cover. It’s out of the way yet always visible. When this shot was taken, we had completed the first topic, checked it off, and we moved down the line in order of priority. We knew we are focusing on the next most important topic (Budget Tracking) and that we were only on topic 2 of 9. In case we ran out of time, at least we knew we focused on the most important things first and not the most exciting or easiest parts. Action Items List - The top left side shows a list of things we identified that we need to go back and change in our systems or processes to make the product spec work as intended. Again, always visible but out of the way. Questions - In order to mockup the dashboard, we needed to first identify what questions we were planning to answer. These questions were shouted out at random, and like the topic ranking, we also ranked our questions in order of importance and scratched off things that didn’t end up making sense. Dashboard Mockup - This is the centerpiece. We also know what questions we wanted to answer about Budget Tracking and in what order. This helped us wireframe the dashboard so the most important question was answered in the top left, and it read like a book. The second and third most important questions were answered to the right of the first, then on to the next row. Just like reading a book. This is a general best practice for dashboard content organization. All the upfront work allowed the dashboard design step to be super easy. It was kind of like preparing a room before painting it. If you prepare the room well, the painting part is the fastest and easiest part!
So, we set out to collect apples but we ended up in Brazil fly fishing and eating apples. Did you see it?
We wanted to build an analytics hub for monitoring and managing Data Analytics Programs, but what we ended up building was a repeatable and scalable framework for data analytics requirements gathering and specification. Here it is:
- Topic Creation. Determine what to measure and why. Rank the topics.
- Prioritize Topics. Define what is critical. Split into (1)Must have, (2) Need to have, and (3) Nice to have.
- Questions List. Outline specific questions to answer. The more specific the better. Success will ultimately depend on asking the right questions.
- Prioritize Questions. Rank and prioritize questions to answer within the topic.
- Data Visualization. Determine how you want to display the answer. Stick to best practices.
- Identify Blockers. Identify any potential risks, blockers, or changes that need to be made to make it all happen.
FedEx Day was engaging, exhausting, and never boring. This experience was great for our team building and for scratching the creative itch we all have.
In this case, we wanted to build the start of a product, a Mashey Hub, and ended up with a killer process that we have reused with clients since then and delivered consistently great results. No, we have not forgotten about the hub. In fact it has grown from idea to product with the alpha version available next month. If you’d like to schedule a demo or be a part of the beta program, please let us know!
We intend to keep the FedEx Day concept alive by doing these several times a year. We would all be excited to see great product features or market offerings come out of the events. An even better outcome would be continuing to connect better with people we don’t normally work with and creating things we’ve always wanted to create but never have the time to build.
Try it! You’ll like it!