What does a feature cost?
A lot of people would like to know but in the last 20 years or so, we have migrated away from the practice of budget and cost tracking for distinct features to the more Agile approach of 1) how will we make that feature and; 2) is it done yet? It’s a project management formula with the potential for enormous mischief.
Let’s roll back the project management clock a bit to put this all into perspective. Project plans used to be mostly guided from the top. The project sponsor or owner would want to create something. “How much will this something cost?” they might ask or, “I have this much funding, what can you create with that much money?” A project manager would assemble people to create estimates of the work to be and identify the multiple elements involved in creating the something including estimates of durations, costs, dependencies and options. If we’re talking about a software project, that would likely be broken down feature by feature with some features perhaps dependent on certain underlying architecture advancements.
In the 90’s in the lead up to Y2K, this method proved overwhelming for mega software project that often included reviewing and updating entire enterprise systems that were 20 or 30 years old. As soon as New Year’s 2000 was behind us and the crisis of software updates abated, the notion of Agile became popularized. Design-build wasn’t a new idea. It has been every version of the Project Management Institute’s PMBOK but it was certainly new to the software industry where, in the 2000’s it became more and more popular.
With Agile teams now much more nimble and able to create iterations of a project that could be released in phases or in parts, the process gathered even more fans.
In the Agile community now, there are some aspects to the development of high tech projects (and not just software) that carry costs of that nimble-ness. Where a team can now add new tasks to the backlog, change features on the fly, update the perceived overall scope of the project itself, that seems perfect… to the team. But the need for knowing what is being created and what it is expected to cost is still critical to the management of the organization and that is not getting the same attention in an Agile only process.
Let’s take a case in point. A kick-off meeting for the new version of a software product makes a list of potential features. Management and the technical team work back and forth to come to an understanding of new features that marketing desires and what background architecture changes the technical team believe to be critical. To add to that list is the every present list of what is needed to keep up with associated technology to continue to be compatible with security standards, database version, operating systems, browsers, mobile upgrades and so on. A global budget for the project is set and is probably constrained by when marketing will need this new version to be released and the overall availability of resources available either within the organization or available to it. Everyone in this group understands that the project might not go exactly the way they are projecting on the first day. Features might be harder that expected to create. Staffing and available skills might change. Priorities of the organization might shift. But, management, marketing and the technical team have all made whatever compromises needed to come to a final plan. Key in that thinking if the determination of what a feature is worth. At some point in the discussion is a trade off of what features will be included and what features will not based on the available time and budget.
Now the technical team takes control and moves forward with the project.
From this point on if we are in an Agile project process, the process works like this:
- A Scrum or huddle occurs. The team leader (scrum master) creates a sprint with a short term of 1, 2 or 3 weeks in duration.
- There are a list of tasks from the backlog of the project to which individuals can assign themselves or be assigned. Individuals end up assigned to tasks they expect to compete within this sprint.
- At the end of the sprint, everyone huddles again to report on progress. “Is that item complete?”, an individual is asked.
- If the answer is “yes”, the scrum master takes note and the individual gets something new from the backlog.
- If the answer is “no” the item is almost always just slid into the next sprint.
- Eventually the entire list is either completed or the project’s duration runs out and anything not completed just goes into a pool of future features to be considered for the next version.
I’m simplifying of course. What I’ve just written up in a couple of paragraphs is described in great detail in volumes upon volumes of books and training material. This process works. We use it at HMS to create new TimeControl versions and we’ve been using this process since long before the term “Agile” was used in a project management context. The process is almost universally popular at the team level.
But.
There is something fundamentally missing from what I’ve described that is the oversight of many projects managed in this manner. We don’t typically keep continual watch on the cost of a thing and the cost of a feature can spiral upwards when that oversight is not included.
The process I’ve describe has Activity-Based-Estimating. That’s great but it doesn’t cover the cost.
Over time at my own HMS Software company, years ago we decided we needed to have our technical team timesheets align with our Activity-Based-Estimate. We added the notion of timesheets into Agile (something that is often not tracked in an Agile world). This meant making chargeable tasks that matched features and, when someone would add a task in an Agile manner to a backlog, that the task had to link up to a budgeable item.
It has been a number now but back when we started that we had several unfortunate surprises. One was that our technical team estimates were strong on development time and underweighting testing time. Almost all time spent in QA was underestimated. So we adjusted our estimates going forward. Another unfortunate discovery was that sometimes a task would be assigned, then carry over into one, two or three sprints. A worst case scenario happened one summer which wasn’t noticed as quickly because we were all so busy and also interrupted with vacations and such. A task originally expected to take 3-5 days was in its 13th week of development and was still not complete. That was a wake up call for us and we adjusted our process and tracking directly.
Our project management method is now much more of a hybrid environment. We do planning from the top down including estimates from the bottom up. What is different however, is we are tracking the costs of features at a feature by feature level.
If we think back to that original design meeting and the trade offs that marketing, management and the technical team are making to decide on what will be in the next version, it is easy to see how some decisions would be different if the true cost of a feature was known in advance. Things happen in projects. Everyone in project management understands that. But that’s why project managers exist.
When money is almost free, there is less focus on these costs. For many years, only growth counted, not the value of what was being created. In the last couple of years, that perspective has changed dramatically in the industry.
When we re-introduce Activity-Based Costing into modern project management, we end up with an interesting construct. The Agile process continues uninterrupted at the team level. Scrum masters still lead the scrum meeting, tasks are still assigned, the sprint progresses. But, when timesheets are now being used to track the cost of these features, there is an opportunity for a project manager to intercede. Perhaps a feature should be cut or deferred into a future version if becomes too expensive. Perhaps there is a skill mismatch on the task or perhaps there is an underlying problem that is more architectural. The comparison of the feature cost to the original feature estimate tracks that.
Another aspect of Activity-Based-Costing that is almost unspoken of in recent years is the use of the baseline. A baseline saves an image of the project at its start and can be used to compare both schedule and cost elements activity-by-activity. If you have organized a software project by feature then the original plan will show what you intended to deliver, when and for how much.
As the project progresses, variances to the baseline can be critical. Originally, the baseline feature was targeted at dates but in a software context, that’s not quite as interesting. After all, one of the characteristics of a software project plan is that many of the tasks on it can be done in almost any order. So, comparing the software schedule activity-by-activity from the original plan to the current schedule shows huge variances. Let’s put that aside for a moment. If we just compare instead, the expected durations and the budgeted costs, the report becomes much more relatable in a software context.
It should be apparent that no one at the team level likes this conversation. I’ve never met anyone who likes their work being supervised. But, when you look for big variances as a project progresses, you can see where a feature’s costs or work effort starts to make major deviations from the original intent. In many cases, this can indicate scope-creep. At HMS we’ve had this very aspect of our project management process cause a pause in the development of a feature that was envisaged by management to do something and that the technical team thought could be so much bigger. As the plan for that task went from a few days effort to a couple of months, we paused and regrouped. Did management want the newly envisaged much bigger feature? They did not. It was not seen as valuable enough to do the additional effort. The work was scaled back to more closely match the original intent.
Some people complain that baseline management ties you to your thinking of a year ago. But baselines in most modern day project management software is designed to allow for updates with an original baseline set aside and updates to the baseline happening at controlled moments along the path of the project.
Finally, reporting in an Activity-Based-Costing method can be hugely helpful once this project is even over. Feeding back to the technical team the actual cost of a feature compared to its original budget makes estimating even more accurate in the next cycle. Seeing what a feature costed gives marketing an opportunity to see if there was a positive return on investment for that particular effort.
Activity-Based-Costing may not be a new notion. But it’s one that hasn’t lost its usefulness at the management or operational project management level.
For those interested in how TimeControl implements Activity Based Costing, see the White Paper: Activity Based Costing Using TimeControl on the TimeControl.com website.
