“Our project is to implement a new widget management system”, she stated confidently. “Ok”, I said, “but what is the problem we are trying to solve?”
“We need a new system…”, she reiterated.
“Yea, but to what end? Whats the business goal? And how will we know when we have reached it? How will we measure success.”
“Look”, she said, steeling her glance and locking eyes with me, “My job is to get this project done in 9 months with 500k. No more. No less. I let the business people look after the business goals. My job is to deliver on time and on budget.”
Like many others, the project became a morass of blaming, finger pointing, and misplaced expectations.
Here is a 3 step process to avoid some of these problems
Gain clarity on the problem to be solved
You should be able to articulate to stakeholders and the team what the problem is you are solving for. This has a couple positive side effects:
It gives your team context. Context is important because it centers the attention on the outcomes to be achieved, not the activities to be performed.
It aligns your stakeholders. Stakeholders may think they’re aligned, but when you put a concrete problem statement in front of them, you will quickly find the difference in opinion and disagreement among stakeholders.
It helps greatly with prioritization. No project ever in the history of software development projects has ever had enough time, enough people, and enough budget. Effective management is the art of getting the highest value outcomes given your constraints. Since we know we won’t be able to do everything that everyone wants, we have to decide whats most important. Clarity on the problem to be solved creates a framework for prioritizing whats important (items that help us solve the problem), and whats not (items not directly related to solving the problem at hand).
Create a qualitative goal to be reached
A goal is a way to describe the end state of the solution your team will be developing. The purpose of a goal is not precision (we will get to that later), its directional accuracy. Goals are aspirational in nature and qualitative in description, and represent the opposite “end state” of your problem statement. Similar to problem statements, goals help with prioritization, context, and stakeholder alignment.
Outline quantitative success measures to be attained
Success measures, or lack thereof, is the area where I see the most problems. Companies, stakeholders, and project managers create success measures like, “on time, on budget”, which is a very lazy and undisciplined success measure. This is because companies spend money and initiate projects for three primary reasons.
- To save money
- To make money
- To reduce risk
In other words, software projects are initiated to help attain business outcomes. “On time and on budget” are project outcomes, but should not be the primary measure of success for a project, because they are not business outcomes. Not only that, but “on time and on budget” are only vaguely quantifiable. What happens if the timeline moves out? What happens if the budget increases? You can quickly see how time and budget as a measure of success can quickly get divorced from the business outcomes.
A more concrete measure of success would be “Reduce support calls by 50%.” There is a direct line between the amount of customer support calls and the overall support cost. If annual support costs $1,000,000 for a given product, reducing that overhead by 50% creates an additional $500,000 in value. Its easy to measure, easy to quantify, and easy to calculate the ROI of the project. In this case, we have a clearly identified business outcome that is specific, quantitative, and directly related to business success.
Moving beyond the triple constraint
To get the most value from project efforts, business stakeholders and product managers need to work with project managers to create lightweight business cases that help everyone understand the problem to be solved, the goals to be achieved, and how we will measure success.
Until Next Time,
Stay Agile, My Friends