When ActiveCollab was starting out, I wore a lot of hats. My areas of responsibility were backend development, customer support, blogging, community moderation, and many other smaller activities. With such a hands-on approach, it was hard to let go of some of these things and let others do them instead. But it had to happen, because it became obvious that my most impactful work no longer took place in the trenches (even though I still love the trenches).
First step: surround yourself with great people you enjoy working with. How to find such people, direct them (and, even better agree on a direction) and keep them, is a massive topic that we’ll get into in a series of blog posts later this year. For now, let`s just assume that you managed to find them and that they turned up for work next day. Can you really let go, get out of their way, and leave them to do their best work?
In areas such as development, marketing, and customer care, I found a method that worked really well: answer-oriented reports that are quick to compile. They can be set up in ActiveCollab as recurring tasks; colleagues prepare them, and send them over to my partner and me. Apart from that, I’m mostly hands off and intervene only when I get asked for help, or notice something strange.
Answers rather than raw data
Nobody ever told me that a report can be anything other than a massive pile of data that you’re expected to draw conclusions from by yourself. I always pictured reports as huge spreadsheets, full of data points and charts, formulas and rainbow colors everywhere. The fact that I’ve never worked for an organization that was heavy on reporting helped this Hollywood-style image stick in my head for years.
Instead of raw data, reports should be focused on conclusions and opinions.
While some of the reports that I get really are spreadsheets with charts, formulas and rainbow colors, the ones I like best are the simple documents that mix data points with bullet lists and paragraphs of text that offer conclusions, opinions and suggestions.
In such reports, the focus is shifted away from raw data, toward what we get out of the raw data. I hate when someone just sends me a link to an article, or an Excel file, and expects me to divert from what I was doing to focus on something else, and then draw my own conclusions. Why does that very same work need to be done twice – first by the person who read it through and thought it might be of interest to me, and then again by yours truly? When a new colleague does that (old ones know me better than that), they get a simple reply: “And?” or “What am I looking at here?”, but only if I’m in a good mood.
I love when people send me key data points alongside their own conclusions and opinions…and the raw data that led them there is attached as an extra file (that I may, or may not, open for further study). The same goes for articles that cover the topic, or formulas used for calculations. They’re great additions to the report, but it shouldn’t be necessary for me to read or need them to get to the answers that report’s trying to communicate.
Design answer-oriented reports
In order to get a report that doesn’t focus solely on data, but captures the result of data analysis in a simple-to-digest form, you need to build it around anticipated, possible answers, not the data itself. Here are some techniques I used when I was designing a recent report:
Which questions do I want to have answered by this report?
Reports should give you answers, not mystify you and force you to figure out what the data’s all about. In order to get to these answers, start with questions - the crucial questions that can be answered by studying data that your systems and people are collecting, like: “How engaging was the content that we published this month?” or “What was the team’s velocity during this sprint?” or “What’s the churn rate during the month, and what are the main churn causes?”
Reports should give you answers, not leave you even more puzzled then you were before.
Structure things in such a way that you get the data (“Churn rate during May was 2.5%, with 15 accounts, with $1500 MRR lost”) but so that you also get opinions and conclusions from your colleagues (“Upon studying the data, we found that main cause of churn remains X, yet we noticed that people are also stating Y as a reason why they closed their accounts. Our suggestion for how to approach this problem is to do Z.”).
How often do I need to check a report?
Some reports should be checked weekly, some monthly, some quarterly, and some are yearly retrospectives. Start with the least frequent option that you feel comfortable with. Later on, you can experiment with more, or less frequent, reporting cycles to see what works best for you and your team.
Am I the only person who can prepare this report, or can I delegate it to someone else?
The answer should always be that you can delegate it to someone else. If not, reshuffle things so that someone prepares the report for you.
How long will it take for this report to be completed?
Some reports take more time than others, but I always try to shoot for a report to be completed in under 30 minutes. If your colleague needs a day or two to prepare a report for you, it’s pulling them from their actual work way too much. Answers and conclusions are what’s important, so focus on that. Also, consider as much automation for data collecting and number crunching as possible. There are some great tools out there that can help your with report automation.
For example, you can use tools like Zapier to listen to particular events from all sorts of apps and record these events as line items in Google Docs spreadsheets. Then you can pull the important data points from that spreadsheet, instead of going to different tools and compiling the data by yourself.
Are we exceeding A3?
Toyota used to insist that all reports fit a single A3 page. The reason was simple and practical – A3 was the largest format that could easily be faxed between Toyota employees. Apart from that physical limitation, the folks at Toyota also love brief and to-the-point reports. That’s why the A3 directive is a good rule of thumb when figuring out how much info to fit into a single report. While we don’t write or print our reports, I try to lay down the data in my head on A3 paper, and cut the report if it can’t “fit.”
Should I store the reports for later use?
The reason I love wiki as a way to publish reports is because it helps you build up your company’s knowledge base. With these reports, the conclusions presented in them, and the discussions they sparked, can help you induct new colleagues in the future and get to the “thinking behind,” so you can disseminate you got to a process, not just the process itself.
When you’re designing your new report, consider whether it’s going to be worth keeping, or if you’ll delete it once you’ve studied it. Some things can be forgotten because they hold no lasting value (like the weekly Twitter audience analysis report), but some will prove to be a valuable asset as they pile up and build your knowledge base (like development sprint, or marketing experimentation reports).
Implementing automated reporting
Now that you’ve got your list of questions that you want your team to answer on a weekly or monthly basis, it’s time get things geared up so you actually get them answered. Consult the person who’ll be preparing the report, and explain the questions and thinking behind the question. They’ll probably have comments and suggestions, and you should consider them and improve the report.
Know that it’s human nature to go with the easiest possible route, so never lose sight of your main objective (why you wanted this report in the first place) when discussing technical implementation. Don’t just discard a question because the data’s hard to collect. Figure out a way to make it easier, instead. Consider automation, adopting new products that can produce the numbers that you need. Just don’t give up at the first hurdle.
I see a report as a way to extend our processes with a mandatory reflection point on an important topic. As such, it brings value to the team preparing and presenting the report, to the company itself (as a knowledge building tool), and to you, as the business owner or manager. Take that into consideration when you decide how the report will be prepared. If it’s hard for you to take it in, it’s not going to be read (or watched). If it’s hard for team to produce it in a timely fashion, it’s going to cost you more than the value that you’ll get out of it. Avoid both traps, and go for something that’s reasonably easy to prepare, yet you know you’ll give it your full attention when it arrives in your inbox.
I see reports as a way to get insights, keep things on track and get myself out of people’s way.
You’ve noticed by now that I like wiki as a way to get reports. That’s my personal preference for some types of reports. It goes hand-in-hand with my goal to build ActiveCollab into a company that collects and nurtures our collective knowledge, instead of letting it disappear as time goes by. Some reports that I get are Google and Excel spreadsheets or PDFs attached to tasks that ActiveCollab automatically creates and assigns to the team. That works really well for reports that I don’t consider to be “knowledge building.”
You may prefer something completely different, and you should go with that. In the beginning, fancy tools are of little relevance, and you should go with something that’s convenient and easy.
When you pick the tooling, try to create one report by yourself (with assistance of the team, of course). It’s okay if there’s a lot of manual work in the beginning. By preparing a couple of reports manually, you’ll get a feel for how much work goes into them, and what the general experience is. As you get a feel for the process, try to improve on it by automating as much as possible. Depending on the tools you’ve chosen, different options are available: document templates, form builders, data aggregation tools….
If possible, keep in mind that 30-minute target. Some data points and records may already be prepared (for example, incident reports, web traffic analytics etc.) Putting these elements together, with brief conclusions, should take no more than a half hour. Elaborating on conclusions, and adding extra bits of information to present an opinion or suggest a course of action may take as much time as needed after that. That’s the magic, so don’t put a limit on it!
Now that your team knows what kind of report they’ll be preparing for you, and why, you’re ready to delegate it. Create a recurring task in ActiveCollab that assigns the report preparation to a colleague, sets the reporting frequency…and sit back and wait for the first report to roll in on the scheduled date:
You just made a big contribution to your company by thinking things through and adding a reflection process, automated reporting, and an opportunity for course adjustment. Changes like this can have a profound effect on the company given enough time, so congratulations!
Working on your business, instead of in it is something that many of us continue to struggle with. Don’t let that worry you – it’s a learning process for everyone. Follow the recipe above, and enjoy the insights you’ll get from business reports that are actually important to you.
- Waterfall project management
- Fundamentals of Agile project management
- Advantages and disadvantages of Agile project management
- Introduction to Scrum
- Extreme Programming (XP)
Other posts on Agile project management
- A practical guide to project planning
- Keeping projects on the right track
- Project manager roles and responsibilities
- When to hire a first project manager
- How to choose the right project management methodology
Posts on project management
- The Complete Guide to Managing Digital Projects
- Fundamentals of Agile Project Management
- Kanban: A Quick and Easy Guide to Kickstart Your Project