Number One Problem In Seeing Projects To Completion?

What do you guys feel is the number one problem in seeing projects to completion? A lack of motivation? Others flaking out? Lets hear it and compare notes.

 

I think the biggest thing would be lack of motivation. If I start a project but become bored of working on it, then I won't continue working on it. I think a lot of reasons why people stop their work is because they choose to do things that won't excite them. I try to keep myself motivated. For example, when we were designing one of my games, I got bored pretty quick. To keep myself from abandoning it, I added another element that I would enjoy working on it. That way, I've always things to do, and I can't get bored. As you mentioned earlier, I think that I might drop a project if a lot of other people do too. But that goes back to motivation, because if other people are really excited about a project, chances are, you will be too. Another thing is that the project is just too hard. They aim too high, and when they don't get there, they become depressed and/or unwilling to continue a project. My last observation is that the project takes too long. If you have a project that you expected to finish in a year, and it actually takes 4 years, then they might just drop a project. Either that, or they just finish it to finish it, and they turn out a bad product, and they become discouraged. Now that I think about it, there's one more reason : they're idea is just too impractical. For example, I was working with a team of programmers and 3D Modelers, but those 3D Modelers had all depended on other 2D Texture artist to texture for them. We were going to make a game for iOS, but since our game would heavily rely on textures, and we couldn't find a good enough texture artist, we ended up dropping it. There's a lot of reasons in there, and a lot to discuss about. Fire away.

 

I think the biggest problem is un-realistic goals, People who are developing there first games seem to endulge into large goals like FPS and RPG's when it should be logical to start out at the base level of Pong. Motivation has never personally been an issue of my own, I think that's because I usually have money dangling in front of my face, which in that case money is my motivation.

 

other than motivation aspect, I would say , get your idea and stick with it , even if you consider it be a first iteration, but at last finish it, then you can think what you could add in more to make your game interesting.

in other term, try to plan ahead where you go for and doing so you will have better overview of code and stuff needed to glue all that together.

if you need to do A , B and C for your game , then just do that ..first , want put some D or F ...dont overdo or start to change around while you are doing , this is often a good opportunity to get bored as you will start to run everywhere , jumping all over place in your code , game etc..not good ^^..

establish your concept , take the time to think about first , before even opening unity..then when you feel you get something good >> prototype it..which should be fast if you make to yourself a clear path

also it's good to work in scope or theme , mean , when you doing gameplay stuff etc , don't waste time with having nice asset etc , you don't care , cube is all you need haha ^^..

then when come the time of polish and get to what your game should like you can spend your time at artwork...but your code part will be there and wait for your art update..

just keep focus on one aspect of the game at a time also help see some progression , which it self motivating..

good luck !

 

I think most people realize exactly how much work goes into releasing a finished product. And with non-profit teams/projects, I've noticed there is a distinct lack of milestones and trying to complete goals at a reasonable rate.

 

You have to want it.

 

How do you finish the games? Wouldn't they just succumb to feature creep if you just kept adding fancy new features?

 

Lack of planning and failure to stick to a design.

How can you get somewhere if you don't know where you are going?

Without a plan, you will flounder and lose interest.

 

Its not just a problem of wanting it. Its also a problem of time, and sometimes money.

 

Set a goal, and finish it. Sometimes things seem impossible, but then struggling through it, you learn that it doesn't take much to be amazing.

 

Mentally replace the word "Success" with "Games" in this video.

 

Note to forum moderators: This is not SPAM!! It is a joke!



Are you STILL unable to finish your projects?

Discover the EXPERT SECRETS To
"Project Completion," Earn More Money
Build Your Bankroll Using the Same
Project Management Techniques, Tools and Systems
The Pro Indie Game Developers Use to Win!​

[FONT="]
How Would You Like To Join The Top 2.5% Of
Pro Indie Game Developers, THE PROJECT COMPLETERS,
Who Consistently Finish Projects And
Make Money Every Day - And
Make Everyone Else Pay to Play On Your Games?[/FONT]​

A Personal Message from Justin Lloyd

​

​

From: Justin Lloyd
Date:Friday, 6:18PM
Subj:Are you part of the 2.5% earning more than the other 97.5% of developers?
​

Dear Forum Member,

In game development, as in life, you rarely get ahead by "standing still" - you have to keep moving, keep practicing, keep improving.

In fact, if you're not improving, you're actually falling behind because the competition is getting better and tougher.

I've "shaken things up" here at the Unity Forums to help you combat this trend of increasing competition.

What Kind of
Indie Game Developer
Are You?​

Are you still paying others to play their games? Or are you part of the elite core that makes everyone else pay them to play your games?

The top 2.5% of professional developers are the experts - these developers know and apply expert techniques to complete projects 80% or more of the time, without strong management - even more often when they do have a good team to work with or strong motivation.

The good news is... you are about to gain access to everything these experts know and do... so you can become one of the experts who makes everyone else pay to play!

How to Get Everyone Else to Pay YOU to Play
​

It's time to get serious about your game. It's time to go from endless hours of "just playing" to taking an active role in becoming a "Professional Developer" so you can get everyone else to pay YOU to play.

We'll show you how to quickly become a "Project Completer" instead of a "Project Abandoner" and:

· Arm yourself with expert tools to complete more projects
· Determine the features that you should cut to be able to finish your projects
· Limit scope and features to deliver a fantastic playing experience
· Profit bigger from the monster ideas you get
· Improve your post-release profits
· Go deeper in to the soft, easy profits
· Bring in more money more often and more consistently in the app stores

If you're ready to go beyond "just messing around" and take your game to a new, more profitable, more EXPERT level with COMPLETE PROJECTS, where you see beyond the cool features and successfully "play" the project to your advantage fully...

And if you want to find out HOW the EXPERTS take your money, so you can stop giving your money away to other developers, and rather employ those techniques to your own advantage...
...then please read on and I'll show you how you can become part of the "Top 2.5%" who make everyone else pay to play your games, using Professional Developer Justin Lloyds secrets and expert project completion techniques, revealed here in The New Complete Your Project 3.0!

You'll learn STEP-BY-STEP how to employ expert techniques to fill the gaps in your game and take it to new heights.

Meet Your New Guide to
Expert Project Completion
for The New Complete Your Project 3.0,
Justin Lloyd​

Professional Developer Justin Lloyd brings the missing "expert techniques" and experience in to the Complete Your Project.

Justin brings the expertise and the energy to show you how to complete more projects with high-risk, bigger payout clients -- where the higher leverage and big paydays can take your bankroll to new heights.

Justin has completed projects that have generated more than $750 million in revenue. He has become a project completer on every project he has completed, from low-risk, short-turn-around tutorials to high-risk multi-million dollar projects that are failing. Justin is a proven multi-project professional developer with more than 100 projects completed, both personal and professional.

Justin Lloyd - Professional Project Completer Instructor
​

PRO DEVELOPER STATISTICS SUMMARY

- Over $750 million in delivered projects
- More than 100 projects completed
- Full-time professional developer since 1978
- Expert level instructor
​

Justin is a seasoned professional developer. He has delivered great projects in hot young start-ups and Fortune 50 corporations and has honed his game over 33 years of designing, developing and delivering great video game experiences.

Justin's high-risk project experience has had major influences on how he approaches any new project, cutting through the bullshit and the project management fluff to get at the meat of where the problem lies.

His resulting style could be described as hyper-aggressive, built on the foundations of:

1) maintaining first mover initiative to gain the maximum output from everyone involved
2) generating unusually large project payoffs by being concerned about the smallest of details

More recently, Justin has created and patented several techniques for analysing projects and ensuring those projects get delivered quickly, techniques which are now exclusively available to The New Complete Your Project 3.0 members only!

Introducing...
The New Complete Your Project 3.0
​

​

And... I didn't complete this project. I would have done more here but didn't want to get banned for posting a long-form sales letter joke!



P.S. Most text shamelessly plagiarised from some crappy website trying to sell you a poker system.

 

As someone now currently working of finishing a long-term Unity project (and was going to get on doing that before I started reading this forum lol), I'd say the most difficult aspect is motivation. When you start a new project it's exciting: you can literally do or at least try anything you want, you have to think of new ideas, expand your game programming horizons and have a chance to work on new art with a new art style. Although the task might seem daunting, that's all the more motivation to work on it more so you can and everyone else can see the final thing that you think is a really good idea.

However, as I am realizing from this project, the more you progress in a project the less motivated you become (at least in my case). As you complete more stuff, the concept becomes more set in stone and you are stuck with the thing you thought of months or years ago, and that creative spark disappears and it turns into what feels like more of a chore. Now that my project is almost complete, the fact that I can release it soon excites me, but at the same time the stuff I still do have to complete seems all the more mundane and stupid if you look at how complete the project already is.

I think, as other people like Hippocoder said in this thread, the main way to get motivated to finish a project is to really like the thing you are working on and try to make it the best you can so other people will like it. One way to do this that works for me in an almost complete project is to look at the work that you have already done and see how (presumably) good it is and tell yourself that you don't want this work to go to waste by not working on it. Doing this might be more time consuming then just working directly, but it has a bonus of boosting the morale and you also get to see your old stuff in a new light and fix the things you don't like on the fly.

EDIT: To be honest, one way to combat lack of motivation later in a project might be to show off the WIP and get positive feedback that motivates you to continue working (assuming your project is as god as you think it is). With my project I can't do that, but I imagine for most projects that would be a good idea.

 

1. Lack of Planning_ Most won't notice this right away as the beginning is always the Honeymoon stage

1. Lack of Leadership_ I could write a book on this, every team needs a leader and that leader should do one thing well (LEAD) a good leader should not be the one getting down in the weeds he/she should delegate and oversee the project as a whole.

2. Lack of the right people_ Game design can be (fun frustrating hard work) with the right people or (slow painful death) with the wrong people, Ambition goes a short way in game development but talent and skill get the job done! (Note) if you are indie keep your team manageable.

3. Lack of Motivation_ Often times development will stall or hit bottlenecks and that synergy the team once had will be tested, it seems the freshman and rookies are the ones quickest to throw their hands up while the juniors ride it out and the seniors keep pushing.

4. Lack of Organization_ Every development team should be organized as best as possible

The number one problem i have encountered working on other projects is leadership and planning to me they are one in the same a good leader will start out with a good plan and follow through on it, if things get rough a good leader should be able to adapt and take a new route (While continuing with his/her overall goal)

 

I think that there are two main reasons.
In fresh starters of game development main reason are too big expectations and goals. More or less everyone starts development on RPG, MMO or something very big and what happens, few weeks later you dont hear about this project being developed ever again.

For those who are in development a tad longer and have learned their lesson, for them the main problem is either lack of planing i guess.

 

Somethings not right. I purchased it from the website through PayPal, but my order has not been delivered yet. I am unable to contact the salesperson through the website. What's going on?

 

That was a great video, I never thought of it quite like that. I think its very true of achieving tough goals, you have to want it bad enough.

A lot of the posts I see around these forums of beginners aspiring to build a huge game, it just kills me, they have no clue what they are attempting is almost impossible. The guy that made the indie MMO, he had what, 10+ previous games? If he had tried to do that as his first game, you know there is no chance in hell he would have completed it.

 

What kills me is being home alone Temptation of going back to normal work breathes on my neck all the time, guess that is where usually freelancing fails, and that's where i may end this solo indie fun

 

Ah, the force is weak in this one.



But seriously, you can blame it on anything you want, money, relying on other people, as long as you have an good enough computer (doesn't have to be a from this year even) the only real thing stopping most people from making and completing a game is motivation.
There are people that are severely handicapped that has been able to accomplish great things, this because they didn't stop at nothing to meet their goal.

 

Team dedication/talent and scope

Start with a simple project finish it (if you are a programmer just buy your art assets). For your next project try to get an artist that you can complete in a few months (rather a few years).

 

I think the main problem is to take a challenge that you are able/willing to accomplish!

 

Lack of focus.

 

It's the lack of inspiration and/or a drive to finish.

 

I mean little things, like possibly a unique way of how a person shoots. That way I can develop that idea, and suddenly, the game seems more fun to me. That's also a way of developing you're game to be the amazing game you set out to create in the first place.

 

I would say lack of experience leading to an underestimation of the workload. The fact that you make make a playable prototype in Unity in the space of a few hours is very deceptive as it could take many hundreds of hours to polish that into a game. Secondly the time and effort gives diminishing returns. In the first few hours, the project went from zero to fun. In the final few hours it goes from completely finished with an obscure bug, to completely finished without the obscure bug. It is a gradual process but each day has less impact on the game than the one before. I think the fact that anyone who hasn't completed a project does not know this, is the main reason why most projects are overly ambitious and not completed.

 

Yes it is. If you WANT it, you make the time and money, no matter what. I emphasise it in the boldest possible way. It has to be an obsession, above and beyond the call of duty or needs.

If you truly want something bad enough you will fold space and time to make it happen. Same for people giving up smoking. They have to want to.

There's no magical shortcut, no special trick, no little document telling you how. If 100% of you doesn't want it bad enough you'll give up.

 

I suppose I shouldn't go against experience. Actually, you make a convincing argument.

 

Decay of motivation: When I was working on my game and ready to add a title screen and do the final polishes, I suddenly lost motivation to finish the project, therefore, I released it prematurely.

 

While I don't disagree with your reasoning, 'want' is a subjective quantity. Everyone does want it when the start, otherwise why would they bother at all? A strong desire will push through the boredom and monotony but it alone is not a sufficient condition for project completion.

 

I want an MMMORPG really bad with all my heart! it is my life's goal and dream! I've been focusing on this ever since I was little!!
I want it, I WANT IT!!


I think experience (or lack thereof) comes into play more than some might think. That is perhaps why I am currently unmotivated to finish my game.

 

Not realizing all of the really boring annoying technical stuff that you inevitably have to do that you didn't envision when you started out. Most projects become `work` at some point and can be a bit of a pain. But you have to have a lot of patience and perseverance and give yourself time away from things when you need to otherwise ignoring your natural needs will only make things worse. Also don't set your sights TOO high or you will just generate a lot of guilt about not achieving the standard you set for yourself which will act as a major deterrent against desiring to work on it at all.

 

Lack of time/motivation

Im a one man band. I write code at work during the day. Sometimes when I get home, the last thing I want to do is write more code... but im persisting, because atm, im enjoying it more than playing games. Although sometimes I just have to back away and go play some games to give my brain a break. Would love to be doing this fulltime, but until I can make a game that makes me enough money to leave my job, im just gonna have to deal with it.

ps. im tired. lols

 

@jlcnz: I can definately relate!

 

While I would agree with most people here, I think the biggest problem comes down to lack of experience. I had studied the industry for years while working as a hobbyist. However, nothing but experience can prepare you for the reality of game development.

Hobbyist developers hold on to this idealistic view of their work, assuming that they are the one person who can develop their massive (typically MMO) project, while all others around them have failed. When it comes down to it though; when you're dealing with real developers and real money, a LOT has to change. Your head needs to come out of the clouds and you need to create something that generate income before you run out of money.

If you get that opportunity to get into real development, you'll have to learn to plan small projects. Cover every angle. Make the tough decisions of which features are simply more costly than they're worth.

So yes, it is lack of direction, lack of preparation, and too high of expectations, all of which leads to a faltering in motivation. All of this, however, can only be overcome once you've really gotten into the trenches and learned the hard way.

 

Here is why you haven't fully agreed with what I wrote about 'want'. If in the desert, a man has a chance to make it, no matter how impossible it seems or how hot the sun shines on his back... he can make it only if he wants to live badly enough.

Thats nothing to do with:

need
desire
boredom
depression

Or any emotion you describe. I put to you, that 'want' is the most powerful of them all, and I'll explain why this simple feeling is the strongest and the most useful to you.

'want' is a decision. It is often confused with just 'fancying' something or 'maybe i'll get it' sort of thing. But the true meaning of want, when it's 100%, it means there's one decision. You either want it or you don't.

When a man knows what he wants, truely knows, and makes the decision to get what he wants, nothing in the world can stop him. It didn't stop me despite disability, poverty and everything stacked up against me. I wanted to make it as an indie so I did.

There's many times where every part of me screamed to give up and take the easy route.
Other people would have worded it as: "There's many times where every part of me wanted to give up'. But if I wanted to give up, I wouldn't be here today would I?

 

I agree with the honourable, inch thick steel biting, Hippopotamidae gentleman.

But that said, there is a point where you can "want it" all you like, but you won't get it simply because you lack the tools to acquire the tools to do the job. There is nothing wrong with a one-man army, with little of the required skills, wanting to create an MMORPG and being able to actually pull it off. I've seen people do this. But... and it is a huge but, that one man army learnt the tools and skills to acquire the tools and skills they would need to be able to pull it off. They didn't immediately start making the MMORPG as their first project or even second project. No matter how badly they wanted, they couldn't have it, until they put in the time to learn how to get it and not just want it.

 

Sounds like a vote for lack of motivation.

 

It sounds like we're all on the same page and we're starting to get into semantics. I agree with you Hippo.

 

I'm just curious: what exactly is this fascination with MMORPGs? I'm a beginner progammer, an indie wannebe if you will, and the LAST thing I'd want to try and make is an MMO. I'd rather try and make 3 or 4 "small" games a year than spend 10 years trying to make 1 game. Apart from the sheer size of the task, the gaps in the market exist for smaller projects. It just doesn't make sense to tackle big projects without a lot of experience AND a lot of people working with you.

 

I think many 10 year olds think it's a get-rich-quick scheme to make an MMO that will have paid accounts and will become very popular.

 

I agree with all of this. I have reached that point.....and boy is it stressful. Although I'm just a kid, the project is beginning to stress me out and I feel some sort of obligation to work on it. BUT, It is one of my goals to finish the project and I really want (want as Hippotense form) to. I lack experience but I'll still try to come up with a game, whether it's what I envisioned or not (most likely not).

 

I would like to subscribe to your newsletter.

 

What I would really like to do, is write something small, that makes me enough to get by, so I can spend all the time I like working on the bigger projects I have in mind.

Would love to get it to the point where I can afford to hire additional ppl (artists generally). ATM, I resort to buying the models, since I dont have the skills atm. I know the basics, but im still slow at it. One day I would like to be able to belt out awesome models for stuff, but ill just stick to what I know for now which is coding... there is certainly plenty of that to be done!

 

You have to want it.

 

I would like to subscribe to your newsletter.

 

You can't have it.

 

hahaa :')

 

I can tell you when I was that age I had a dream of making an MMO, (I didn't mention it publicly on forums though). I don't play any MMOs but for me it represented the ultimate game experience if it could be done right. Imagine your favourite TV show/movie/book and make a whole universe exactly like that with thousands of people all playing different roles. Sounds pretty cool, but fairly disconnected from the reality of game development.

 

Complete 80% Of The Projects You Start With These 5 Simple Steps​

How do you get better at completing more projects?

But let's not talk about that right now, let's talk about what makes people want to start and hopefully finish a project in the first place.

I can say with reasonable certainty that the people reading this post on the Unity forums have all worked on projects to some degree. School essays, college assignments, office work, putting up book shelves, finishing a video game, writing a blog post.

Let's talk about projects you have had success with in the past that you weren't doing on your own. Generally if you live in a first world country you attended a structured schooling environment and then progressed to a structured work environment. Both of these environments offered a variety of opportunities to work on projects either alone, in pairs or in groups of varying sizes. These projects, which you may or may not have had a hand in deciding the parameters of, were most likely dictated by an outside motivator, e.g. your teacher or your immediate supervisor, that dictated the subject, the goal, the scope, the deadlines, and the success criteria. The outside motivator most likely set out what resources you were permitted to use or had access to, the plan of how to execute, often not detailed but detailed enough that you didn't have to think about what to do next, and the final delivery method.

For example, "Write a four page essay, double spaced, covering the economic impact of the immediate years after the death of Alexander the Great, include references to primary political players of the era. Delivery in is in two weeks, by 5PM on 15th of December. You are expected to work alone on this essay. Late submissions will not be accepted." This is a project with fixed scope, a hard deadline with failure consequences, success criteria, and even the hint of a plan and resource allocation. Most people, when developing their own projects, don't have anything this clear or succinct to work from. Their "project" flounders around, unable to be completed because there is no goal, or the goal is too big, no plan to speak of, nothing is actionable, there is no success criteria, and certainly no realisation of resource availability, i.e. your time.

Notice I didn't say anything about deadlines. Deadlines are important, sometimes they are the most important thing to consider, "We must have this complete so it can be picked up by Fedex at 5PM!" and sometimes they are not important at all "I need to clean the cat litter, but I can let it slide a few days because I'll just live with the bad smell. The cats just learn to use the toilet like a civilized species."

When you work in a structured environment like that, where the project is handed to you, and you are expected to just get on with it, the project details are usually already decided by someone else well in advance, at least if you work in a productive office environment and not one that I have had occasion to experience at some companies where nobody really knows what we are doing from one day to the next.

How do you get better at playing the piano?

Every day you practice. You play scales. You do finger exercises. You stretch yourself with new pieces and new musical styles.

You define the project. You define success criteria. You make a plan of small achievable daily goals. You act on the plan. You commit to deliver.

There are three distinct stages to any project of appreciable size and complexity. There is some overlap between all of the stages, but to have a well executed project, they should attempt to be as distinct as possible:

• Planning
• Development
• Production

The first stage, planning, is when the germ of the idea is being explored, estimates given on the amount of resources required, features thought, and ideas kicked around. From planning we move to development, the stage where deep research in to thorny, unanswerable questions is done, difficult problems are solved and any early weaknesses in our assumptions are found. Development is where a lot of the interesting work lay for most people. Production, our final stage of a project, is where we are doing the hard work that is the day to day slog of getting the project done and finished. Production is actually the area where many non-professionals, and several professionals for that matter, fall down because this is where people lose motivation and interest.

There is no shame in doing lots of "development-style" projects where the majority of the focus is doing something for the fun of it, for the hell of it, for the learning experience. I do a few of these projects a month. Sometimes more if I am answering a couple of involved questions on various business forums, entrepreneur forums and developer forums that I inhabit. The big takeaway from these development focused projects though is that I do move them through to the final, albeit much shorter stage of production. I complete the development project in some form that I can say "It's done!" which usually involves a public posting of the work somewhere. The final project might not be any good, but I have reached a point of closure where it is no longer at the back of mind where I am thinking "Yeah, I need to get back to that someday." I am mentally freed to move on to the next project because I know that I have completed that particular project.

There are five easily identified faces to successfully completing projects:

• Motivation
• Focus
• Planning
• Resources
• Delivery

Let's talk about Motivation first. It's the single most important criteria for starting and finishing any project as identified by everyone who gives this subject some thought. We need motivation to start our project, we need motivation to get us through the hard slog of the excruciatingly boring parts -- boring to us anyway -- we need motivation to finish our project and deliver it whoever the end customer is, whether that customer is just us, a client, a future customer, or our pet cat. Motivation is the primary factor and comes in two flavours. One is more powerful than the other, and I'll talk about that in a moment, but both have their place in any project we undertake, and each type of motivation is important at different stages of the project.

The first type, external motivation, is something outside of us and comes in many forms; our boss telling us we'll be fired if we don't do our jobs, our wife nagging us for a new car, the prospect of earning money, a deadline that is part of our final grade. The list of external motivators is endless. External motivation has a powerful short-term effect on us, the deadline set by our teacher galvanizes us to knuckle down and get the essay finished, the increase in salary we just got given makes us work just a little harder and a little bit more diligently.

For a while at least.

External motivation and external motivators arrive in two forms: punishment motivators and reward motivators.

Punishment motivators are failing to meet deadlines, the threat of being fired, our cat dumping on the carpet because we failed to clean the litter box, flunking out because we didn’t complete our essay. With punishment motivators the usually short-term pain is what gets us to do what needs to be done. The problem with punishment motivators is that we soon start to ignore the pain or punishment, perversely at times, even welcome it. We miss one deadline, we get a stern lecture from our boss, but that wasn't so bad was it? A couple of hours later we've forgotten the pep talk and we're busy working on our next project. And we fail another deadline, and another pep talk. We fail to clean the litter box and have to side-step another stinky pile on the carpet. Pretty soon this becomes the norm for us, we've slid down to a new level of acceptable punishment motivation and have learned to tolerate and even ignore the short-term pain. It's just one more stinky pile that needs to be avoided on the way to the kitchen for another Mt Dew.

Reward motivators are pats on the back, certificates of recognition, increases in salary, a fancy new office, a better chair, a company lunch, a graduation gift of a new car. Reward motivators offer a short-term buoyancy effect to our ego and to our productivity. Unfortunately for us receiving the reward and the external motivator delivering the reward, that buoyancy soon wears off. There's two issues with reward motivators; novelty overload and entitlement.

Novelty comes from being given that fancy new Aeron chair, the faster workstation, a fancy certificate for a job well done or an increase in pay for getting the project out. The problem with novelty is that it quickly overloads to the point where the uniqueness of being given something for doing what you do is no longer of interest to you. "Oh look! Another plaque with my name on it! Oh dear! Another honorary degree for showing up! Yawn!"

Entitlement creeps up on us; "Because I'm worth it!"

We may no longer be doing work that is worth what we're paid, no longer delivering work that is worth what we earn, we’re not giving the best we can, but we have built ourselves up to such a level of self-worth, at least self-perceived worth, that should the rewards not keep flowing, and increasing, we feel slighted; we want those rewards, we earned them, damnit!

How do you get better at writing?

Every day you practice. You expand your vocabulary. You read authors outside of your immediate interests. You stretch yourself with new genres and new writing styles.

You define the project. You define success criteria. You make a plan of small achievable daily goals. You act on the plan. You commit to deliver.

Internal motivation is what makes us get out of bed in the morning and be ecstatic that we’re off to do something we enjoy. Internal motivation comes directly from being engaged in interesting and worthwhile work. It drives our ego and gives us self-worth. Internal motivators constantly shift depending on what we are doing; interest in solving a difficult problem, desire to do a good job, a need to show the world our ability, engagement in our task. Of either kind of motivation, internal motivators are the most powerful and the longest lasting. Internal motivators, if properly driven, never wane unless we engage in activities that are of no consequence to us.

Learning when to use internal motivators and external motivators is a useful tool in our extensive tool box of completing projects. The first part of training to recognize when to switch from one to the other is being able to identify whether the task you are undertaking is engaging to you or not. A task that is not pulling you towards completion and is not pulling you towards it so that you want to tackle it immediately needs to be driven by external motivators; rewards, deadlines, planned structure from an external source. You need to change from the pull that is not happening to a push that can happen. A task that you cannot stop working on or thinking about until it is completed and all of the interesting work is done pulls you towards it. It grabs hold of you and won't let go until you are done no matter how insurmountable the problem.

"Let's go to the moon, land a man on it, and safely return him to Earth."

A focused project permits everyone who works towards delivery understand the full scope of the work to be done. Each team member may not grasp all of the fine detail work, and some team members may not fully understand or appreciate the necessity of another person's contribution but everyone should be able to agree, based on good project focus, exactly what the project covers.

Purely creative projects rarely start out with a strong focus because the creative artist isn't sure which direction their creativity will take them. Purely technical projects usually do because there is some unique problem that someone, somewhere, is trying to solve. Sat in the middle is game development where the creativity is leashed but the technical problem is not well stated. A good game designer and able project manager can bring those two opposing forces in to balance so that the project does not begin in an unfocused state.

Many creative/technical projects, e.g. game development projects, if begun with naivety can either start completely unfocused or become unfocused due to a lack of any kind of clear statement of what the project is about. "We're making a zombie fantasy MMOFPSRPG!" isn't very clearly stated because everybody's opinion about what that sort of game entails is different.

Let's compare "zombie fantasy MMOFPSRPG" to the paraphrased quote up there.

Someone on Earth says: "Let's go to the moon!"

And you are unlikely to hear, unless the person is a trolling pedant, "Which moon are we talking about precisely?" As far as sane Earth people are concerned, there is only one moon to go to. Stop talking nonsense, we're going to the Moon.

"Let's have a man land on the moon."

Only the aforementioned pedant will ask: "Does he have to get out and walk around or can he just look out the window and say he did it?" Of course, he is going to walk around on it, sending him to look out the window? You might as well get him to lie in a cornfield in Iowa and just stare up at the night sky.

"Once he's done his walking about I think we should safely return our man to the Earth!"

Again, the pedant asks, "Does he have to be alive? All limbs intact? Will he bring back his pet monkey he took with him?" because clearly "safely return him" is open to debate as to the true meaning of the phrase.

If you are debating the exact meaning of the sentence "Let's go to the moon, land a man on it, and safely return him to Earth." either the stated project is unclear and unfocused, or you're dealing with that self-same pedant.

Or internet forum trolls.

But I repeat myself.

Bring focus to your project. When someone asks you what you project is about, and you cannot clearly and succinctly state that without leaving what you say open to questioning or debate or interpretation, your project is unfocused. Keep reworking what your project is about until there is no question in anybody's mind what you are doing.

Should you ever find yourself having to explain any part of your project statement, or debate about the exact meaning of what your project covers, you have one choice: STOP! Stop work, go back to your project statement, focus it until there is no more questions and no more debate, then work through all of your features removing those that don't fit in to that statement -- "And he will be able to play golf on the lunar surface!" -- and then continue work.

Don't confuse having to explain particular implementation or design details of your project with the project statement itself. Explaining design details when someone asks how you are going to solve a particular problem or how you have solved a particular problem is a separate discussion to what the project is about. "Let's go to the moon, land a man on it, and safely return him to Earth." leaves a lot of room to discuss implementation details of how to get there, how to land, and how to get back. In the case of the moon shot tens of millions, if not hundreds of millions, of small decisions to get from here to there and back again were made and discussed. You can learn to recognise what is a question about an implementation detail and what is a question of what the project is about reasonably easily by listening to whether the asker is referring to something directly in the project statement. "Which moon?" or "how safely?" are both questions that needn't be answered because the asker didn't hear the statement to begin with. Compare those questions with "will we use rockets or a slingshot?" or "how long will he be on the lunar surface?" or "how many people will go?" are concerned with implementation details. The questions are not wondering about your statement but about what your project encompasses: implementation detail questions always concern themselves with the "how" of the project, the "best way", the "quickest way," the "easiest way," "the cheapest way," rather than the "what" of the project: "What are we doing again?"

There's two ways a project can grow uncontrollably beyond the abilities and the resources of the people working on the project, the obvious culprit is feature creep, which I will talk about at length in while, but the other project killer is scope just when the project itself is incipient. Now often people will believe that the scope of a project can be limited by either rigidly defining what the project will be, or by creating an overly detailed plan so that all features are accounted for. The problem with both approaches is that neither strikes at the heart of the problem; cutting out, before they go in to production, those features that are beyond either the capabilities of the team, the resources to hand or planned for resources, but more importantly, beyond the success criteria of the project.

You can limit scope by deciding, during the planning and development phase of your project what will be included, and asking yourself "do these features that I'm designing support the success criteria and the project statement directly, or are they superfluous? Can I cut them before I even develop them?"

"But I'm doing a creative project! I'm making a game! You can't decide whether a feature will be fun until you create it! How can you define whether a feature will support your so-called success criteria until it has been created, balanced, played, made fun!"

This is something you often hear from young game designers within the games industry, but you hear this lament even more frequently from people who aren't even game designers, they play games, they discuss games, but they don't actually make games. To a degree, the lament is partially true, but only very partially. Experienced designers have a large toolbox of tricks and techniques to figure out what will be fun and by keeping the project in the development phase rather than the production phase until any revolutionary features are tested and tuned. By relying on those tricks and techniques that have come from long experience practicing their art of game design, game designers are able to quickly put together a robust set of features and still maintain a limited scope.

You need to learn to stop feature creep at every step. Between deciding to begin a project and the delivery of that project, you will make thousands of small decisions that will guide the project along to a successful resolution, but each of those small decisions can lead to big problems if you do not carefully consider whether it is a decision that adds work or a decision that removes work. Your aim is to remove work as much as possible but still deliver the project. You have to train yourself to say "No" more often than "Yes" to various ideas that pop up during the development of any project. If you've worked on any kind of creative or technical project that has a poorly defined scope you will have heard the dreaded "How hard would it be...?" question at least once, and possibly countless times. You may have been asked it, you may have been asking it of someone else, you may even have been asking it of yourself. The "how hard would it be" problem is just one aspect of the bigger feature creep problem but it is usually the most common. The ideas that come to you at the beginning of a project are often nebulous and indistinct and firm up as the work proceeds. Oftentimes you will be trying to think up features to add and be drawing blanks until you brainstorm a bit and then ideas will start flowing all at once. These aren't the problem features because it is reasonably trivial to cut features that have not yet been implemented or had very much thought put in to them. It is the late stage ideas, the ideas that begin with "How hard would it...?" that take place when you are deep in to project development that can de-rail the work, require copious reworking of foundation work that has already taken place and cause any project to lose focus and delay delivery.

How do you get better at art?

Every day you practice. You draw still life. You draw live models. You stretch yourself with new techniques and new styles.

You define the project. You define success criteria. You make a plan of small achievable daily goals. You act on the plan. You commit to deliver.

If there is one skill, out of all skills you learn, learning to say "No" to feature creep will be the hardest for you to master for a variety of psychological and political reasons. When your boss comes to you with the latest idea fermenting in his head about an off-the-cuff remark made to a client over lunch one day it can be difficult to guide him away from creating extra work that will potentially jeopardize the project. Working on collaborative projects with other people who volunteer their time can also prove to be a difficult dance of negotiation as you attempt to get everyone to move in the direction that creates value to the project rather than each volunteer pulling in their own direction that may not be in the best interests of the project or the team at large.

A project statement is concerned with the "what" of a project. A project plan is concerned with the "how." Every project needs a plan. No plan, no project. Starting a project without a plan is just planning to fail. The earliest work on any project should be the drafting of the plan on how to reach the success criteria that means the project can be delivered. A plan should consist of individual actionable steps that someone should be able to read, understand and take action on.

Each step within the project plan should concentrate on the details of what needs to happen, these are the tasks that need to take place for the project plan to be executed. Individual steps should avoid covering the details of implementation generally because you want to keep the plan understandable by people without detailed domain specific knowledge, i.e. avoid jargon, avoid minutiae, avoid telling someone knowledgeable about the subject how to do their job.

Any plan you draft will need to be flexible enough to change as the project proceeds. A plan needs to change either due to changing requirements or due to external influences. Changing requirements can be to do with matters such as Apple releasing a new iPhone if you are developing a game for iOS or the client wanting a feature changed to better meet their needs. External influences impacting the plan and forcing a change are can be egregious, such as a team member quitting, or subtle, such as a bug being discovered in an essential tool that has no immediate workaround. Whilst changing requirements and external influences can appear to be the same thing at times, who doesn't think that a client's changing needs are an external influence on the plan, it is best to try and think of them as distinct as one can actually be reasonably planned for with slack built in to the project plan for changing client requirements, or even ignored as in the case of the a new iPhone model being released, whereas external influences are often difficult to predict and budget suitable resources for.

As a plan is created, there will appear at least one step or detail, often more in a sufficiently complex plan, that makes the entire plan hinge on it. A failure at that step, or lack of sufficient knowledge about the detail, can bring the entire plan from that point on in to jeopardy. A sweep through the plan, questioning the assumptions about each step can usually allow you to easily identify the problematic steps and either remove the step and use a different solution or mark the step as a high risk issue that should be tackled as early as possible.

President: "Let's go to the moon, land a man on it, and safely return him to Earth."

Manager: "What colour should the walls be?"

President: "What?"

Manager: "The walls? What colour should they be? There's a step in the plan where we spend two days deciding what colour the walls in the control room should be. Well, what colour? We can't move forward until we've gotten a consensus on this huge problem."

Ever seen a plan that includes a step to decide what colour the walls should be? And everyone should be involved in the decision making process. I'll bet you have if you've ever worked on a large-ish project, even if it hasn't been exactly worded like that, there's a step in almost every plan that involves picking out paint colours for the walls. It's a step that doesn't move the plan forward, it stalls everyone while everyone has an opinion on the best, brightest, cheapest, most productive colour to use on the wall. These are steps you need to work actively to remove from your plan. Any step that doesn't make the plan move forward at full speed is just wasting time and resources. Kill these steps at every opportunity.

Projects need resources. Big projects need lots of resources. When you are planning on your project and what you aim to achieve, take in to account what resources you have available and what amount of them you can spend on the project. I work a full-time job for various clients so my personal time is limited, any personal projects I want to work on and plan out must take in to account the fact that I have a limited amount of time available to dedicate. I can hire people to work for me, but then I am expending capital resources to purchase another person's time and expertise and that resource isn't infinitely deep. My project, and my plan for that project must fit available resources otherwise I will fail to deliver.

Over-commitment of resource is one of the primary reasons why any project fails. "And this scripter guy I know is going to work 100 hours a week!" I have seen failed professional projects so many times because the resources available to the team were over-committed at every decision point and action step in the plan. There was no slack for unplanned for work, there was no leeway for error or misjudgement, the plan assumed that every action would be perfectly executed, every detail was flawless. This never happens in real life. What happens in real life is real life. When making your project plan you should commit at most, 80% of a professional's paid time, and at most 10% of a volunteer's unpaid time. These figures are usually a lot lower, but anything over those numbers should raise huge warning flags for you when looking over a plan that something is going to go catastrophically wrong in execution.

Many volunteer teams on the Unity forums plan, if they have a plan at all, on resources that are not available to them. There are also no resources that can be converted from one type to another, e.g. money in to code, or money in to art. Realistic projects and plans take in to account available resources, conversion of resources from one type to another, and also planned for resources, i.e. acquiring the part-time help of a volunteer scripter.

Plans often create issues by building on the assumption of resources that will become available in the near future as though by magic. Invariably, these resources never materialise and the project flounders. Having just a game designer and an so-so 3D artist who can't texture you can plan on starting a game within those available resources, and you may realistically plan on locating and retaining a programmer of some ability in the not too distant future as you work through your initial planning stage. This is a realistic estimate both of resources available and resources that you intend to acquire. Having the same game designer and so-so 3D artist who can't texture and planning on bringing on five more modellers, two texture artists, three programmers and a bunch of other workers, when you have no capital resources and doing it within three months is not a realistic estimation of your available resources and estimated future resources. Build your plan to your resources on-hand, with a little slack for growth if you think you can swing it.

You've planned, you've developed, you've produced. There's nothing more to do. Now what? Now you deliver. Now you make concrete your project. A blog post needs to be posted. An application needs to be compiled in to an executable that runs on a different machine than your development workstation. Your Unity game needs to be "Built" both as stand-alone and as a web player or pushed to the mobile target platform of your choice. Your artwork needs to be displayed. If you create a project, but don't deliver it, your effort was meaningless except as a learning exercise. To gain any kind of value from your work, you must deliver that work. Even if all you do is deliver the project in to your personal portfolio, the act of delivery brings closure and you are free to move on to the next project without the current one, and possibly the myriad incomplete details that go with it, dogging your thoughts every day.

There's a number of reasons people are unable to deliver a project; fear, inexperience, lack of resources, lack of direction, lack of success criteria. The latter three are easily overcome with proper planning and knowledge. Inexperience can be fixed by just experiencing. But the first, fear, is the biggest reason and almost the sole reason most people are unable to deliver anything. People are afraid to put themselves out there and show off what they can do. They don't want the rejection, they don't want the criticism, they don't want the trolls hurting their feelings. This fear is what holds most people back from achieving anything in life.

Many projects I have been involved with for clients have no end. There are projects, maintenance work mostly, that legitimately do not have an end to them, the first iteration of the on-line system is built or the eCommerce website is created, and then it becomes a maintenance project from that day forward with small incremental improvements that are ongoing for years at a time. But then there are the interminable "it'll be done when it's done" projects that are poorly defined from the very beginning, or suffer from bad project management that means the project is constantly trying to meet new goals every few months that were never part of the original project statement. Part of your success criteria is knowing when the project has reached the point of delivery, but many projects, with poor success criteria, or none at all, will drag on indefinitely. These are great projects if you are not worried about cash flow and you don't mind doing mostly the same stagnating tasks week after week. But they aren't where the excitement is. Those projects aren't pushing the boundaries either of development, creativity or your skill set. Nobody ever did great work whilst working on a maintenance project. Nobody ever excelled re-designing some buttons for v5.1 of a project. Knowing when to say "it's done" is a valuable skill to learn, and you can learn it by setting easily measurable and easily understandable success criteria for your project.

Let's all do an infinite loop! You cannot deliver a project if you do not know when you have reached the point of delivery. When planning out any project, there must be at least one success criteria. Often times a project will have several success criteria but the fewer it has, the easier it is to verify that you have met the criteria. Just one success criteria will let you know you are done and can stop working on the project. You're done. Hand it over if you need to and go home. If you are a programmer, you understand all about infinite loops. for ( ; ; ) { ... } and while (true) { ... } and do { ... } while (!HELL_FROZEN_OVER); There's no exit criteria from the loop -- assuming there isn't a "break" statement anywhere in the loop -- that permits the processor to know when the task is done. "Run forever!" This isn't a terribly interesting project to be working on if it is never done-done.

Success criteria should be easy to understand and need to be easily measurable. No criteria should be mutually exclusive of any other, i.e. you cannot have conflicting criteria. You're a sensible person, you won't ever write success criteria that is mutually exclusive with some other success criteria, right?

Success criteria should be as simple as you can state them: "I'm done with this project when I have the server backing up to the external drive." Simple, easy to understand, verifiable. That said, possibly a bad success criteria, because even though the project is done, you might have cables and wiring that has to be tidied up, so your project is "done" but it is not "done-done." A simple rewording of the criteria "I'm done with this project when I have the server backing up and the installation area is clear of debris and cables." is still trivial to understand, not mutually exclusive, and verifiable.

How do you get better at chess?

Every day you practice. You play different styles. You learn new opening moves. You stretch yourself against better and different opponents.

You define the project. You define success criteria. You make a plan of small achievable daily goals. You act on the plan. You commit to deliver.

Finishing a project is a huge thrill. I am a very results oriented person and I tend to surround myself with other results oriented people. I don't "get results," I make sure there is a result. If a project I have worked on does not generate a result I can measure, I consider that I have failed and I need to either abandon the project or continue work until it is done. When a project is finished, when I can check it off as done, I become ecstatically happy. I feel like a huge weight has lifted off me and I am free to move on to whatever else I feel like. When you become proficient at completing projects, and adept at meeting the well-defined success criteria you have laid out, I can guarantee you will find that same powerful, motivating feeling. The thrill of completion, the knowledge of a job well done, the closure on a project that frees you up to work on the next novel idea.

During the planning, development and production of your project you will face several major problems that you won't necessarily think of as problems. Learning to recognise what you might think of as a good thing as an actual problem will help you steer your project to completion.

Details matter throughout the lifetime of the entire project. Details matter on the implementation stage, the production, not the planning stage, the development. Too many details in the plan means that the plan is inflexible and cannot adapt to changing needs. Details in the implementation permit you to make the project fulfil all of the success criteria. Details matter more than you possibly realise because through the details we gain the satisfaction that the project is complete and does not need to be changed or fixed or tinkered with any more than it has been. When putting up shelves, you don't put up only half the shelf and leave one screw out, so the shelf doesn't do what the project set out for it to do, and you have to return to the project at some point to fix the details. You don't put up a shelf that is crooked, or at least, you try not to, because that is a detail of implementation. But when you put up shelves, you may decide that they would look best on one particular wall, "oh, about by here looks good", you may decide, if you have several shelves to put, how to arrange them, "I like the staircase effect," but drawing up a detailed plan, "the first shelf will be precisely 4.75 metres from this wall and at a height of 1.8 metres from the ground, with an offset of precisely 63 centimetres and an inclination of zero degrees and a declination of zero degrees." Argghh! Too many plan details. You only want those kinds of planning details if you consider the person putting up the shelves is a complete imbecile or they are assembling IKEA furniture.

Be concerned at every step of the project implementation with the details. Become as detail oriented as you possibly can be. The details are what elevate a project to greatness and the project becomes a thing of accomplishment. But avoid too many details in your actual plan because they won't survive and you will bog down in planning for things that may never happen.

Drawing up your first plan should be a simple task and not take more than ten minutes to perform. I would recommend you spend no more than ten minutes on each of the first half-dozen plans you make. A plan that takes more than ten minutes to write out, if these are your first plans, are probably too big for you to execute fully on or the plan most likely contains a lot of extraneous implementation details.

Your first plan should be simple. This goes for all plans but as a project grows in complexity and requires more resources, which each detail of the plan should remain simple, understanding the entire plan won't be as the dependencies of each area grow and become coupled. Your first plans should be simple enough to hold entirely in your head, though of course, you are writing down your plan anyway, right?

Once you have your plan, go over each part of the plan and run it through a simple checklist:

1. Does this step, detail or feature support the success criteria? If it doesn't, cut it.
2. Is this step, detail or feature actionable? If it isn't, cut it.
3. Is this step, detail or feature reliant on external influences beyond my control? if it is, cut it.
4. Does this step, detail or feature rely on resources I don't have? If it does, cut it.

Once you have cut as much as you can from your plan, go back to the top and do it again. Two passes of cutting is the bare minimum you want to shoot for. When I draw up a plan and I think that each and every feature of my project is essential, if I cannot find anything to cut out, I put the plan to one side, I walk away from it, either physically or mentally, and do whatever else I want to do for as long as I like. When I come back to the plan I always find a few things that aren't that necessary to the success of the project.

Almost all details in a plan are controlled by external influences to one degree or another. A specific detail that relies on the sun coming up tomorrow and the world continuing on as normal is a reasonably concrete detail. A specific detail that relies on you finding an hour sometime in the next 30 days to work on it is also quite a concrete detail that has a high probability of being executed. A detail that relies on finding an artist to work for free for two weeks straight, and you need to have them start work by not later than Monday of next week, is a detail that you should be very critical of. There is a fairly good chance that part of the plan won't be able to execute within the time frame desired, if at all. Put as realistic an estimate of difficulty, likelihood of the resource being available, and successful execution of the detail on any parts of the plan that you cannot directly control or don't rely on stable foundations. At all times, be away about details that are controlled by external influences that are based on projections, wild guesses, and non-reliable or over-committed resources.

Let's talk about deadlines. We've all had one. we've all met one. We've all blown one. An assignment handed in early or late, an appointment we needed to make and only just squeaked in by the skin of our teeth. The joke is that deadlines make whooshing sounds as they go by. When you set deadlines, and you must if you want an effective project plan, you will need them to be as accurate as they possibly can be. For putting an estimate of time and a deadline on a big hairy problem you don't fully understand, you need to analyse the problem, research issues, and then make wild arse guesstimates about how long something you've never done before will actually take. That is your deadline. And most likely, if you aren't experienced with making good deadlines, you will blow it. And you should accept that. You have to be firm with yourself, the deadline was missed. And there is a reason behind that, missing a deadline is a learning experience. Every time you miss a deadline, analyse in note form why the deadline was missed. "Artist quit on us" or "Programmer wasn't able to solve the problem" or "too many tasks to do in the available time." By performing this analysis and figuring out what went wrong to cause the deadline to be missed you will actually become better at estimating the amount of work involved in a particular part of the project plan, and how to find areas in your plan where deadlines are relying on resources of details that are controlled by external influences. As you make more estimates, and set more deadlines in your plans, and you meet them or break the, your skill in that area will improve tremendously.

Even the most generous deadline can get away from you very easily. The deadline was too far in the future for you to make a strong plan to meet it, the deadline relied on resources or details that were controlled by external influences, the deadline was predicated on committing resources you don't have , e.g. three full-time artists when you have one part-time hobbyist. All of these factors of why deadlines get broken can be avoided by practicing the setting of, and meeting, or at least attempting to meet, deadlines and learning from each deadline what went wrong or right.

When you miss a particular deadline be aware that it will change your plan from that point forward. A broken deadline doesn't mean that just that deadline is affected, it means that all other deadlines in the future are also changed.

When you miss a deadline, no matter how hard you try, you won't make up the time. You cannot put extra resources on the problem, you cannot divide up the tasks to bring down the amount of time required, you cannot work smarter instead of harder, you cannot even work harder. I have seen way too many teams attempt to "make up the time" on a missed deadline only to burn themselves out and start to miss other deadlines because of it. Now, all that said, it is possible to make up small increments of time but not enough that it will affect the overall project. From personal experience I rarely make back 20% of lost time by committing extra resources at a late part of the production that we didn't not plan on committing during the development phase of the project.

How do you get better at programming?

Every day you practice. You learn new algorithms. You read books by master programmers. You stretch yourself with new logic problems and new technologies.

You define the project. You define success criteria. You make a plan of small achievable daily goals. You act on the plan. You commit to deliver.

Just like a piece of code in a program that doesn't execute is the least costly to execute, a feature that doesn't get implemented is the least costly to implement. If you can cut something to make up time, do so. If you cannot make a deadline because of a feature, work strongly towards cutting the feature. This act may have an influence on future work to be done, on other areas of your plan, but if you can cut, cut. Cut often. Cut early. Go! Go be an emo project pruner!

When you complete a part of your plan ahead of schedule, don't move up the other deadlines. Deadlines only move forward, never backward. I've seen bad managers time and again bring a deadline forward because some other part of the plan was completed well before it was supposed to be only to have the movement of the deadline impact other areas of the plan unexpectedly. Moving anything in a plan without thinking about what it is connected to, and what dependencies it has means actually spending time reworking the plan, and educating everyone working on the plan, about the changed deadlines and priorities. Also, in any plan with enough moving parts and sufficient complexity, something else will run late, it always invariably does, and then your iconic bad manager will be complaining that the new deadlines are all being missed.

Many times I see people trying to make huge plans in their first few attempts. Your first plans should be small, simple, clear, and actionable. Don't be afraid or embarrassed to make very small plans the first few times. I make small plans for side projects several times a week. How small is a small plan? Here's an example: Draw up a plan to answer one interesting question on the Unity forums as clearly as I can. It is not all that silly to plan that out, try it, you might be surprised by the steps involved. Here's my attempt at it:

Project Statement: "Create a post that provides long lasting value to one member of the Unity forums."

1. Monitor Unity forums on a daily basis for interesting and engaging questions that is non-trivial.
2. Draft up a non-code answer to the best of my abilities within two days of the question appearing.
3. Perform all necessary research on what will be required to solve the problem within one day.
4. Create a sample project in Unity that solves the problem within two days.
5. Post working sample project and sample code on Unity forums within five days of the question being asked.
6. Follow-up with original poster within two weeks of my posting to see how they are getting on.

This is a small plan. It's clear. There's no "magic happens here" step. It fits within my skill set, within my abilities, within my resources available, it is actionable, it has little reliance on uncontrollable external influences other than the fact someone may not post a non-trivial question that I find interesting. This is a reasonably strong, but incredibly simple, plan. I have been using this very plan for the past five or six weeks to provide answers to various forum members that post questions. I generally manage about one or two answers per week.

I mentioned that each detail in the plan is actionable. What I mean by that is I can take action in discrete steps that move the plan forward. I always find the best way to keep a plan executing is to make each step executable. Lots of verbs at the start of each detail in the plan let me focus on what I should be doing for that part of the plan.

I've got thirty years of planning experience, leading teams, delivering products. Some days I seem to be flying by the seat of my pants and not working to any kind of plan but I always know where I am going because I have that thirty years of planning experience. Some days, I flounder. There is no direction, no idea of what to do next, no plan. That's when I have to step back and start drawing up plans for the day or the week that just focus on that period of time rather than the bigger project. And I also make plans for small side projects, a list of "to do" tasks down one side of the white board that need to happen in a particular order that are concerned only with one particular project, e.g. setting up the backup on the server. By making those small plans I keep my plan making skills sharp, but by making those small plans, other people can see me making plans and will make begin to make their own plans for their part of the project too. No matter how experienced I get, I still make small plans. Don't be afraid to make small plans even when you have lots of experience.

The fastest way to get better at making plans is to make a plans. Make a first and simple plan, then throw it away and do another one. When I teach these kinds of skills in class, I have the students draw up a plan for something simple they are already familiar with, such as graduating class, and then I have them put the written plan away, and do it again about twenty minutes later without referring to their first plan. Very few of them write the exact same plan out the second time because they have thought about the problem some more, have considered the best approach, and also considered what could go wrong. Their second iteration of the same plan often loses steps they considered essential in the first version.

Your first few plans will be utterly unfeasible. Like it or not, you have to actually create quite a few plans to be able to get the experience necessary to create better plans. If your first several projects are grand productions and you have no experience at planning, any plan you come up with will by default be flawed, insufficient and incapable of supporting the needs of the project. If you realise that your plan making skills when starting out are poor and that you need to improve them, you will be more accepting of changing the plan to fit the project and of throwing out what you perceive as a good plan.

How do you get better at cooking?

Every day you practice. You expand your repertoire of recipes. You try out new ingredients. You stretch yourself with new cuisines, and you set small achievable goals.

You define the project. You define success criteria. You make a plan of small achievable daily goals. You act on the plan. You commit to deliver.

Until you start actually executing your plans you won't have the knowledge necessary to understand what should be in the plan, and what parts of a plan are unworkable. The subject of what to look for in a plan that would raise red flags is unfortunately very deep so it is difficult to give general pointers on what to look for that would cause issues during production.

Generally you want to be aware of "aggressive schedules" and "aggressive deadlines." In fact ,if you ever hear someone say "we have an aggressive schedule" you should start paying attention to everything as "aggressive" anything means that resources have been over-committed there have been issues, either creatively or technically or personnel, that have either burnt through a lot of time before being completed or caused problems in other areas of the project.

Another area to watch out for in any plan is "hand waving." Most of us have seen the "1. Think up big idea, 2. Hire team 3. ???? (magic happens here) 4. Profit!!!" form of joke usually perpetuated by starry eyed entrepreneurs and their overfunded start-ups, but that step 3 in any plan is a huge red flag that you want to pay particular attention to. Any step of the plan that cannot be adequately explained to a six year old in clear and concise terms without resorting to "because I said so" or "I think it'll be okay" should be carefully reviewed and fixed at the earliest opportunity.

Starting any new projects is an exciting time. The big idea, the planning, the neat stuff you will do, the places you will go, the people you'll get to see. There may even be dollar signs dancing in your head of how much the project, if you ship it, will actually make for you. We all rush off with pen and paper in hand, eager to create the next big thing, or even the next small thing that just scratches a mental itch for us. We learn a few new skills and tricks, we have a half-baked idea of what we're doing, and time marches on, and reality begins to set in, and pretty soon, we're losing motivation, the project is floundering, the daily grind of drudge work to get all the details straight and the project polished to a bright shine drains us of energy just to even think about it. We lose focus, we start thinking about other cool projects we could be working on, our mind is fizzing over with new ideas for other neat things we could be doing. And then we wake up, one day, two years from now and regret we never finished that project that was so exciting to us at the time, because today on the App Store was a fantastic little game where you throw irate birds at criminally minded pigs. Damnit we had that idea! That was our idea! They stole our idea! We could have been a contender!

This constant danger of the new and the novel is why I advocate small plans and sticking with them through to the end until you are really strong at making and following plans. I cannot stop my mind from wandering off and thinking about shiny new ideas to create, and I wouldn't want to, but I can temper that desire to move to the next thing by realising that the plan I am currently working through today is what will bear fruit tomorrow, rather than the half-baked execution of a new novelty idea that I also most likely won't finish because something else will have come along and distracted me.

Treat everything you do as a project. Every day attempt and complete one small project. Draw up a stated goal, draw up a realistic plan, limit the scope, set a deadline of when to start and a deadline of when to finish. If your small project has not been started after one week there is only one thing you should do: Throw it all away!

Throw out the plan, because by the time you get to work on the project your subconscious mind will have thought it over without you being involved and thrown in a few new twists, the world will have changed and the plan will no longer match up with what you thought needed to be done. If you were making a clone of Angry Birds two years before Angry Birds came out, your idea of what the game should be back then would be vastly different than what your idea of the game should be today.

Throw out the goal, because the direction you want to move in is no longer available to you. Goals are great, ,make a new small goal every day to stop yourself getting in a rut. But don't cling to your short-term goals because you will change from day to day, so will the world around you, and what you wanted yesterday is no longer relevant today, and what you want today, is no longer relevant tomorrow. Long-term goals survive because they are just that - long term. Short-term goals shouldn't be allowed to accumulate and fester because they will simply distract you from your long-term ones and crowd out other short-term goals and opportunities.

Feel free to make notes about your small projects, draw up a list of what you were thinking of doing as you may want to return to it at a later time, but once you have those notes written up and safely saved, forget about the short-term project if you haven't achieved it in a week. Move on. Your project was still-born and you are never coming back to it except in moments of regret.

Every day I visit the Unity forums I see the same mistakes about completing a project being made over and over again by people just starting out and also by experienced, grizzled veterans.

The primary mistake I see is that their projects are too big.

Projects that take weeks or months or even years to execute never get finished because the person becomes unfocused, they lose all motivation, and they usually do not have the skills, techniques and tools in their toolbox to get the project back on track. You cannot get better at completing projects if you only ever work on one huge project. You cannot get better because until you complete that one huge project, you haven't completed any projects.

"Ahah!" you say, "That is where you are wrong! I have several projects on the go! I have my zombie fantasy MMOFPSRPG that is my long-term project that is going to be a huge success and I have my fantasy zombie MMORPGFPS which is much smaller and only requires half the resources! I am working on them in parallel!"

And to that I say, "No, you're not. You're just mucking around until you get bored of both of them." You can have multiple projects on the go, but if you want to successfully complete projects, you need to pick small ones, one at a time, and get them done, in series, not in parallel. This text you are reading is a project of mine. By the time I am done writing and editing I will have about 20 hours invested in this document. That's a reasonably good project length to pick for your first dozen or more projects. Two days of solid full-time work, or about one week part-time, would be the absolute outside length of projects I would recommend you attempt to complete if you are not being pushed by strong external motivators in a structured environment, e.g. your boss and your salary, and have no experience of completing projects on your own cognizance. Two days is about the time it takes most people to lose interest in their pet projects unless they are especially disciplined, in which case they can usually manage a few months before becoming bored of all the repetitive detail work. Pick small projects that are achievable, that you can complete, and do those until you are incredibly good at completing projects.

How do you get better at martial arts?

Every day you practice. You learn new moves. You exercise unused muscles. You stretch yourself with new techniques, new opponents, and you set small achievable goals.

You define the project. You define success criteria. You make a plan of small achievable daily goals. You act on the plan. You commit to deliver.

Many recent small projects I pick to work on, and complete, come from ideas and questions on the Unity forums. If you've read any of my posts, you think "Hey! Justin is spouting off on his soap box again! This should be good for a troll post." but actually, those posts, they're small projects in an on-going series of small projects.

Tiny little projects.

Done to completion.

Want to see some of those projects?

Here they are:
http://forum.unity3d.com/threads/113843-Carving-effect-challenge
http://forum.unity3d.com/threads/113686-Idea!-Build-Unity-Answers-Into-the-IDE!
http://forum.unity3d.com/threads/113953-If-(transform.position.x-lt-int)-does-not-apply.
http://forum.unity3d.com/threads/113749-Is-the-publicity-side-of-app-development-really-this-sleazy
http://forum.unity3d.com/threads/113324-Zombie-Zeppelin-Defense-My-Saturday-afternoon-distraction
http://forum.unity3d.com/threads/112998-can-somebody-explain-this-in-more-detail
http://forum.unity3d.com/threads/103967-How-to-earn-£12-000-in-one-year-from-game-development
http://forum.unity3d.com/threads/111168-Using-For-to-instantiate-blocks
http://forum.unity3d.com/threads/11...t-have-corresponding-physical-object-in-world
http://forum.unity3d.com/threads/110190-Choosing-a-player

There are many more posts like those here on the Unity forums. Combine all my worthwhile posts on these forums together and you have tens of thousands of words. That's not a bad project to have completed. Each post is a project. I watch the Unity forums all day for an interesting post of someone trying to tackle a manageably small problem, and then my goal is to solve it.

Or troll them.

It depends on the original post. Sometimes I get the two confused. Oh how we laugh at those posts! Eh-heh...

Completing projects is trivially easy once you understand how to complete projects. I don't believe anybody is born understanding how to do complete projects and only that -- but if they are, they generally make excellent middle managers -- but the skills are easily learned and the principles terrifically effortless and uncomplicated to apply.

How do you get better at completing more projects?

Every day you... but I think you already know the answer to that one.

 

[Wall Of Text] delivers a crushing blow to [ForumThread] for 87,000 HP.