Project Management - you can't go into many directions at the same time

One of the most important things in managing your project is to have a clear vision on what is it you want to deliver. Of course we all want to deliver maximum features with very low defect ratios, within 6 months time frame. I have news for you this is usually not possible. Those are interdependent and usually investing in one of the constraints costs you neglecting another. You will be making priority decisions throughout the project, so why not to get clear on what are them at the beginning. That would also give your team a clarity on what is important to the project and how to act when they would have to make priority decision themselves. So keep everybody in sync by providing priorities in advance.

As it always come to comparing two (sometimes more) project characteristics when you are supposed to make a decision I would recommend to write down an order of priority list which has the most important characteristic on top and then descend to less important characteristics.

So for example if you are targeting visionaries with new innovative project you know that you have to generate a specific minimal features set, release it as soon as possible, and think about quality later. You can reflect it in your list. That means that if your defect levels are high but you still don't have complete feature set you will devote your time to implementing features and not improving quality. Second important thing is to define what are the must-haves from the list - things which have to be accomplished for the project to be successful.

Now, make sure you are on the same page with your sponsors and potential customers as otherwise you are heading for disaster. You must be sure that list reflects priorities of people who fund the project. Talk to the sponsors and get them to choose what's the most important by simply asking them. If they don't want to choose as they want 'perfect quality, full feature set, 6 months, 4 people team' ask questions which will mimic decision you will have to make: "let's say it's a month and we still don't have full feature set and quality is low, shall we focus on quality or on features? Or maybe delay the release?". Do whatever you can to get it out from your sponsor. If you can't make the decision yourself (in advance) and get sponsor to agree, sign off on it. Without that project will be dead on arrival - overconstrained projects rarely are harder to deliver they usually are impossible to deliver. Unless you are Chuck Norris of course.

How to develop software faster

Nice article on how to develop software faster: here

Software Defect Reduction Top 10 List

I've just found interesting article on statistics behind defect reduction by Barry Boehm and Victor Basili: here.

According to the article top ten defect reduction list is the following (I'm citing the article):

1. Finding and fixing a software problem
   after delivery is often 100 times more
   expensive than finding and fixing it during
   the requirements and design phase.


2. Current software projects spend about
   40 to 50 percent of their effort on avoidable
   rework.


3. About 80 percent of avoidable rework
   comes from 20 percent of the defects.


4. About 80 percent of the defects come
   from 20 percent of the modules, and
   about half the modules are defect free.


5. About 90 percent of the downtime
   comes from, at most, 10 percent of the
   defects.


6. Peer reviews catch 60 percent of the
   defects.


7. Perspective-based reviews catch 35
   percent more defects than nondirected
   reviews.


8. Disciplined personal practices can
   reduce defect introduction rates by up to
   75 percent.


9. All other things being equal, it costs 50
   percent more per source instruction to
   develop high-dependability software
   products than to develop low-dependability
   software products. However, the
   investment is more than worth it if the
   project involves significant operations
   and maintenance costs.


10. About 40 to 50 percent of user programs
    contain nontrivial defects.

Software Economics

I found interesting entry on stackoverflow.com which lists resources for Software Economics (not only Barry Boehm book).

Check it out: Economics of Software Development