Too often folks on a project focus on getting to 100% complete of a specific feature, feature set, or even project. Unfortunately, too often that means those same teams aren’t focusing on delivering 100% value.
Draw a comparison with the infamous 80/20 rule: the first 80% of something takes 20% of the effort, and the last 20% takes 80% of the effort.
It’s highly likely I’m not delivering the best value to my company or customers if I’m spending inordinate amounts of time finishing up the last 20% of every feature/feature set/project. Instead, teams should constantly be evaluating the progress through their features and asking the hard, hard question: “Does it make sense to finish out the last bit of this particular feature set, or should we stop and move on to something else of higher value?” [1]
This isn’t often an easy sell to folks. Some individuals or teams get very focused on those 100% metrics because that’s how they measure their own value: 100% complete of their work instead of 100% value delivered on the project. That’s a tough hurdle to overcome since this mindset hits not only teams, but also management and stakeholders.
You can sometimes overcome this mental FUD by laying out the cumulative effect of working five features to 100% complete, when only 80% of those features offer high value. Continuing with my completely arbitrary, highly contrived numbers, say each of those features takes 20 hours.
80% of the value of those features was created in 20% of the work time: 20 hours * .2 == 4 hours of value creation time. Conversely, you’ve spent 16 hours per feature working on lesser value portions of that feature.
Add that all up and you’ve spent 80 hours of your 100 on low-value work. That hurts. Badly.
The bright side of this – the really shiny, awesome part – is that you’ve created tremendous value in 20 hours of work out of the 100 you had planned for those five features. You have delivered tremendous value to the customer in just 20% of time/budget/whatever.
If you focused on only the most critical aspects of your work then you could apply those 80 remaining hours to building tremendous value elsewhere in your project. You could even have the conversation with your customer that “Hey, based on the close interaction we’ve had with you through this short project, it turns out we’ve gotten everything you really need on this project. How about we figure out some other awesome things to do with the money you’ve got left in those remaining 80 hours.”
[1] You also need to think hard about the added weight for maintenance, sustainability, and overall complexity you’re adding in by working that last 20% to completion. Those longer term costs, both direct and implied, can crush the life of a system.
3 comments:
This is a slippery slope. Maybe the 20% of the project was already cut by the project manager when first scoping the work. I also would be concerned that developers don't start cutting things like UI/UX since it doesn't add any measurable functionality and is just "fluff" to many developers.
For those working in an agile environment, this should already be part of the sprint, where teams are always working on the features with the most business value.
These cuts should NEVER be made in a vacuum, Joe. Obviously devs can't unilaterally and arbitrarily decide to chop things away.
These evaluations shouldn't stop just because work is already underway on a feature. You may find unexpected dependencies or complexities as you work through a feature, or you may get better exposure of how that feature may (or MAY NOT) be used by your customers.
The point being: constant communication and discussion around what's most important -- and reassess whether or not it makes sense to complete something over moving on to new value.
It may be that you have to look at what are you really trying to accomplish. Are you trying to run a test on 100 PCs using a program or are you trying to reduce the amount of resources needed to perform a test on 100 PCs. Once again, communication is the key.
Post a Comment