Simplicity–the art of maximizing the amount of work not done–is essential.

One of the often overlooked issues with software development projects is the hidden cost of what I call the “nice to have”. You know what I’m talking about, it’s that little feature you want added to a software product because you think it’s cool but no one ever uses it. Or, maybe what you thought you wanted three months ago is not what you want now. That brings me to a question: How much did you pay for those features that you don’t use or need?

The truth is that most software projects spend far more effort on things they don’t really need than you would think.  But, there is a very simple way to avoid most of this extra work and reduce the overall scope and cost of a project.  But, it means you have to give up something.  You have to give up the notion that your 100% complete and fully predictable project schedule is actually correct.

Here’s what you do.  First, put all of the requirements and features you think you want in the project into a collection system of some kind.  If this is your first time building this kind of list I suggest you use 3X5 index cards and stay away from a computer screen.  Write the requirement on the front of the card and put the name of the person that fully understands that requirement on the back.  As you brainstorm for a while and come up with a bunch of cards for the system requirements you should start to organize them.  I like to do three things for organization.  First, I label them with T-Shirt sizes.  Some cards are Small, some are Large, some are 2XL or 3XL.  This is a rough guess of the scope of each requirement and how long it will take and how hard it will be to implement.  I like to put this in the upper right corner of the card.  Second, I label the card with the kind of person that will use that feature.  I like to put this in the upper right corner of the card.  Lastly, I put an indicator on the card to say how critical that requirement is to success of the project.  For this one I put #1 if the product is useless without that feature.  I put #2 if the requirement is a primary feature. And, I put #3 if it is possible that I could ship the product and get customers to buy it without that feature.

Once you have your requirements you can sort them.  This is one of the reasons I like index cards; they are easy to sort by just laying them out on a table.  To sort them, you pick up two cards and ask “If the product could only have one of these two features, which one would be better for the product?”  As you keep doing this, lay the cards down in the order you determine.

Once you have sorted all the cards, you now have a Product Backlog.  This is a backlog of features you need for the project and they are sorted into a “must have” order.  So, you just pick a small set of cards.  I suggest that you pick one card for each developer on the team to start.  Now, here’s the magic: tell the development team to implement the one feature and ship the product as if the project was over.  This causes the team to exercise the full development pipeline from analysis to design to development to test to delivery with a really small set of requirements.

When they finish building you a working software product that is almost useless because it has such a minimal feature set, make the give you a demonstration of what they have built so far.  When product managers see the working software, suddenly the understanding of what the software could do changes in their minds and all those priorities you wrote on the cards change.  So, you go back to the remaining cards and throw out the ones that don’t make sense anymore, add new ones that you have thought of after the demonstration, and repeat the process.  Every card you throw out is money you saved.  Every priority you change is cost you avoided.  Every new card you add is an innovation that you could have missed if you were not paying close attention.

Having the development team work on a very small set of requirements then demonstrating the result to you ensures that you know the project status.  Adjusting the cards before each new round ensures that the team is actually focused on business value instead of building what you thought you wanted when you didn’t understand the implications.  The net result is that you avoid a significant amount of expense in building and maintaining software features that don’t really fit your needs.