Project Properties: Effort, Cost, Value

Project owners use effort, cost, or value to estimate or show the progress of a project. For example, in a marketing campaign project, it is common to hear some variation of: “In the past X months, we spent $Y on this project that led to a Z% increase in revenue.” In this example, “X months” shows the amount of effort (proxied by time), “$Y” is the cost, and “Z% increase in revenue” shows the value.

There are nuances for using effort, cost, and value in project planning and progression. These nuances can mislead stakeholders and create an illusion of achievement. Below is a closer look at these three elements.

Effort

Effort is the amount of work needed to complete the project and deliver the promised value. It is usually measured by how much dedicated time is required for a project. Time is measured differently from organization to organization. Some prefer hours, while others use weeks.

If multiple disciplines work on a project, the effort estimation will be split by discipline. For example, if software engineers (SWE), data scientists (DS), and quality engineers (QE) are needed, the effort estimation will look like this: 20 SWE weeks, 5 DS weeks, and 5 QE weeks.

Some notes on effort:

Effort is not a timeline. 20 SWE weeks does not mean it takes 20 calendar weeks. Sequencing, available resources, and parallel execution affect the timeline. A 20 SWE weeks effort project can go down to a couple of weeks or up to a couple of years.
Buffers help with effort adjustment when there are unknowns. More unknowns require more buffer. While some unknowns can become clearer with investigations, there are still unknowns that can derail the project from its course.
Experienced project managers help with high-effort cross-functional projects. They can align stakeholders, track progress, identify gaps, prioritize tasks, and escalate issues when needed. Without them, the project requires more effort, and there will be potential churns in work due to misalignment.
Waterfall and Agile have different effort estimation expectations. In Waterfall, the project has an estimation from the beginning, which will last until the end. Agile, on the other hand, is an iterative process. Agile estimates are at the user story level rather than the whole project.
New pieces of information during execution can change the effort. All stakeholders should become aware of the new information and re-adjust. For example, a competitor just released a feature similar to a feature from a project in progress. In that case, the product manager may cancel the project or change features to get a competitive advantage.
Investigations and prototyping increase the accuracy of effort estimation. Agile Spike is a good example of how to deal with unknowns.
Estimation can change based on contributors’ level of expertise and domain knowledge. Better estimation comes with better knowledge of the talents who will work on the project. New hires, for example, take time to onboard, and there is potential churn in their work at the beginning.
Maintenance and administration are part of the effort. Systems need both to run smoothly. They are ongoing efforts that can span multiple years. They may not seem important at the beginning. But, systems decay. Not considering maintenance and proper administration will leave the company with tech debts and security risks.
Some companies use t-shirt sizing such as small (S), medium (M), large (L), and X-large (XL). This presentation shows buckets for a range of efforts. The benefit of this way is spending less time digging further into individual tasks while maintaining a lower and upper bound estimate.

Cost

Cost is the monetary investment, measured by $ (or local currency), required to run the project from the start to the end. It includes human resources, infrastructure, and external services. Companies allocate a budget for project costs. If the project is big enough, it will have its dedicated budget. Smaller projects usually consume from a shared budget.

Some notes on cost:

Cost should be broken down if the project needs funding from multiple budgets. These budgets can come from IT, HR, Engineering, etc. Each budget owner should sign off separately. Executive sponsorship can help with fund allocation with less friction.
Cash flow analysis helps run long-running projects smoothly, especially when the company is tight on working capital. Companies pause or shut down projects when they don’t have enough money to pay the bills.
Some costs can be overlooked if another department is paying the bill. For example, a project on the surface may need $50K to purchase a piece of software. Hidden costs are the infrastructure costs, billed to the infrastructure team ($100K), and human resources cost (12 SWE weeks = $30K) to set the service up, which come from a shared pool of resources.
Subscriptions should be handled with extra care. Many SaaS companies are offering subscriptions. They offer good deals to attract customers for the first year and charge them the full amount upon renewal. It can surprise many that the finance team doesn’t sign off on the renewal because of a new surprising bill.
Costs increase as the company scales up. Many elements of the original cost estimation, such as vendor and infrastructure costs, will increase with more users using the project artifacts. Cost projection should include growth costs for better decision-making.
If the cost of a project is significant, the cost analysis should contain the option for buying versus building. There are pros and cons for either. Building gives the company more flexibility on features at the expense of time and the costs of building and maintaining. On the other hand, buying provides an already-made solution at the expense of less feature flexibility and vendor locking. The project owner should make a conscious tradeoff.

Value

Value refers to the overall worth or importance of a project. This can be evaluated in various ways, including the monetary value of the project, the impact it has on stakeholders, and the benefits it brings to the organization or community it serves. Determining the value of a project can help organizations prioritize their resources and make informed decisions about which projects to pursue.

Some notes on value::

If the value is not objective or hard to measure, all stakeholders should be aligned. Values such as customer satisfaction or developer productivity are not objective. Some proxy metrics, such as NPS score or DORA metrics can be used to track, but they don’t 100% represent the actual value. Without an alignment, stakeholders may have their interpretation of the value and track a different goal.
The goals of a project should be tracked as metrics or proxy metrics, visible to all stakeholders. At any point in time, each stakeholder should be able to look at a central dashboard and fully understand where the project is with regard to value delivery. This dashboard is essential in Agile, where the value delivery is incremental.
A postmortem is an essential learning tool when the project does not deliver the promised value. No company wants to do a similar project and makes the same mistake.
Like money, a value’s worth can change over time. For example, a company plans on a project that creates a unique feature. The worth of this feature will change when a competitor delivers the same feature.
A project should be re-evaluated when the worth of the promised value declines. Sometimes, sunk cost fallacy or an emotional attachment to a project leads to project continuation even when it is logically obvious the company should cut the loss and pivot.
Stretch goals can be harmful if not handled with care. For example, a company’s front page load time is 4 seconds. Based on research, they conclude that if they can reduce this time to less than 2 seconds, they will retain 40% more users. They can push the numbers to 45% if they go as low as 1 second. They can achieve the first goal with some trivial front-end optimization. The second goal, however, requires re-architecting the whole system to optimize back-end services and data fetching. In this case, the stretch goal can cost the company more than the money they intend to make.
A project’s value should be aligned with a company’s goal. This alignment does not need to be direct. But the path between the project value and the company’s goal should be visible. OKR is one of the methods that show this alignment.

Takeaway

Effort, cost, and value are important parts of a project. They can decide the fate of it: to pursue or not to pursue. While on the surface they seem straightforward, some pitfalls can cost the company significant time and money. Project owners should ensure tackling the right problem with the right value with accurate effort and cost estimations, especially when the stakes are high.