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.

Today a client of mine emailed me with great news. He is starting to see results from the last 6 months of his marketing efforts. For instance, his sales pipeline is heating up thanks to an educational letter and follow up campaign we worked on—including 2 recently closed deals. He just spoke at an association that serves his target market and landed a client and a lead that way. Plus he is actively getting referrals from his existing customers, which now number about 70.

But 4-5 months ago, things didn’t look so rosey. It is only thanks to a consistent, focused commitment to marketing that he has achieved these results.

While you can see instant results by marketing, it takes time and persistence to build momentum.

Hopefully you have a plan and are sticking to it. Don’t get frustrated. Results come to those who persist.

Some positive thinking guru used to tell the story of a bunch of gold diggers who dug a big hole looking for gold and eventually gave up. Then someone else claimed the land and found a huge supply of gold after digging only one foot more. Keep digging!

This article provided by sitepoint.com.

The last blog post talked about the importance of failure.

There are two mindsets that makes failure acceptable and bearable, and they are non-judgment and non-attachment.

Both of these mindsets mean that you can go all out to get your business going, or to make a sale—but you stay a bit detached. You don’t judge yourself. You don’t take things personally. You don’t wrap your ego up in how things go, and instead drive to the outcome.

If things work out, great! If they don’t, you observe what happened, learn, make adjustments, and try again.

Many people misinterpret non-attachment to mean that one is passive. That’s not the case. You still move forward powerfully and with full intent. You still give it your all. But you don’t add the junk that so many people add—like tying your sense of personal worth to your success or failure.

A friend and business partner and I recently invested lots of money in a business that didn’t quite work out. I mourned it for a while, and then moved on. He is still kicking himself about the result. What’s the point?

There is a Zen story about two monks crossing a river, when they meet a beautiful naked girl. She asks for help crossing the river. The older monk picks her up and crosses the river, while the younger monk looks on in shock (as monks are supposed to be celibate and avoid beautiful naked girls). A mile or so down the river, the younger monk is still in shock, and can’t stop thinking about the older monk’s behavior. The older monk says something like, “I crossed the river with that girl a mile ago and left her there, yet you still carry her.” I think lots of people still carry their burdens of long and not so long ago.

There is a great book called the Inner Game of Tennis by Tim Galloway that everyone should read—tennis player or not. In it, Galloway talks about a Self 1 and a Self 2. Self 1 is our rational, thinking self. It is the self that gets all wrapped up in ego and judgment. It is the self that causes players to talk to themselves on the court, or throw their racket when they miss a shot. Self 2 is the self that actually gets things done, and hits the ball—without thinking, but simply by doing. His approach is about trusting and developing Self 2.

The same applies to business. The more you can let your Self 2, your non-judgmental and non-attached observer and doer, do the job, the happier and more successful you will be.

Another fine book to read is Money and the Meaning of Life—which gets into our attachment to and judgments about money. How we think about money has a lot to do with our enjoyment and ultimate fulfillment and success.

Failure means nothing. Success means nothing. Striving for excellence and fun—that’s everything (and also nothing).

Hopefully this does not come across as too fluffy or mystical. It is a very crucial point, and a hard one to put into practice.

This article provided by sitepoint.com.

A recent post to a blog entry asked about failure and what to do if you have never failed.

I have to confess that I am one of the biggest failures you will ever meet. And that’s a good thing from my point of view.

4 out of 5 businesses or ideas I have fail. (But 1 out of 5 do great; and I’ve learned how to test ideas at low cost).

I’ve failed trying to climb the corporate ladder—at at least four decent-sized companies. And I’ve failed as an employee in a variety of smaller ventures. I’ve been laid off once and fired another time. (But these failures have given me the confidence and desire to go out on my own).

I’ve failed in working with 2 out of 3 business partners. (But the 1 that has worked out has been fabulous!)

One out of 4 clients don’t continue to work with me. (But 3 out of 4 are intensely loyal!)

The vast majority of people who see me speak, read my articles and blogs, receive a direct mail letter, or see an online ad for my programs don’t respond. (But I learn from this and keep testing and improving to increase response).

Get out there and fail! Stop trying to be perfect. Put up a site and keep improving it. Get out there and keep learning and refining your approach. Stop being an A student and start being a B or even C student. Try lots of things and see what works—and then build on that.

In fact, one of the reasons clients come to me is because I have failed so much. I turn that into an advantage: “Mr. Client, I can save you lots of money because I know what DOESN’T WORK as much as I know what does work. Hire me and you’ll avoid making lots of costly mistakes that your competitors make every single day.”

I used to be a perfectionist. I was an all-A student at Harvard. But while that kind of record (which came before grade inflation there) was great for a career in research or academia, it didn’t mean much in the business world. I learned fast that success in business is much different than success in school. It took me a long time to adapt, and get out of the perfectionist trap.

So try things and see what works, and doesn’t work. Learn about the needs of a specific market and solve their problems.

Get out there, try (at low cost), and learn.

Take risks and be ready to fail. When you get good at failing, paradoxically, success will follow.

That’s because you are out there doing something. That can often be enough to take your knowledge to a new level compared to your peers, and then have an insight that brings you great success.

Obviously, you can’t fail 100% of the time forever. You have to keep shifting and adapting, using what you have learned to try new things. Don’t try to fail. But do take risks in which you minimize your downside, learn from your actions, and keep persisting in new and improved directions.

In drilling for oil, you might hit 9 dry wells before you strike the gusher! The same is true in business. You never know if success will come after 1 well, after 10, or—due to the way that statistics can work—after 20.

Just keep drilling! And that means you have to be willing to keep failing.

This article provided by sitepoint.com.

No one can doubt that project management software is a great tool to help PMs save a significant amount of time. However, “the tremendous power of project management software can lull young project manager into a false sense of security” (Heerkens, 2002, p 138). As every other software, applications like MS Project are just tools; they do not execute the entire job for the PMs. It is unacceptable to expect a computer to manage the project, it just manages the vast amount of data that large projects require to store (Verzuh, 2003, p 104). Project management software is incapable of “establishing project objectives, define project tasks or dependencies, determine and manage project constraints” (Richman, 2002, p 93). As the significance of having a proper Statement of Requirement becomes more and more apparent, project management software should consciously take a secondary role in a project system since their power can only be exploited when the project is defined correctly. Computers can only help producing wrong plans faster, instead of helping the PM understand the essence of project management: satisfying the stakeholder’s needs.

Getting paid can be a stressful thing, and can make some web developers/professionals do things that lack judgement.

Here’s an example:

I referred a videographer to a colleague of mine recently, to shoot a commercial for him. The videographer did a good quality job with the shoot.

But then he started demanding payment—after two days after the shoot. Now he won’t finish editing until he is paid.

Meanwhile, the client works with a $100 million corporation known for paying on time. But he can’t pay for 30 days, as is customary.

But the client will never hire the videographer again, because of his approach to collecting his money. And I look like an idiot for referring this guy to him—even though my experience has been more positive.

What should have happened here is:

- The videographer should have specified his payment terms up front as part of a written contract. Part of that contract should have included a clause for 25-50% paid up front before the shoot, Y% immediately after the shoot, and Z% after final delivery.

- The videographer should have been more professional and patient in insisting on payment. Two days is not a big deal. (I suspect that the videographer has been burned before, and so gets a bit paranoid about payment).

If you have had times when you want to react with emotion/fear/anger about payment, please first be sure that you have acted professionally to protect yourself and communicate with your client.

This article provided by sitepoint.com.