The One Big Step to Release Your First Product as a Start-up!
To be honest many people I casually chat to in business start-up mode have no plan. Which is raw and fun to begin with. They are armed with an idea, ambition, drive and a dream. The excitement and adrenalin is pumping throughout their veins.
As an entrepreneur one has many balls to juggle in the form of handling finances, sales, marketing, operations, production, strategy and of course IT.
Some businesses are fortunate enough to be so simple that they produce one single product and sell it to the general public. Cash flow is consistent, profitable, customers are loyal and competition is weak. No massive need for complicated IT systems or website. Business is basically run from a single laptop computer with Microsoft Office or Open Office. Life is simple!
On the other hand there are business models that rely entirely on a digital IT strategy. It is who and what they are known for. E.g. Facebook, You-Tube, Google …
If you are building software there is one important planning activity that I see is not taken seriously and that is a creating a project schedule. When I say schedule, I am referring to when the project starts to when it is completed. Completed being when the software is commercially deployed.
While it seems like a trivial topic to discuss within an article a software project can be setup for failure without one.
If you are unsure about whether your idea is high risk or if your budget is extremely limited. You may want to conduct a proof of concept to confirm if the idea is feasible. This outlines developing a piece of software on a smaller scale and releasing it to a small group of users. The users are not necessarily beta testers, but can be several select customers using the software and providing feedback to whether your idea has future potential. The software could be built at a minimal cost with basic functions. That way if the idea is not feasible you have invested minimal funds allowing you to investigate other ideas.
A proof of concept could also investigate if the use of new cutting edge technology is ready for mainstream use. Again, providing you with critical information on whether to pursue or invest your hard earned savings or those of other investors.
From my experience if you are working with multiple contractors, vendors or staff within a team to achieve a single outcome and in this case a piece of software. A presence of a project schedule points everyone in the same direction.
Every time a business representative or project manager engages me for a job, I ask for funding and scope confirmation and of course a schedule. Along with the project scope the schedule is a critical input which allows me to shape my estimate as a software testing consultant.
Below is a sample high level project estimate and associated schedule to be expended upon.
A schedule should always be developed and made available to wider team members or audience before commercial contracts are formulated and detailed planning commences. Running a project in an ad-hoc fashion places you at considerable risk.
A schedule is an organised list of milestones or events that occur in a particular order over a set period of time. There is a clear starting point and a clear end point.
For a start-up do you need a detailed schedule?
Well, not necessarily. A schedule needs to be practical and something that can be easily understood. Not everything will go to plan and you will make adjustments along the way. In recent weeks I have discussed the use of the agile methodology (Link to agile blog) for delivering software projects. We will go through a sample schedule in a moment based on an agile project.
Schedule in Practice
A project schedule can be shaped like the example below. Again, the whole point of developing something like the below is set expectations and modify as you go. The intention is to set everyone in the same direction.
A downloadable version of the above spreadsheet is available at the link below:
In the above example the project is completed over a 13 week period. As mentioned earlier each sprint could deploy a working piece of software to production and deliver customer value earlier. It all depends on your team and technology process maturity. Most importantly you must uphold quality at all times.
Creating this kind of simple view upfront provides a practical picture of your project. I find this aspect highly beneficially to all parties nvolved.
If you need me to expand further on any of the items discussed in this article today, please feel free to contact me.
I would love to hear your opinions, questions or subjects you wish for me to cover.
Please post your feedback to me via the discussion boards below.