Starting a new project is always exciting. There’s lots of anticipation and hope for great things to come. There also tends to be a good amount of optimism at the beginning of a project.
Sometimes a bit too much optimism!
Some people tend to get caught up in all these emotions. It seems like nothing can go wrong.
This makes it a very dangerous time.
All the feelings mentioned above tend to cloud thinking and lead people to rush through the early project steps.
This is a huge problem, because the beginning stages of a software project are critical to its long term success.
It’s like laying the foundation of a building; seems boring and slow, but it’s incredibly important to get it right.
As a project progresses, your options become more limited, so the best time to make choices is at the very beginning. The choices you make at the very beginning are usually the hardest to change later.
Here’s an example that shows why software projects work this way.
Imagine you are starting a new software project. There’s a great feature that will make a big difference in your project, but you haven’t thought of yet.
Watch how much more painful it gets as you discover the need for the feature later in the project.
- Imagine you think of the feature while writing your project description. This is pretty easy, you just add another paragraph or so to describe the feature.
- Imagine you think of the feature after putting your project out for bid. Now you have to change your bid request and get programmers to look at it all over again.
- What if you’ve already selected a programmer? Now you have to renegotiate the new feature with your programmer (no bidding, just you and him).
- What if your programmer is already half way through the project? To add the feature, he may have to re-write part of the program to add the new feature, so you’ll pay twice for that part of the program.
- What if the project is finished and already working? Let’s imagine it’s up on the web, working beautifully. Now you have to describe a completely new project to get the change done. Worse, you have to account for upgrading the system, avoiding any data loss during the upgrade, minimizing the downtime on the upgrade, etc.
Bottom line: don’t rush through the planning stages, getting it right the first time is much easier and cheaper.
Word of caution: you also need to avoid the other extreme; analysis paralysis (all thinking and no doing).
That’s all for now, next we’ll look at Mistake #6, which is easy to fall into, and hands control of your project to the wrong person.