|
A lot of people never finish most of the
projects they start. "Finishing a project is the hardest thing"
-Secrets of the Sages. The problem can occur at any point and for
any reason. For example, my biggest problem is learning something new
and jumping right into starting a project for an idea that popped in my
head. Well, let me tell you, serious psychological problems as well as
bad habits can occur. Not finishing a project is one of my worst bad habits
and in return, it has weighed heavy on my mind. Depending on the person,
depression can occur. You might take these statements lightly, but you
can ask any of my coworkers and my wife.
Most
projects are just something to entertain me at the time. If I had taken
the time to properly plan out my ideas into working projects before just
hacking code, I would have
- Figured I'd be
wasting my time and would not even bother to start as I already knew
I would lose interest, or something else would keep me from finishing
- I would finish
the plan and I would have a nice road map to complete the project.
This
is the point of this article right now. Learning to manage projects and
keep your peace of mind. Let's take a look at the overall process of planning
your ideas into projects
- Idea stage
- Thinking
stage
- Preplanning
stage
- Planning
stage
Now
these stages are just a quick overview of the process. Let's get into
some details of each stage.
Your
Idea
OK, so now you have an idea. Ideas are really
fun and great. They get you all excited because you have something new
to try out and learn from. Something to show your friends. I know this
feeling all to well. It's a rare day I don't read about a new language
or about how to do something new in a language I already know, or get
an idea for a new program that I could market, etc. Does this sound familiar?
Well, today, I started learning about the benefit's of XML. And since
I've been working with Perl the last few days, I had another idea pop
into my head. I want to build a piece of software that I can market using
Perl and XML. Now, as always, I have the idea and I say to myself, wow!
This will be so easy! So I just jump right into it. After a little while,
I see all these things that get in my way and it puts a stop on the project.
Had I taken the time to plan it out, I would have seen these things. Luckily,
this time I am taking it slow.
Getting
yourself organized is the first step. Another serious problem that plagues
me, is that I have ideas everyday and they all generate the same response.
Since not a good idea to work on 50 projects all at once, if you cant
even finish one, go buy yourself a journal, notebook, palm pilot, or if
your a poor starving coder, then use notepad! Anything that works for
you is fine. Make an idea chart. Each time you get an idea, write it down.
Not only will this allow you to focus on your current project, but it
will keep your from forgetting about them later, and most important, it
will help you weed out projects that you would normally not finish due
to it being one of those, "Keep me entertained at the time"
projects. Very important.
Thinking
stage
This stage is a must. The reason why is
because in this stage, you will be defining what your project is. You
must define a clear definition of your goal. What will your project be
at the finish line? What is the purpose of your project. Before brain
storming about all of the ideas you want in your project, you must clearly
define this information.
Once
you have a clear definition, you can start your brain storm session. Be
sure to use your notebook (or start a new text file) to write all of these
ideas down so you do not forget them when it comes time for planning.
When you are logging these "bells and whistles" that you want
to feature, include details and any specific information you have in your
mind. You might think, "I will remember what I meant when I see what
I wrote down", but I cant count how many times I have said that to
myself only to come back anywhere from a week to 6 months later only to
find that I have scribbles that are very cryptic to me. Someone else may
as well have written them.
During
this thinking stage, you will want to get opinions and comments from other
people and write them all down. Remember, this is just a thinking stage.
Getting a lot of information now can help more than not having enough
later on.
Preplanning
If you are still interested in your project
at this point, then finishing this stage is our next goal. Preplanning
goes like this, you take all of the notes and scribbles and comments and
suggestions and you sort them out. This is where you make sense of all
the data you have acquired. You must weed out bad ideas and keep the good
ones. Use the suggestions and comments to build, modify and improve your
ideas and form them into solid, legitimate additions to your project.
A lot of people would include features that are useless in the end, but
look good now. Time wasters are what they really are. Now with the ideas
you have left from that mess, you must determine how each idea will fit
into your project. If it don't fit, put it a side. You can always add
it in the next version.
OK,
now we are at a critical point in our process. Here, you need to decide
if you should repeat the "Thinking stage", or if you should
continue on to planning. Now before we get into planning, you will need
to understand some guidelines. Any new ideas that arise will complicate
and potentially ruin your plan. So, if at any point from here on, you
get new ideas, write them down like you did before. But this time, you
will have a different agenda for them. These ideas will go into your next
version, or will be added only after you have finished your original plan.
If you think that they are too good to pass up, go back to the thinking
stage.
Planning
Our last stage is by far the most important.
During this time, we will design and layout our project road map. From
this map, we will start and finish our project. Now, this stage in it's
self has many sub stages that must be followed.
- Putting
the puzzle together with a design document
-Defining your resources
-Defining sections / goals
- Starting
at the start
Now
we have an overview of our planning stage. Let's get started!
Putting the puzzle
together
After our preplanning stage, you should
have everything that will be in your project. You will need a new piece
of paper (of a new text file) because you are going to create a design
document. If you have ever been involved in a big project, or have read
about them, you will know that the design documents are the "bible"
and will be the highlighted path to your destination.
Creating your design
document
A design document is the key to your project.
It holds the outlines of everything that goes into your project. From
the user interface to the push of the 'OK' button. Lets take a look at
what should be in your design document
- The purpose
of your project
- A clear
definition of what the end result will be
- Defining
the 'tools' to be used
- Drawings/Sketches/Renderings
(User interface, menu's, splash screen's, models, etc.)
- Feature
placement and function
- Defining
people who are involved and their duties/responsibilities
- A breakdown
distributed resources
We
have defined the purpose and the end result in the preplanning stage and
should not be difficult to add to the design document. Defining the 'tools'
you are going to be using is another easy one. Let's take a game as an
example. If you were to be building a game, you would surely want to define
what API you were going to use (OpenGL, DirectX, Software blitting, etc.).
If using 3D models, you will need to define the file type and software
used to create these models, otherwise, define the sprite file type and
format's. Sound, input, distribution, and many other things will need
to be defined. Since it's a compiled game, you will want everyone working
with the same compiler. As we all know, Borland and MS don't mix very
well.
Drawing
and sketches (if applicable) will help to give a visual aid to you and
everyone in your project. Even if you have a clear vision in your head,
it will be distorted by the end and it can cause serious side effects.
Put it in ink and leave it alone. If you feel you have to tweak on it,
leave it be until you are done. I cant stress this enough, wait until
you finish until you make changes. If you feel that the changes are necessary
now and can not wait until after your project is finished, then you will
need to go back to the thinking stage. This is OK since you have not started
on any work at this point. You might lose a little time, but it will be
worth it in the end.
Feature
placement and function goes along with the drawings/sketches if applicable,
otherwise, describe how they will fit in to your project, what their purpose
is and how they will function.
If
you have other people involved in your project, then you will surely want
to spend time on your resource section. It will be an outline for everyone
and what their jobs are. To maximize your time, you will want everyone
to have a job all of the time. To go even further, you will want to add
'odd jobs' that anyone can work on if they complete an objective and have
some free time, even if it's sweeping the floor (considering everyone
is all together and not spread out over the Internet). Define a project
leader. Who ever that individual is, should be responsible, since it will
be their failure should the project fail. If you are not willing to take
responsability for failure, dont be the leader!
Defining
your resources, if any at all, includes time, money, workers and materials
(depending on the job). Step back from your project and look over your
objectives and everything involved so far. If you are paying people to
work on the project, then you have to define a budget, and with a budget
comes a time frame. Let's define a scenario
- 5 workers
@ $10.00/hr each
- $50,000
- No time
frame
- Software
application for database interaction
OK,
so this is our 'box' that we must work in. A good thing is that there
is no time frame, so you can mess around all you like. Your budget is
$50,000 and there is nothing to buy since everyone has their own workstation,
and all the tools they will need. But, you are employing people to code
software and they work 8 hours a day, 5 days a week. All 5 employee's
are being paid equally @ $10.00 /hr. This means that every month, $8000
comes out of the budget.
((10*40)*4)*5
= $8000
((Hourly rate * Hours per week) * weeks per month) * Number of workers
= Total monthly cost in worker pay only
All
of the sudden, there is a time limit on the project! Since the budget
is $50,000, the time limit is approximately 6 months. You better get started!
Define a time limit for each section of your project and stick to it.
If you have to work for free on the weekends, then you had better do it.
By
now, you should have a pretty good design document. I haven't covered
everything, but creating docs over and over again, you will learn more
and more what you must include for everything to run smoothly. We talked
about setting time limits for each section. Let's take a look at defining
sections and goals.
Defining sections
and goals
Since you cant do everything at once, you must do small sections over
time. This is a tough job, but it is critical. You have to take your project
as a whole and break it into little, manageable pieces. Let's go back
to our software project we defined in the example above. If only one person
were to be working on this project, the sections might be broken down
as such
- Create
user interface 1/2 month
- Create graphics
- Create the menu's
- Layout objects (button's, etc.)
- Code the
menu items 1/2 month
- Code objects
(button's, etc.) 1 month
- Code the
database wrapper DLL 2 months
- Connect, Close, Add, Search, Delete, Edit
- Code the
features 1 month
- Test /
debug / fix 1 month
This
is a small simple break down but it should get the point across. By following
your break down, and finishing each piece individually, you will have
your project finished in no time. It will also help to keep your attitude
on the positive side because you can look back and see what progress you
have made. Attacking the project as a whole with no direction can hurt
the moral when you look back after 6 months of hard labor and you have
nothing finished to look at.
Starting at the
start
Isn't it so fun to get right in and start
hacking away at your project? Yes it is. I love just jumping in and start
writing code with no direction at all. But, after reading this article,
I'm sure you will want to start where you should, and that's at the beginning.
Planning is key to your success. Think about war. If you had an army,
would you have a better chance of taking over a country if you had a plan,
or if you just sent all of your troops in blazing at random? That's my
point. Designing the layout of your database isn't fun, it's boring and
mundane, but it must be done before you start writing code.
I
hope this article has helped at least one of you. It has helped me in
many ways. Look for more articles from me @ Programmers-Unlimited.com
|
By 9 Users
12/2/2003 6:50:57 PM: 
