Business is for the management, programming is for the programmers, right? Wrong! Many aspects of the business must be understood by the programmer for the success of the project. How can you write a good accounting system if you don’t know a thing about accounting? The days where a programmer simply translated flowcharts into code are long gone. Programmers are now expected to do analysis and design. Many people begin with a list of features or modules, but this is not where the process should begin. The process begins with identifying and describing the business goals. What’s a business goal? Some confuse it with business logic, the part where a 15% tax would add $15 to an invoice of $100, or where all unpaid invoices must be highlighted in red. Business goals are different and reside at a higher level. Here are a few examples of business goals:
- Increase the number of corporate clients by 10% within the next two years.
- Increase the average amount of a shopping cart to $50 in one year.
- Reduce sheet metal wasted by 35% in six months.
- Reduce the time required to create a new invoice to 60 seconds in ten weeks.
How do these goals help develop the software? They guide the decisions, help focus and avoid scope creep and seep.
Every time you are at a crossroads, the decision that brings you closer to these goals is the best decision. For example, should the user type the full product name and price in the invoice, or should the user set up a list of products and then just select them from a drop-down? The second decision seems to bring us closer to reducing the time required for an invoice creation.
Walk towards your goals and try to stay on the path. There can be many distractions: picking the best fonts, aligning elements with pixel-precision, setting up complex deployment processes, designing advanced architectures, etc. These are necessary, but only to some extent, since they can suck a lot of your time for little contribution to the goals. The problem with side-tracking is that you may encounter obstacles that you need to surmount, causing even more unnecessary delays. This is how many projects bust their budgets and deadlines. The goals remind you of what’s truly important.
Avoid scope creep and seep
The difference between the two is that scope creep comes from above – someone adds features for you to implement – while scope seep comes from within – you add features yourself because you feel that they are necessary. Both terms apply when the features are outside of the scope. How do we know the scope? The goals tell us. For example, if you’re trying to reduce the time required to create an invoice, it is unnecessary to create template customization tools. Although it is nice to add a company logo and change invoice colors, it does not get you any closer to the goal. There is an infinite number of features that can be added, but you should remain within your scope.
Stay mindful of your goals. Make sure that the management defines goals rather than features. Features can be rearranged, but the goals are what will decide whether the project is successful or not. I have seen projects for which all the features have been completed, but since the goals were not met, the client was not using the software. It’s like ordering a book about PHP and getting a book about breastfeeding instead. It’s useful for moms, but it won’t help you become a PHP programmer. Print the goals on a poster and hang it in the office. Let it remind the entire team what is it you’re trying to achieve. Help everyone focus on what truly matters. Aim for the success of your project.