Why did my Project Slip by 6 Months?
It was September 2015 and I quit my job. No more long, boring meetings, no more hundreds of unnecessary forms, no more uncreative tasks and idiot company policies. The brain-degrading period was over, it was a big relief. I could spend as much time of the daily 24 hours on my project as I wanted. It was an amazing feeling.
After I quit my job the fact making a “product” from Bookmark Ninja became even more real, so I decided to make some schedule for my project. First I was focusing on creating a development schedule. Since I’m the only developer who works on the project I didn’t want to make the schedule planning too complicated, I didn’t want to use any advanced project planning tool, I used a simple Excel document. It had a product backlog with the features I planned to implement and it also had a sheet with the tasks assigned to the weeks. I used kind of an agile approach with weekly sprints. I started to create this plan as a development schedule then I realized I had to add some non-development related tasks as well (like setting up the IT infrastructure, writing documentation, marketing tasks etc.) in order to get a better picture of the whole “project schedule” not just the development schedule. (I plan to write a post about completing the development/coding vs completing the product — there’s a big difference between the two…)
Based on the first schedule I created the launch date was in April 2016 and I planned with a 3 month Beta starting in January 2016. But I couldn’t make this schedule, the schedule slipped. Then it slipped again. And again and again.
An unforeseen event you cannot plan with
In January 2016 both my mother and father got into hospital. After 2 weeks being in the hospital my mother died. My father couldn’t recover fully and he was diagnosed suffering from dementia. He had to be taken to a nursing home, because he couldn’t look after himself anymore, he needed care. And he’s been there since then.
This was too much at once… I got depressed. Literally I couldn’t work for 6 weeks. And I can’t say enough how thankful I am to my wife, Lilla, who had been beside me during these weeks and supported me. This unfortunate event added 6 weeks to the schedule slip.
Even if you carefully plan the architecture of your application it might happen that you realize that you screwed up something only after you finished the implementation, coding. This happened to me when I designed and coded the Dashboard of Bookmark Ninja. After finishing the coding of this part of the app I realized that the way I implemented it completely sucked… From the user point of view it worked fine, but I misunderstood the specification of the PrimeFaces control I used (it was my fault, they provide very detailed, cool documentation) and I implemented it in a very nasty way, which I didn’t like. I decided to rewrite the whole Dashboard. This refactoring added 2 weeks to the schedule slip.
A good piece of advice for developers (I read it many times) not to deal with trying to fix possible performance issues until you finished the development and have a working application. It’s true that during designing the architecture of the app you have to consider performance optimizations as well, but you can run performance tests only on a running code. And when you have the results of the performance tests then you can start fine tuning the system.
I ran the performance tests and it turned out that the database operations were not well optimized in some cases. It might not have been necessary to make the improvement at that time, because it probably would have caused performance issues only in case of really high number of concurrent users, but one day it would have been inevitable to fix it. This performance tuning finally added 2 weeks to the schedule slip.
My idea was not to build any native app for smartphones (iOS, Android, Windows Phone) but have a dedicated mobile UI experience in the browser when you launch Ninja in a mobile browser. It’s good because you don’t have to bother with the native mobile apps on the different platforms, and since my app is a bookmark manager, it’s absolutely obvious that users want to open the saved links in the mobile browser.
An obvious choice would have been the responsive UI, one UI code that works both in desktop and mobile browsers. But I have never seen a good implementation of responsive UI. Usually neither the desktop and nor the mobile UI is perfect and also the maintenance of the code is a big pain. I decided to implement a dedicated UI for the desktop and another separate, dedicated UI for the mobile that looks like a native mobile app. Of course the mobile UI is kind of responsive in terms of the different mobile screen sizes.
I knew that the implementation of the dedicated mobile UI would be a big work in the way I imagined. Since I wanted to release Ninja as soon as possible, I decided that the first release would not include the mobile support, it would be a desktop only version. Then I would add the mobile support some months later — I thought. As time passed I started to feel that this was a bad decision… If you launch a web app that doesn’t have a mobile support in 2016 then you immediately lost (for example in 2016 over half of Facebook users accessed the service only on mobile). So finally I decided to add the mobile support in the first release. The implementation of the dedicated mobile UI and the development of the “add bookmark” feature on mobile (the method that works in desktop browser doesn’t work in mobile browser) added 6 weeks to the schedule slip.
The importance of videos
I created as much documentation as possible that help users to get familiar with Ninja. High level description of the main features on the Home page, step by step instructions during the sign up process, detailed User Guide, FAQ. But something was wrong. Based on the statistics new visitors didn’t stay on the Bookmark Ninja website, they left it pretty quickly. Also I was not satisfied with the number of signups. It took some weeks to figure out what the problem was. People, especially the younger generation, prefer watching videos to reading long text. The problem was the lack of the videos on the Ninja website.
Then we decided to create 2 videos. An animated, explainer video, that explains what Bookmark Ninja is good for. This video is for people who are not familiar with the bookmark managers. The other video is a feature demo video, that demonstrates the main features of Ninja. My wife helped me a lot, she created the explainer video and I created the demo video. We are not professional video makers, we had to learn a lot of things. It took a total of 8 weeks to create the 2 videos (it’s true neither of us worked full time on it, my wife has a full time job, and I was developing improvements for Ninja at the same time).
Every effort we put in creating these 2 videos was worth it. After we added the videos to the Home page, the visitor statistics improved, and the number of signups increased. Creating the 2 videos added 8 weeks to the schedule slip.
The lessons learned
Finally Ninja went into production in October 2016 (the original date was April 2016) That was a 6 month slip in the schedule. So instead of the originally planned 7 months it required 13 months to finish implementing the features and make a product from Ninja.
And here are the lessons I learned about creating a web app project schedule:
- Allocate time for possible architectural changes even if you planned the architecture carefully
- Allocate time for performance tuning
- Mobile support of any web app has to be available at launch time (either a native mobile app or mobile compatible web UI)
- Allocate time for making at least 2 videos (explainer video, demo video)