Over the lifetime of a project, a roller-coaster of emotions will be felt. What typically starts with high levels of excitement might become apprehension when it’s time to start. That apprehension may turn to dread as soon the scope of the project is realized.
For project owners/starting entrepreneurs, the excitement may lead to the addition of numerous features.
Apprehension once time has passed and that feature list looks more like a mountain every day. Dread sets in when the myth of on time, on budget, and on scope proves to be exactly that…a myth.
The question that begs to be answered is does this have to be so?
Simple Answers
The simple answer to the question above is no. While the simple answer may give stressed-out team leads to hope, it is far too simple to ease stressed minds. Indeed, the answer is no, but it involves adopting the right mindset before starting. Even adopting the right mindset will initially read like a poor answer. So, let’s break it down into a more practical list of considerations.
Build Less
At the start of the project when confidence is high, egos are running rampant and the belief that every problem the app intends to solve can be done. Not just done but surmounted with ease. With such a high level of confidence, another belief begins to emerge, “wouldn’t another feature added here be great?”. Soon the feature list looks like a grocery list that will just add pain further down the line.
Build less, resist the temptation to have more features than perceived competitors. It is better to have fewer features than operate excellently in tandem. Sure, this involves not jumping on the hype train and telling teams not to give in to their feature creep desires. They will thank you later.
Market Knowledge
The next bit of being completely honest with yourself to reach the right mindset is to answer if you understand the market the app will target. If you are building an app that addresses a problem you have daily, then congratulations. You have unlocked the market understanding you need.
An honest appraisal of where you and your team’s knowledge base of the market have incredible knock-on effects. This will lead to you knowing where the gaps are and whether the third-party can help fill those gaps. It may be that the gaps cannot be filled readily, and the project needs to be cut, a hard decision but one that may be necessary.
Investment
How much time and effort are you willing to sink into the app is an important question to be asked. Equally as important is how much money are you willing to spend. Ideally, the project should be self-funded. Investors want their money back, more often sooner rather than later. This will place extra-stress and eat into the passion needed to see a project to completion.
Plan A should always be to self-fund and keep the passion for the project alive. Embrace the limits of available capital to its fullest. This might lead to novel solutions to problems. Given that hardware is relatively cheap and open-source software can be the jump start needed, it is possible to build a project from the ground up with limited resources.
The on Time, on Budget, and on Scope Myth
Software development has never had the greatest track record for delivering on time, on budget, and on scope. Too many it has become somewhat of a joke. While some laugh around the water cooler, team leads are waking up from deliverable nightmares.
One way to do the impossible is to keep the deadline and budget fixed. This gives teams a goal to strive for and prevents potential costs from ballooning. Critically, the third aspect of scope needs to remain flexible. If it is not possible to meet the scope demands within the allotted timeframe and budget, scope down.
The Why
Constantly asking yourself why you are working on a particular project is an important consideration. Asking why and answering it will keep one on track or realize the time, effort, and money is just not worth it.
The above points need to be considered before starting. This will help foster the right mindset to conquer the tasks that lie ahead. Asking why can be done at the start and throughout the project. This will act as your compass when navigating the several successes and failures that are bound to crop up.