Formula to Calculate Average Cost per team member per month

How much you expect to spend on wages

+ Total headcount on project (developers and non-developers)

+ Estimated project duration

= Average cost per team member

If that number makes sense and is roughly in-line with the wages for your area, you’re on the right path. But you still need to answer a few questions:

If any answer to any of those questions is “no”, you have a problem on your hands. Address it early rather than proceeding with blindfolds.

When the budget is tight, the price is often paid in speed, quality, or both.

Absence of Product Requirements Document (PRD)

While there's a modern tendency to downplay the necessity of Product Requirements Documents (PRDs), they are crucial for efficient execution.

Developers are capable of determining requirements without PRDs, but that diverts time to meetings, research, and deciphering the business logic—time that could otherwise be spent on actual development.

Key details that should be outlined in a PRD include:

Without these clearly defined, developers are pushed into a cycle of non-development activities that can steer your project off course. We are not advocating for removing developers from product development activities. In fact, a chunk of their time should be spent close to the customers and the product management process. But we urge close attention to how team member time is allocated across tasks and how that affects time-to-delivery.

Constant Changes in Scope

Scope change is a fact of life. However, they often slipped in during meeting or in emails without proper acknowledgement by all parties. With each scope change you must make realistic adjustments to timelines and budget. In addition, clearly state the reason for change and develop strategies to prevent future changes.

Constant scope changes, even minor ones, lead to reduction in quality, morale, and potentially, the failure of a project. It is especially unrealistic to rely on more output by your team to make up for scope changes.

Stakeholders Unaligned

If you have multiple stakeholders in your project and they’re not aligned, that misalignment will ultimately make its way into your product.

Do multiple partners/departments disagree on which workflow to follow? Is everyone in agreement with third party libraries being used? Is language being used in the application to describe things agreed upon with everyone?

Sniff out misalignment and fix it before it crashes your project.

Lack of Customer/End User Involvement

All software is made to be used. And if the people who are meant to use it (customers) are not involved early and consistently, you risk building an unusable. Which in most definitions, is considered a product failure.

Put customer feedback into your process early on and significantly increase your chances of success.

Unclear Project Management

Simply, at any given time, can someone answer the following questions:

Without clear project management, the team is likely to become overwhelmed quickly and lose focus. More importantly, project management starts with effective product management. If there are frequent scope changes and unclear product definition, the project management will likely be a mess.

Lack of Defined Success Metrics

If all team members are clear on what success looks like - you’ll be more likely to be successful. For example, if you’re building an accounting software, you may have the following metrics:

These metrics have to be pragmatic, not vanity metrics, and should prompt action when targets are not met. Inability to come up with specific metrics that determine product success, or a scenario where every action in the application is a success metric often points to eventual product failure.

No defined process to identify and investigate uncertainties

Some people think of product development as a process of flying a plane while building it. I’d rather think of it as searching for the key to success inside a murky swimming pool. In order to see clearly and effectively search for the key, you need to filter the pool of all substances (uncertainties).

The ability to find the right messaging, right pivot, right value proposition, or make key decisions is predicated on how clearly you can see. Identifying the major uncertainties: risks, questions, and unvalidated assumptions and systematically dealing with them will clear up the murky waters and increase your chances of success.

Conclusion

Software is hard, but it’s not impossible. Simply dealing with the aspects above can set you up for success where others would otherwise fail. It requires intellectual honesty, realistic budget, discipline to avoid shortcuts, and collaboration of a team of operators. The road might be difficult, but the goal of a successful product is a goal well worth the strife.