How to Guarantee That Your Project Will Be Successful
(4 Min Read) One simple tip that's every engineer must implement.
Every engineer wants to work on a successful project. The best way to ensure that is to start a project and make it successful. Duh!! But only if it was that easy.
Many projects fail because the definition of success as per the engineer differs from the definition of success as per the company, i.e., leadership or peers.
Now you may be asking, does that even matter? Who cares if the engineer definition is different from others? And if it does, when does it matters?
Yes, it matters (more than we may think) and especially at the time of calibration/promotion.
A project can be a success and a failure at the same time 🤯
Engineers assume a project is successful if it solves the problem. The company (leadership) considers a project successful if it delivers the promised impact. This is where the problem lies. Different entities have a different understanding of impact and evaluation criteria. But why does this happen?
When the impact and the evaluation criteria are not clearly defined and captured, everyone defines their own. I like to call impact and evaluation criteria the success criteria collectively.
Engineers often define project impact as a problem solved. They assume the evaluation criteria are going to be how technically challenging it was to solve the problem.
Leadership defines the project impact as the impact on the business (growth, savings) when the problem is solved. They assume the evaluation criteria as the time to market, cost, and scope.
As both of them have different definitions of impact and evaluation criteria, it results in a technically successful project (per engineer) that failed to deliver the right business impact (per leadership).
When does this problem arise?
This contention usually arises at the time of engineers calibration/promotion. Clearly defined success criteria can easily break the tie. Often that's not the case. In place of pre-defined success criteria, the problem is usually solved by asking the engineer's manager. (And you see where I am going with this)
Not all managers are skilled or often even aware of the technical depth of the project. Even with good intentions, they are likely to do a poor job at explaining. I am not saying that all managers can't explain; I am saying that most managers may not be able to explain the project as well as the engineer. There are other situations such as manager departing from the team or organization changes can also lead to a manager knowledge gap. Either way, failure to do so results in leadership/peers using their evaluation criteria and engineers getting the short end of the stick.
This is why engineers are often confused when a successfully delivered project does not get the acknowledgment it deserves. So what can we do about it?
Define Success Criteria Upfront ☝️
It’s the easiest and most efficient solution in my experience. Define the impact and the evaluation criteria upfront and gain alignment on them before starting the project.
Revisit the success criteria when the requirements change, and they will change. Even if they won't, it's an excellent time to re-evaluate.
When we define project success criteria and achieve them, no one can argue if the project was successful. And as you may have already guessed, defining success criteria helps the engineer, managers, and other peers during the performance cycle. Even if a new manager takes over, it's easier to get them aligned and prepared for calibration/promotion discussions.
Key to defining success criteria 🔑
When engineers first start defining success criteria, they get flustered. That's genuinely understandable because engineers have their engineering success criteria such as using the specific open-source tools, tech-stack, feature list, etc., which are different from organizational standards such as time to market, cost, etc. And the organizational project criteria are what matters unless it's an open-source project.
The key is to ensure that when defining the project success criteria, they are aligned with organizational criteria. A project that meets organizational criteria is considered successful every time over a project that exceeds engineering criteria.
Finally, if you joined a project mid-way or are currently leading one without defined success criteria, pause and define them, that exercise will be the best thing you can do right now to make the project successful.
If you find this interesting, you can follow me on Twitter or subscribe to this free newsletter. Here is the tweet that initiated this post
