So how do you measure risk for projects, which you ( or you as a member of a small indie team ) are about to embark on? This question is more relevant if the project involves some few untested concepts.

I'm asking because I don't want my current project (puzzle game) to go down the route of the previous ones. I have twice abandoned my current project and restarted it again. Its basically, at the core, a puzzle game except that the implementation include a couple of novel ideas

I have been involved in a few projects that didn't make it because, - it took much much longer than was estimated (~ 9-10 X estimated time) and the business end was flawed (though the projects eventually worked as was intended, some ultimately failed due to flawed business analysis and others failed because it was taking too much time and savings couldn't sustain it any longer). Only one of my previous projects was a full blown success, a very bad success rate

Majorly, the reason the last previous one took so long was because there were a few new concepts in the project which I estimated that I will breeze through easily after thinking about it and penciling down some algorithms. It turned out to be much more (a zillion times) complicated than estimated and my original penciled algorithms were hastily discarded.

Even though i thought I had fully learnt the lessons of my previous project and wouldn't make the same mistakes again, bizarrely history seems to be repeating it self. I'm finding things more complicated than originally penciled and its taking too long

The main issue I think, is that I have been getting the estimated implementation time very wrong because its difficult to think too many levels deep mentally alone on the implementation of the new concepts on top of the game

Recently i read a thread (damn! am not able to locate it anymore), where the OP asked why a particular game should take up to 4 years to make by the solo developer.

Overwhelmingly the replies where that 4 years (some even suggested 6 years) is just about right and not too long.

But when one factors in other pressures such as available savings (or limited funding), that answer is not so clear cut anymore

So the question is, is there a standard way of estimating this kind of risks so as to cut down if its not feasible within certain time?

Risk analysis is one of the major areas of study in the field of project management.

Commonly risk is measured systematically by breaking the project down and trying to list all of the potential setbacks and points of failure, along with a cost and probability for each. You then multiply those cost values by the probability of the risk. High values are risks that most need to be avoided and/or mitigated.

Unfortunately, getting accurate values can only be accomplished through experience. If your organization doesn't have a history to draw on for this then you have to look to similar organizations and try to get data that can be used to make reasonable estimates. This also applies to scheduling. You can make guesses, but they'll almost always be too short. The most reliable way is to base your estimates on data from previous projects. (This falls under the heading of "scope management".)

In any case, this is work for a project manager and not necessarily a programmer. If you're in a fully agile environment it's possible (though unlikely) that you don't have someone with these skills, so that's worth looking in to. If you're interested for your own sake then you may want to poke around for an introductory text on project management.

So how do you measure risk for projects, which you ( or you as a member of a small indie team ) are
about to embark on?
I'm asking because I don't want my current project (puzzle game) to go down the route of the previous
ones. I have twice abandoned my current project and restarted it again.
I have been involved in a few projects that didn't make it because, - it took much much longer than was
estimated (~ 9-10 X estimated time) and the business end was flawed (though the projects eventually
worked as was intended, some ultimately failed due to flawed business analysis and others failed
because it was taking too much time and savings couldn't sustain it any longer). Only one of my previous
projects was a full blown success, a very bad success rate
The main issue I think, is that I have been getting the estimated implementation time very wrong
because its difficult to think too many levels deep mentally alone on the implementation of the new
concepts on top of the game

There is no standard formula by which to measure risk. You have some good experience (by which I mean, you have experienced projects which failed, and one that didn't), so you can judge this.
Consider each area of risk:
- There is a risk of underestimating the time.
- There is a risk of overestimating the fun of the concept.
- There is a risk that the technology will present difficult problems.
- There is a risk that the monetization plan won't succeed.
- There is a risk of unexpected costs.
And so on. Make a list, and address each one. This becomes your risk management plan.

Recently i read a thread (damn! am not able to locate it anymore), where the OP asked why a particular
game should take up to 4 years to make by the solo developer.
Overwhelmingly the replies where that 4 years (some even suggested 6 years) is just about right and not
too long.

You posted in the For Beginners forum, but I moved it to Business/Law. I could also have moved it to Project Management, but when you mentioned monetization, I decided it was a Business question. My point is, you probably didn't look in the right forum for the topic you seek. It's probably in Project Management.

So the question is, is there a standard way of estimating this kind of risks so as to cut down if its not
feasible within certain time?

As above, not really, unless you've taken a Feasibility Analysis or Risk Management course at a business school. You'll have to do what most people do - make educated guesses about each risky aspect of the venture.

n any case, this is work for a project manager and not necessarily a programmer

In a small team you are expected to wear many hats.

In my day job I am expected to take on the role of project management, lead developer and IT manager at the same time.

For a small indie team this is likely too, so it's good to learn these skills (through experience)

Good luck in your new project!

My best suggestions is to pinpoint the risky bits, and do your own little game jam (~one for each risky), where you spend one weekend or less (NO MORE) implementing it. When the weekend is done, regardless of the success of the implementation, you will have a much better idea of how difficult it is going to be. This does not have to be weekends, but spend some time measuring what you can. Yes this will most likely be wasted code, but it will not be wasted knowledge.

Use agile development (I prefer something scrum'ish) it allows you to rescope and reprioritize as you go. Because your project will change!

Use a feature matrix to compare each feature (risky or not) with every other feature. While some things are difficult to predict before the actual implementation, this will give you an overview of most complications.

And finally once you think you have overestimated everything multiply the time with PI.

from your post it seems you have now learned though trial and error, most of the vetting process for title selection.

i'll just address them as they appear in your post.

"This question is more relevant if the project involves some few untested concepts."

ok, first off, there really should be no question marks left by the time its time to finally say go or no go. so as part of the vetting process, you must rapid prototype everything you are unsure of. penciling algo's just ain't gonna cut it. so your whole problem of the project taking longer because you had to re-design cause your original untested design didn't work goes away. OTOH, you vetting time goes up, cause you must now rapid prototype everything you've never done before. you may spend a month protoyping stuff for a game, only to discover its not a good candidate. better to waste a month than a year or 2 or 3 or 4. so now you know what to do, and you'll never have untested concepts in your projects anymore. cause they won't even become candidates until they've been tested. simple huh? more work? sure. you didn't think succeeding would be easy did you?

>> it took much much longer than was estimated (~ 9-10 X estimated time)

easy way to fix that: do your standard estimate like you normally do, then multiply by 10. for engineering in general the rule of thumb for experienced engineers is "double it", or "add 10%" when its a no-brainer.

>> some ultimately failed due to flawed business analysis

the game was not vetted thoroughly enough for sale-ability / potential demand. either you didn't do your homework, or you came to the wrong conclusion,. either way, you should have learned your lesson by now, and it won't happen again, right?

>> Only one of my previous projects was a full blown success, a very bad success rate

its about par for the design methodologies you've been using (IE muddling though). don't feel bad, we would all have similar track records under similar circumstances. "muddling through" is a rather hit or miss design methodology.

>> others failed because it was taking too much time and savings couldn't sustain it any longer

business is about making money - not spending it. all you need is a computer, software, and electricity everything else is just overhead. and NEVER quit your day job, until you've made at least 100K in games. then, even if you never sell another title, you'll have enough money to find a new career.

>> But when one factors in other pressures such as available savings (or limited funding), that answer is not so clear cut anymore

hardware, software, electric bills, and supporting yourself are all part of the costs that must be factored into the vetting process, IE "Can i afford to build this?"

and quitting your day job, and betting your savings on a game is a BAD, BAD idea. secure a source of income that will support you and pay the electric bill for the company, and can buy any required hardware / software. this factors money out of the equation at least for a while (until marketing time). then its juts a matter of how much of your time your willing to spend on development.

>> is there a standard way of estimating this kind of risks so as to cut down if its not feasible within certain time?

yes, but in the end they are estimates (educated guesses). you tend to get better at them with experience - IE as you become more educated about what it takes to succeed. so for your next project, you want to determine market demand, rapid prototype, and do time and budget estimates. then to adjust your results, divide estimated sales by 2 or 10 and increase time 10X and maybe double costs. and THEN see how viable it looks. how much to multiply or divide things by depends on how off your estimates have been in the past. you stated you've been off by a factor of 10 on time estimates, but gave no examples for sales or budgets - so i'm guessing divide by 2 or 10 or multiply by 2 or 10 for those. you will have a better idea of what the "correction factor" should be. this is really how one learns to estimate things in engineering. you do an initial estimate, and from the results determine your error factor. then the next time, you correct for your error factor. every time you do an estimate, your error tends to go down, until you reach the golden rule for engineering which is x10 for safety, x2 in general, and +10% if you know what you're doing. there are entire semester long courses in engineering on this kind of stuff (especially cost estimates, as opposed to time estimates).

n any case, this is work for a project manager and not necessarily a programmer

In a small team you are expected to wear many hats.

Yes. I just don't want to imagine an organization that has formed and operated with no one having any PM experience or training.

Many thanks everyone for the advice.

Many thanks Tom Sloper. Its true indeed that I do learn more from experience and have used lessons learnt to improve project by project.

Maybe I am just too impatient, I don't know, but it seems that despite lessons learnt from the common factors of projects, the variabilities unique to "a current project" still ends up with its own surprise bottlenecks for me

In any case, this is work for a project manager and not necessarily a programmer. If you're in a fully agile environment it's possible (though unlikely) that you don't have someone with these skills, so that's worth looking in to. If you're interested for your own sake then you may want to poke around for an introductory text on project management.

from your post it seems you have now learned though trial and error, most of the vetting process for title selection.

i'll just address them as they appear in your post.

"This question is more relevant if the project involves some few untested concepts."

ok, first off, there really should be no question marks left by the time its time to finally say go or no go. so as part of the vetting process, you must rapid prototype everything you are unsure of. penciling algo's just ain't gonna cut it. so your whole problem of the project taking longer because you had to re-design cause your original untested design didn't work goes away. OTOH, you vetting time goes up, cause you must now rapid prototype everything you've never done before. you may spend a month protoyping stuff for a game, only to discover its not a good candidate. better to waste a month than a year or 2 or 3 or 4. so now you know what to do, and you'll never have untested concepts in your projects anymore. cause they won't even become candidates until they've been tested. simple huh? more work? sure. you didn't think succeeding would be easy did you?

.... ....

.... ....

the game was not vetted thoroughly enough for sale-ability / potential demand. either you didn't do your homework, or you came to the wrong conclusion,. either way, you should have learned your lesson by now, and it won't happen again, right?

.... ....

.... ....

its about par for the design methodologies you've been using (IE muddling though). don't feel bad, we would all have similar track records under similar circumstances. "muddling through" is a rather hit or miss design methodology.

Like Briandigitalis points out, a small or single person team can't afford to hire all specialists (business, Artists, Extra programmers) required. I wish I can hire all the business-risk analyst, but for obvious reasons I can't afford to do that. So the next thing to do is to improvise which is do most aspect - meant for specialist - on my own

Rapid prototyping is a very good idea. Though, to me, the pitfall is - it still might not give a true picture since corners are being cut here and there. So rapid prototyping might as well be developing a full draft prototype, which one can then refactor, refine and rewrite algorithms - and this is close to what I'm currently doing... except its taking too much time than estimated

>> it took much much longer than was estimated (~ 9-10 X estimated time)

easy way to fix that: do your standard estimate like you normally do, then multiply by 10. for engineering in general the rule of thumb for experienced engineers is "double it", or "add 10%" when its a no-brainer.

I don't have that luxury of time

>> others failed because it was taking too much time and savings couldn't sustain it any longer

business is about making money - not spending it. all you need is a computer, software, and electricity everything else is just overhead. and NEVER quit your day job, until you've made at least 100K in games. then, even if you never sell another title, you'll have enough money to find a new career.

..... .....

..... ....

>> But when one factors in other pressures such as available savings (or limited funding), that answer is not so clear cut anymore

hardware, software, electric bills, and supporting yourself are all part of the costs that must be factored into the vetting process, IE "Can i afford to build this?"

and quitting your day job, and betting your savings on a game is a BAD, BAD idea. secure a source of income that will support you and pay the electric bill for the company, and can buy any required hardware / software. this factors money out of the equation at least for a while (until marketing time). then its juts a matter of how much of your time your willing to spend on development.

I did indeed foolishly quit my day job once but started working again (for an agency) as a contractor several months ago, allowing me flexible hours. But I prefer long stretches of day job working and long stretches of project development. That way my focus is full and unbroken during project development phase, Still I do run out of savings (and my wife does her bit to help out anyway).

Because the stretches project development tends to go longer I do run out, but its a catch 22 situation

My best suggestions is to pinpoint the risky bits, and do your own little game jam (~one for each risky), where you spend one weekend or less (NO MORE) implementing it. When the weekend is done, regardless of the success of the implementation, you will have a much better idea of how difficult it is going to be. This does not have to be weekends, but spend some time measuring what you can. Yes this will most likely be wasted code, but it will not be wasted knowledge.

Use agile development (I prefer something scrum'ish) it allows you to rescope and reprioritize as you go. Because your project will change!

Use a feature matrix to compare each feature (risky or not) with every other feature. While some things are difficult to predict before the actual implementation, this will give you an overview of most complications.

And finally once you think you have overestimated everything multiply the time with PI.

If I could complete the implementation of the risky untested concepts in one weekend , that would be a gold mine for me :) . Practically thats impossible for one programmer (maybe up to 4 programmers can complete a draft prototype in 1 months - maybe, just maybe if they are way more advanced than me and know the maths and the right algorithm straight out (so don't need to experiment - make mistakes through dead ends like I did several times) then yes, they can do a draft prototype in 1 months )

I do incremental development and testing methodology,

The reason reason for wanting the full Game before going to market is I do believe that a good brand is made on first good impression, and in any case the market is too saturated for half baked buggy similar looking games to make a break through

Like Briandigitalis points out, a small or single person team can't afford to hire all specialists (business, Artists, Extra programmers) required. I wish I can hire all the business-risk analyst, but for obvious reasons I can't afford to do that. So the next thing to do is to improvise which is do most aspect - meant for specialist - on my own

You don't need to hire someone. You do need to have someone with the skills required to do what you're doing. I'm guessing that you have at least one programmer around the place, since you're doing programming. Well, if you're conducting business then someone needs to understand how business is conducted.

It's not difficult to learn project management and risk assessment skills. I learned the basics in a couple of weeks and can easily apply it to my work.

I have had lots of experience specifying programming projects before though having worked in a web design and development place and in IT support. As the web guy it was a company with a director and myself so I was expected to understand the intricacies of quotes, job estimation, invoicing, purchase orders, and lots more. I applied these skills for a while working as a contractor.

I can probably shed a (somewhat UK centric) light on business operations and help you estimate your projects if you like, drop me a line. Be aware though although I've dealt with software development for several years none of it was game development related.

Hope this helps!