Common Website Mistakes 11: Lack of Business Value
Don't confuse enthusiasm with priority!
This is one of my favorite quotes from the highly recommended book Rework. In an entertaining and easy-to-follow manner, this book explores common mistakes that organisations tend to make during projects. The mentioned statement makes a point in regards to the added value of any solution: it might be perceived very differently depending on who is doing the job. Business teams tend to create overloaded and bloated processes, back end developers might over-engineer their code to consider rare edge-cases and front end developers put too much effort into design aspects. Each of these groups have their own perception of value and those clash constantly.
Opportunity costs
In a project with pre-approved resources, it is easy to perceive the allocated resources for tasks as "free", which often leads to spending more effort than required. Unfortunately, nothing is really free: Any effort spent for one task effectively takes resources away from another - potentially more valuable - one that could have been finished instead. This concept is known as opportunity cost.
What can you do
Go for Business Value
Business value should be the main metric when you prioritize and define tasks. Make sure that whoever implements the task understands the intrinsic added value that their work achieves. You will not be able to prevent all front-end developers from caring a little too much for design. Neither can you stop all back-end developers from considering a few too many edge cases. But you might still be able to reduce the excess effort altogether.
The 80/20 rule
Also known as the Pareto-principle, the 80/20-rule states that statistically 80% of the consequences come from 20% of the causes. Applied to project work, it means that roughly 80% of the value is coming from 20% of the spent effort. To benefit from this peculiarity, your requirements need to be more flexible. Does a process really need to be fully automated as is often ingeniously put into the requirements, or is it good enough to have the process semi-automated for a fifth of the development effort? Does a UI have to look exactly as in the design or are minor deviations fine when you save a few thousand dollars in return?
Describe Problems, Not Solutions
Development tasks are often described in the form of a solution rather than a problem, a common relic from the waterfall approach. Although this might be fitting in some environments, it often hinders the developers in coming up with a more efficient solution. Note that there is often a significant amount of effort put into solution design before it can be written down and prioritized, severely limiting your scaling options.
Allocate Less Time
Did you ever realize how projects and tasks are very rarely completed long before the deadlines or deep within budget restrictions? One major reason for that is Parkinson's Law, which states that work expands so as to fill the time available for its completion. In other words, if you assign a lot of time for a task, do not expect it to be finished early. It might be beneficial to allocate less time to tasks to facilitate more efficient results.
What do you think?
Do you agree? Did you experience situations where printing culture slowed down your publication process? Is this article helpful and would you enjoy similar content? Let me know in the comments.