Project Management Blog

How to start a project?

Get a reference point.
Whatever it is.

Good chances are that the project is based on an emotional desire. No one wrote a Specification. Some one knows one part of the project, some one else knows another. There's no one 'oracle', no one place which holds the whole information in an ordinated manner. No constant reference point which one can work by, sometimes no one to ask either.

A few years ago I lived in the country side. One night I went out for a run in the fields. The hour was 22:00 and the fields were much vast and dark than I imagined them to be.

Instead of 20 minutes run, I found myself unable to position, running around in circles (probably, I saw nothing). After a while, when I started loosing patience, I decided to stop choosing different directions every time I believe I run in the wrong direction and instead to find a light source and run towards it. 10 minutes later I found my self near the lights of a small village street far from my home. I continued walking down the street and from there hitch hiked home. The whole adventure took something like 90 minutes.

When you get a project, look for reference points.

Start building a model with what you have. A model shouldn't be a specification document but the actual thing (if it's a program, you should actually program it).

Always try to understand the small details, they will hold the keys to understanding the whole system but never try to implement all of them in the model.

Cling to the big reference points.

• What are the main objects of the project?
• What can't the project work without?

Build it up together.
Don't try to cover 100% of the cases.
Build the simplest implementation.

Remember, it is cheaper to build 2 tools which do specific functioning than building 1 which does both. It's much pricy to build or buy a Swiss Knife than a simple set of tools for each function needed.

In databases, many times - it's chipper to do 2 SQL queries with a UNION instead of 1 complex one.

Never try to fulfill all the functionalities of the project with one tool. It's cool and interesting but it might cost you your seat. If two functionalities are ment to be processed by one tool, it will naturally happen in a later phase - when similarities of the two different tools will intrigue you to commit this change specifically.

As you continue in the process of building this model, you will naturally see what's central and what's not. It will be possible for you and for your client to ask the right questions and get the proper answers.

Along the way, keep an open eye on the weak points of the model - write them down, think about them, plan and finally refactor.

This article provided by dorkalev.com.

I always thought that writing a good spec before programming is mandatory.

I like short but frequent discussions where a project spec is being written. I found out that having a spec (Agile, or not) is something mandatory. Ever since I understood I have to demand a spec from the customer, even if I have to sit down with him and write it together (frequently), programming became a much faster and easier task to commit.

It is funny that in our world of 'thinking' people, so many times we don't think and rush to program without a true moment of thinking.

If you know the road, you can reach the target.

If you start programming before having a plan, you might find yourself in a chaotic situation. You spent a lot of time programming stuff that isn't needed at all and now you have 20 waiting tasks with unknown priorities. Chaos. The customer isn't nice anymore, you are frustrated and the project becomes more and more complicated.

In cases where the possibility of getting a good spec is low there's a project management style that has to be considered - the chaotic one.

The Chaotic Project Management

1 In the beginning God created the heaven and the earth.
2 And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters.

Genesis I, 1-2

Bring the customer to your office for a couple of days or go sit with him in his. Define short tasks together and to them with his constant observation. The customer should understand that for this matter you function as his 'hands' and to the actual programming but what will be is what he asks.

Don't think about performance or beauty of code. Don't think about good DB structure, think about getting it done.

This project management style gets results very fast but it is pricey and demands great patience. It should only be used when you know you can't go a step forward in the project because of lousy communication and bad specs.

It should be done only with customers you have intimate relation with and are ready to go into this adventure with the price it demands.

Many clients don't understand what project they wish to have. This project management style is all about getting to know the project. It's about managing something that has yet been formed ("without form and void").

After a while, you'll have a clearer picture of what the project is and so would your customer.

Now will be a good time for both of you to write a good spec and manage this project in a more conservative way.

http://www.bartleby.com/108/01/1.html#S1

This article provided by dorkalev.com.