Planning Software projects Part 1

Planning Software projects Part 1

Good planning is critical to delivering software. Anyone who has shipped a product knows that the plans we start with rarely survive the entire release process intact. Too many of the plans we start with are useless by the time we ship our software. Ideally our plans would serve us better through the entire process. Here are some lessons about planning I have learned that should help you spend you planning time better.

Good business starts with a vision

A clear vision will do more to help you ship software that delights your customers than any other planning you do. This is very important so I will repeat it. You must have a clear vision and communicate it clearly to your team. Teams who can’t do this have no way to live up to their potential. Your vision must unify your marketing goals with your engineering goals and it must be realistic and achievable.

Good products flow from a vision. You can have the most technically sophisticated components known to man, but without a unifying vision they are doomed. This part of your planning is really, really important. If you neglect it, I promise you will cause suffering and randomization in your team about midway through the cycle!

Define one or two primary pillars and two or three secondary pillars.

The pillars of your product should be a rough guide to where you will spend your time downstream. One approach to software pillars is to imagine each attribute your software can have is a dial from one to ten. You can set each dial at a number and then arrive at the probably amount of time it will take to achieve your vision. The trick is that you have a limited budget. Most projects can only survive having one or two pillars be set to “10” and two or three more set above “5”.

How can you decide what pillars are important? Talk to your customers. Find out what they really want. They will want everything, of course. Find a way to make them stack rank what they want, and proceed from there.

Some sample pillars you might work with:

· Feature rich

· Usable

· Robust

· Scalable

· Maintainable

· Testable

· Technically advanced

· Performing

· First to market

A lot of software projects pay lip service to pillars, but fail to really nail down the vision for each one. If you want to create a product that scores a 10 on each one of those scales, you will have to pay the price in time, talent and your resale cost is going to be high to compensate.

The best software projects start from a vision that is specific about what pillars are important, which ones are secondary and which ones are going to be “left for the next version.”

Some pillars are diametrically opposed to others. If you want to score a ten out of ten on “first to market” you can pretty much forget about scoring very high in the other pillars.

Make sure before you start to design features that you know what you want the software to achieve in the market. Make this vision clear and public for the team. Don’t use weasel words in your vision statement. When conflicting priorities present themselves, a clear vision will make for smooth sailing. For example, if a feature is causing the ship date to slip, a clear vision will allow you to quickly decide if you should slip or cut the feature.

Finally it’s important to say what pillars aren’t part of this release. If performance isn’t a primary consideration, say so in the vision. Otherwise you will find your team spending a lot of time trying to performance tune a product that shouldn’t be tuned in this release. You can’t have everything in one release. So prioritize and learn to let go of everything else.

When you vision is clear and clearly communicated, your team is set up to succeed.

If your feature crew are struggling ask if the support systems are in place. Can they get builds and run automated tests at will? If not, no amount of planning is going to help them when they discover something nobody thought of. Is it clear how important the feature is to the project, how well it must work and how fast? If not, you will have resource contention issues that will drain valuable resources from your team.

No plan survives contact with the enemy

I worked on a team that had a pretty good process for creating software. They sketched out some pillars, whipped up some prototypes, tried out the combination and then did some mid course corrections. However, parts of the process could have been optimized. The problem was that the plan on paper didn’t match the plan in reality. So anytime you wanted to change the process you got stuck with the fact that no one was following the “real” plan in the first place.

If your actual process doesn’t follow the script it’s likely the script is flawed. This is probably a very healthy occurrence. Try to capitalize on the evolutionary nature of your organization. It will adapt to overcome challenges. Don’t make a rigid insistence on outdated plans one of those challenges.