Learning From Unfinished Projects

There has been a massive lapse in what was originally planned for these blog posts. 2020 was very interesting and it doesn’t seem that it is slowing down much now that we are nearly halfway through 2021.

It also doesn’t help that I had an entire post written that was lost to file corruption reviewing 2020, and explaining my personal experience and successes using Agile methodology. Fun stuff right?

Today I want to reflect on projects however, specifically completing projects. This is something that apparently I struggle with. My desk continuously has a pile of half completed sewing projects, and I am restlessly picking up the actual website for Button404 to work on one aspect or another without putting it into production. Most of these projects get stalled out ether because I get to a part that I don’t understand or am tired of fighting against, or I just loose focus and desire to work in that medium.

This can be problematic when this is a fairly normal pattern. Especially when trying to complete projects that other people are depending on. However, I am very proud to say that I am in the home stretch of a project that is my own at work from start to finish.

I do think that this habit of constantly not finishing projects and setting them aside while gaining more knowledge on what is needed or how to proceed better isn’t necessarily a bad thing. This is because it can also save you from wasting your time on things the client, or you will not want. Cost sunk facility in action. This is something that took me a long time to recognize and honestly something that I am still learning.

A perfect example of this is recently I took two days to put a tool together that I thought was going to be very useful, a simple calculator that takes conditions and gives the user the codes the system will need. From my standpoint this is something that I wanted when I first started my current job, so that I didn’t have to reference six different sheets/ tables or more depending on what was needed. My team was also facing the challenge of a major change to an already difficult process with one of these conditional code processes, so I thought it was a wonderful time to build something of this nature. The result was fairly simple, a few drop down boxes with a trigger event to get the conditions and then give you the codes based on the concatenated conditions. I even went so far as to add in a few simple checks and balances that I often miss. However, when presented to the team leaders the feedback was that it was too complex to use, and wouldn’t be of much help to others.

That kind of feedback… honestly it sucks. Because I was really excited and thought I had made something very simple and helpful. However further development to move the calculator into a production / user state really wasn’t going to pay out if the users had already decided that they didn’t want to use it. But it did help me understand the methodology of my team better, as well as keep my mind focused on tasks that kept me learning programmatically, while learning the new process change.

Even though that project may never be finished I still learned from it, and it was not a waste of time. But realizing that continuing to focus on that particular project would be counterproductive at this stage is important.

Stay tuned, I plan to have a post out soon with an introductory / overview of a VBA project and how to make it look like an application for users. For those of us stuck in the dinosaur days of computing.