Blog‎ > ‎

When to stop working on an Idea?

posted Jan 15, 2013, 1:56 PM by Evan Morrison   [ updated Feb 20, 2013, 3:24 PM ]

This article has been formatted into an appealing magazine style article at https://fnord.jux.com/958725


In this world of constant change, where the next big idea is always around the corner. How do you know when is a good time to give up on your current project? This is a pertinent question that I’ve had to ask myself a great deal lately due to time constraints and repeatedly hitting my head up against a brick wall, either due to project partners or projects simply not gaining traction.

Obviously the number one way to see if an idea will work is to simply try it, talk about it and ask for feedback on it. There are a number of issues though when the idea or the project becomes too large to simply ‘do’. This is something that I’ve found to be the case recently.

Firstly, I’ll give an example of a project that it was very easy to make a decision on. A number of years ago I began working on a project that was very innovative at the time. The group who worked on it all received positive feedback on it; however, ultimately all went separate ways and the resulting product sat on the shelf due to at the time non-scalable technology and a lack of customers. Recently I was been encouraged to re-ignite the project with new team members and to take the product to market. This project was simply to remain a side project until progress by other team members had made it viable to inject more energy into. I explained to everyone involved in the project that I did not have a great deal of time to contribute to the project and my litmus test for me to become a driving contributor that aspects of the marketing plan and a least one potential customer had been found. This was accepted at the time as all other team members were gaining access to market the original shelved prototype.

After a number of meetings the first team member dropped out. Following this, I was asked to fill the gap that the departed team member left. I was able to do small amounts but due to my own time constraints and lowering optimism for the project quickly resigned to my original contributions to the project in the hope that my other new team member would produce more on his end and hopefully lead the project to success. At this point, the other team member has attempted to contribute, but has not contributed anything new to the project, and as a result it appears that the project will die a horrible second death. If I had not included the contribution litmus test when I began the project, there is a high chance that I would have been metaphorically sucked into the jet engine of disaster.

Rule 1: Always have a litmus test to help you assess the situation

The next project I will describe suffered another form of failure, resource and planning failures. Two years ago I was approached by a good friend and given a conceptual idea to work on. It was a great idea and an idea that I believed could be taken to market relatively simply so I agreed to come on board. We plotted out a road map and then began working. The issue that arose immediately was that we began to work on multiple projects at the same time. My partner was half-engaged with a second project at the same time as this project and as a result I often found myself working on both; which wasn't too bad, as I think both contributed to each other. The pain point was that resourcing development was off. The projects budgetary constraints were quiet large and as a result my partner found himself limited to one day a fortnight for project work. Given that we were working on two separate (albeit complementary) project at the same time, together once a fortnight, when project utilities were billed on a monthly basis meant that what little budget we had was gone very quickly and as a result, ended up without project utilities and two half completed projects.

Rule 2: If time is a factor, then focus on the sole goal.  Plan your utility usage.

Over the last few years I've attempted to found a few good-will and social improvement projects, which were to be my way of giving back to the community. In these projects I always work for free and contribute a portion of the project as a charity. For the remains of the projects, I am often tasked with writing requests to the local members and engaging with various government departments to secure resourcing for other aspects of the projects. This is an important step as it helps discover how useful a project will be for a community. All communities are generally happy to receive free beneficial infrastructure, however, it not always certain as to whether the communities will use the infrastructure so a wide array of stakeholders should be interviewed. I've had a few interesting experiences through this process, firstly direct exposure to the nastiness of politics and secondly exposure to the lack of community engagement done by government and the strictness of guidelines for funding requests. In most cases I have engaged with all direct stakeholders that would be affected by particular projects and took on board feedback and suggestions. This stakeholder feedback is then included with funding requests, explaining specific community needs, generally it is because of the stakeholder inclusions that many of these applications have been rejected on the grounds of the policy for the funding. Unfortunately, I've found that the only successful government funding that I've secured, has been funding that does not include these details and simply has the support of a department employee of the agency where funding is sought.

Rule 3: When dealing with anyone who is investing with money that they don’t own, focus on benefits to the person rather than just the project. 



Comments