One month ago, I started the first public 1-month challenge. The challenge was to read and finish a book in February’s 28 days. It didn’t matter which book you choose; it didn’t matter if you read the paperback version, the Kindle/e-book version or if you listen to the Audible version. As for any good challenge, it should be the person’s choice being challenged setting their own difficulty! I could have challenged you to run 100km in one month (my personal challenge in March), but if you’re not a runner or just starting the challenge wouldn’t make sense. So once again, the challenge was about finding your personal limits and expanding them!
That being said, grab a coffee and let me tell you a little story about how I almost failed the challenge that I posted so boldly on Twitter and nominated a couple of friends to join me.
My naive mistake
It could’ve been so easy, right? Pick an interesting book that you’re motivated to read, divide the size by 28, and you know how many pages you need to read per day. In my case, I picked a non-fiction book with about 650 pages (so fairly big). Nevertheless, it’s only 25 pages per day. “That sounds pretty doable”, was my first thought. Yet, there is one big issue with putting up a plan like this. While thinking about it just now, I realized that I made a typical planning mistake I would’ve immediately pointed out when planning a new software project: Progress is never fully linear!
The fallacy of linear planning
You might have heard of this “goal achieving” strategy before: pick a goal, then divide it into smaller actionable tasks and complete them one by one until you achieved your goal. I don’t condemn the original idea – after all, breaking down large tasks makes sense in every way possible! The problems arise when you set a deadline for your goal.
Let’s digress for a moment from the Reading challenge and look at an exemplary project plan: Our client wants a new application developed. The application includes an API, a frontend, a content-management system, and a little more backend functionality (login, user-management, etc.). You break down every task until you have bite-sized tasks of one day per task – including QA (Quality Assurance)! After defining all those mini-tasks, you get a sum of 300 tasks. Thankfully, you have three developers for the project! So you assume 100 tasks per developer, divided by 22 days (average working days in one month), you get an estimate (read: “guess”) of 4.5 months until your project is finished and define the deadline together with the client.
Problem 1: Not planning with (enough) buffer
Okay, that’s an easy thing to spot in a software project, right? Something will go wrong, something unexpected will happen, and suddenly a task takes longer than the aforementioned one day. Think about it: With the plan above, you only need 1 of the 3 developers to be sick for one day and you will fail to deliver in time!
This is completely obvious and practically no one would not plan without a little time buffer. However, that was my first mistake in planning out my Reading Challenge: 0 buffer! The moment I don’t find the time to read the 25 pages in one day, it will be 50 pages the next day to finish in time.
Going back to our software project: you’re smart, so you plan (read: guess/hope) with a buffer of 20% on top. That means instead of 4.5 months, you plan (again read: “hope”) to finish the project in 5.5 months. Luckily for me and my “reading project”, I didn’t have major upsets, and I was amazingly consistent for the first 18-20 days! I’ve reached around 70% without being sick, distracted, or other reasons to skip one day. That alone is a great achievement, in my opinion…
Problem 2: Not planning with dependencies in mind
Your development team is working with a great mindset. Although there have been a few minor setbacks, with proper prioritization and a couple of hours of voluntary overtime, they were able to deliver the first few iterations of the project. The frontend already looked promising, the API returned some data from the CMS already, and you are pleased with the first 60% progress – right on schedule. But all of a sudden, your team starts to struggle! The frontend developer contacts you, saying there are no tasks left to do in the frontend until Feature X is ready. You contact the developer of “Feature X” and learn that “Dependency Y” is not yet ready.
This is a fairly common issue in software projects when you are not completely independent. What could Dependency Y be in a real-world project? It could be an API not ready for integration, an issue with the infrastructure (which is maintained by another department or company), any problem with an external module (video transcoding, advertisement, payment integration – you name it!). Everything that relies on this external dependency will get postponed, and you need to stop development on this particular feature. Thankfully, it only affects one of your three core functionalities, and your developer can work on a different topic in the meantime. You accept the problems of context switching with resignation because you know you can’t change anything and hope that Dependency Y will be fixed in time, so you can still finish in 6 months.
This is really tricky to handle! You can’t really avoid (external and internal!) dependencies, but on the other side, you need to rely on most of them to work. Tasks might depend on each other. The frontend developer needs data from the API, but the API developer needs some clarification with the client. In this case, the frontend developer is completely blocked for this feature. And these dependency chains can get extremely long when an integral part is making problems. The only thing you could do is: be aware of your dependency risks! Make sure to resolve as many risks as possible. When you know that 50% of your application relies on your login functionality, it might make sense to tackle this issue early and not at 49% progress.
That being said, a book is like a very linear and dependency-driven project. Usually, you need to complete page 20 before starting with page 21. Or, adding to the above’s thought, when you miss one day, you need to read 50 pages the next. But now, it’s even more difficult to reach the next day’s goal.
So after 3 days, the problem piles up to 75 pages. This isn’t problematic when it starts early in the month, though! Skipping the first 3 days means I need to read 75 pages more in 25 days – or 3 pages more every day. Missing the last 3 days is a different story! So the later your project, the fewer risks you should have to manage, or you might run into problems. For me this meant, reaching 70% in time but struggling during the last week made me read 70 pages per day during the final weekend.
Problem 3: Sprinting when running a marathon
It is tough to get back on track when you’re behind schedule! One strategy often used is to invest additional time during weekends or working extra hours in the evening. As my example has shown: this can work! But when you use such an extreme measure, be sure to use it carefully and know where your finish line is! When you sprint the final 200 meters of a 42K marathon, you know that you can give your 110% but think of the consequences when telling your runners at the finish line that they have to run another 2 kilometers!
Sometimes it’s a really good practice to think about how differently you would do something if it were in area X or Y. So, in the example above, I would have noticed my mistake earlier when thinking about the reading challenge in terms of a software project. Depending on the situation, the same scenario can work wonderfully comparing it to sports, business, society, etc.
I’ve made it!
In my case, I invested a few more hours during the weekend to finish the book because I was committed to finishing the book. I knew that there is a final page, and then it’s done. And yes, I finished my February challenge just in time! 🥳 But in the end: Why did I have to do it? Was my reading time too slow? Have I been too inconsistent? Have I been too lazy? I think it was mostly improper planning at the beginning that made me have to work even harder in the end. So instead, I could’ve added a 20% buffer from the very beginning. With this plan, even if I skipped 5 days completely, I would still be in time by reading 26 instead of 22 pages. To avoid further piling up of daily reading-goals, I could have moved my personal deadline to one week earlier.
I have learned my lesson and will plan my next challenge in March (running a total of 100km) with a different non-linear approach!
Conclusion
Did you finish what you committed to doing 28 days ago? Congratulations to you!
If you haven’t been able to complete the challenge, I’m sure there was a good reason. In the end, a challenge is, well, challenging! So if you easily finish every challenge, maybe you choose challenges that are too easy for you? The most important thing is that you started, and you tried your best to accomplish your goal. If you haven’t, you at least know what you can work on 😉
You can always do the challenge (again), maybe with a more, maybe with a less challenging book. It’s a really great experience to do this with friends, and you’ll always have the side-benefit of reading a great new book in just one month!
Thank you all for competing in this challenge together! I’m looking forward to doing the next challenge with you! 😎
