“Far too often, the rewards for our efforts seem to be mere pennies as held against the fortune of time and sacrifice spent attempting to earn them.” — Craig D. Lounsbrough.
The abstract nature of software development complicates costing. An idea in a person’s mind is abstract and until the idea is manifested into time and space it basically serves very little purpose. In majority of other fields, the process of bringing an idea to life is tangible and the progress being made can be seen and touched. For software, things are a little different. The ideas are intangible, the process of building is intangible, the progress being made in development is intangible, and the completed software itself is intangible. This is the core pain point for costing knowledge related work.
The word “value” gets mentioned a lot when it comes to costing knowledge work. How do you determine value and define a cost for delivering it? I won’t go into details here.
With software projects, the problem with costing is closely linked to scope and time. Most times the person or company that needs software built only has a very high level understanding of what they want. Yet, they prefer to fix the time and cost components, and leave the scope loose and wild. This is a recipe for disaster.
What tends to happen is that the scope expands as the project progresses and because time (pressure) and cost (more pressure) is fixed it only leads to pain and more pain. I argue that this hastens the failure of a software development project. Committing to costs and timelines too early in the life of a project is the primary culprit. You are usually asked to provide a proposal with timelines and costs perfectly determined and locked in while the scope is left scanty. In addition, you are expected to happily commit to this “time bomb”.
Software is a discovery journey, what that really means is, this is what we think we want but we aren’t 100% sure of it. As things progress and we get to interact with the software we will then truly get to know what we want. This is the nature of software development. It remains true even on your own personal projects. So how do you avoid the costing pain altogether? Here are a few tips that may help:
Determine the most important constraint and link everything to it: Is cost the biggest factor? Is it a certain set of features (scope) that must be built? Or is time the constraint? For example if a certain set of features must be built then clearly define them and directly tie cost to it. More features, higher cost. Make it clear to everyone from day 0.
Don’t commit too early: Only commit when the most important constraint has been clearly defined, documented and agreed to. In larger projects you may have to attach a separate cost, solely for carrying out such analysis to clearly define the most important constraint.
If scope cannot be fixed then link cost to time: If all parties agree that the actual scope isn’t clear and will be discovered along the way then it is best to tie cost to time. Think Agile and getting paid for completing each sprint. That way, scope can grow as much as it can which means more time will be needed and since cost is tied to time it becomes a win-win.
Further Reading
- I’ve wrestled with costing before and I wrote about it here .
- Refer to the Software Estimates, Targets, Plans and Commitments newsletter to refresh your mind on how these things are linked together and how it relates to costs.