About
Subscribe

Is software a benefit or a cost?

Johannesburg, 04 May 2012

Software development is not a low-cost exercise, so its correct price must always be calculated in light of the expected benefit a company will enjoy.

If the benefit is a dramatic improvement in new business or efficiency, for example, then the price is less important than maximising the chance of delivery.

This then moves the focus to making sure the circumstances offer the highest chance of success.

Software development is undertaken by people. People match business needs to a particular design, from the design they build and implement.

The approach taken - in other words, the sequence and focus of each activity that comprises the entire project - has an enormous impact on the final cost and suitability of the solution.

In summary, activities are simple in concept, yet complex in execution.

Therefore, if the approach for building software can accommodate building the right team with the right people when they are available; can implement a daily formula to constantly re-match business needs and system needs; can make small but significant changes in a regular, systemic manner as soon as they are identified; and can increase and decrease the team size according to when the skills are needed rather than trying to constantly increase headcount to accommodate unrealistic or commercially driven deadlines, then the chances of success are very good.

Being friendly, supportive and encouraging is a foreign concept to many captains of industry. Commerce has traditionally leaned towards the aggressive, the fierce, the demanding and the take-no-prisoners personalities. Although these traits have their place, they should not be the characteristics of choice for leaders on complex software projects that rely on smart people.

Smart people have choices and options. But they also want to be successful, and they usually don't like letting people down.

In order to determine whether the cost of software matches the benefit expected by the business, an early estimate and budget must be drawn up by an experienced and senior team. Preferably, a team that is not interested in setting itself up for failure, and represented by senior stakeholders only. This can be done by looking around for similar projects, by considering past experiences, and by consulting with people who have particular knowledge about software in your industry. So don't give responsibility for the budget to the person who will build it, give it to the person who wants it, and the person who will manage it. They can consult with who they like, but they must draw up the budget themselves.

This need not take long.

Once a high-level budget is agreed (don't be frugal, you only delude yourself), the benefit/cost discussion can take place.

Once it is agreed that the benefit far exceeds the cost (it should, as marginal benefits are dangerous drivers in any expensive undertaking), the process then degenerates into building a team, taking constant checkpoints to test the initial budget (throughout the project, always in consultation with the project team), and creating those circumstances to maximise success.

Don't be afraid to firstly reduce the scope, or secondly to increase the budget estimate when it is clear you need more money. These two simple tasks will have the most impact on the actual and perceived success of the project.

So, in summary, don't budget according to what is acceptable to those paying the bills, don't assemble a team in a hurry, don't tell the team how long it should take (ask them to confirm your high-level estimate instead), and don't harass and drive them along a road of unrealistic deadlines. If you do, you will lose your team, miss your deadlines, and probably end up with nothing to show for a lot of effort and cost.

What is more, smart people who have choices often avoid projects that show all the symptoms of unrealistic cost expectations. So then, to make it worse, you start with the wrong people!

And all this does not mean we pander to a sub-standard work ethic.

From day one, the leader of that team is expected to maximise every day: as much as those circumstances will allow.

Share

DVT

DVT provides tailor-made and packaged software solutions and related services to clients throughout South Africa. DVT's practical business offerings include .Net and Java software development, Scrum and Agile teams, Mendix software solutions, enterprise mobile solutions, business analysis, project management, business process analysis, quality assurance and testing, systems integration and data management, integrated Internet solutions, practice management products, contractual resourcing and provisioning and professional services consulting. www.dvt.co.za

Editorial contacts