Image source: https://flic.kr/p/s7aUff, Creative Commons License
Future is Not Predictable
In business life, managers usually want to know upfront how long a project will take and how much it will cost. Essentially, they ask us to predict the future. As humans, we like to assume predictable environments. They make us feel safe. However, as John Lennon has put it: Life is what happens to you while you’re busy making plans.
If we wanted to make detailed estimations for our projects, we would need to know the exact requirements and parameters. Unfortunately, we typically don’t have them. Stakeholders change their mind, we get incomplete and inconsistent specifications, people leave our project team, economic conditions change, we suddenly face unforeseeable technical problems, etc.
Do you want to assess your estimation skills? Try our interactive Quiz: How Good Are Your Estimation Skills?
Agile Management
Agile management is a strategy for handling the ever-changing nature of non-trivial projects. It omits a big design upfront and proposes an iterative, incremental approach for developing products and services.
Famous frameworks for agile management are for example Scrum and Kanban. At time cockpit, we started with Scrum during our early product development phase. Later, we switched to Kanban as this fits better to our way of working.
Do you want to know why we switched from Scrum to Kanban? Read more in our article Why We Don’t Do Scrum for Time Cockpit
Iterative = Not Plannable?
Stakeholders often struggle with the agile approach because it seems chaotic and risky. They don’t exactly know what they will get at the end of the project. They have a tendency towards a waterfall model as it pretends predictability. For them, agile projects do not seem to be plannable and manageable.
Once you accept the myriad factors that larger projects depend on, you know why the predictability of a waterfall-like process lulls you into a false sense of security. Agile methods on the other hand have built-in mechanisms for handling change. Change is welcomed.
Agile must not mean chaos and blind flight, though. At our company, we have developed best practices for keeping track of time and costs in agile projects. In this blog article I summarize the most important aspects.
If you want to know more about how we create time and costs reports for stakeholders in agile projects, check out our article Project Reporting in Agile Projects.
Begin by Exploring the Extremes
Our time and costs planning starts at the very beginning of a project by thinking about the extremes. We want to do a solid launch status check but reduce the necessary effort to a minimum. Here are the questions we ask the stakeholders and ourselves:
Time
Which hard deadlines do we have?
Examples: Upcoming trade shows where we absolutely have to present something, time until we run out of money, presentation dates for venture capitalists, etc.
Asked for deadlines, customers often answer things like “it depends” or “we are flexible”. That doesn’t help. My strategy for such situation is to reply with a totally insane suggestion. “So it is ok if it takes us five years” (replace five with any number that is ridiculous in your project). Of course the customer will protest. “So you do have a deadline, don’t you?”. That typically gets the right discussion going.
Feature Set
What is the absolute minimum feature set that we have to have at these deadlines?
See also concept of the Minimum Viable Product aka MVP
Don’t ask stakeholders for lengthy specifications. A short, well-conceived overview is worth much more than hundreds of pages with details that will change anyway during project implementation.
It is important to question the stakeholders’ requirements until there isn’t anything left in the MVP that could be omitted. Ask questions like: “So the entire project does not make sense if we cannot deliver feature X, right?”. If stakeholders hesitate to reduce the scope of the MVP, ensure them that they will be allowed to broaden the project scope once it becomes clear that the project is ahead of schedule and under budget.
Budget
What maximum resource budget do we have?
Examples: Cash, budget, number of project members, limited number of specialists for a crucial technical area, etc.
This one is hard because it requires trust between stakeholders and the project team. Emphasize that an open communication about resource constraints is crucial for the success of the project.
In many cases stakeholders refuse to tell you the maximum budget. That’s ok. However, once you provided the effort estimation (see next point), they have to at least tell you how their maximum budget fits to your upper/lower estimation.
If stakeholders are vague about maximum budget, use the strategy mentioned above: Provoke by mentioning insanely high efforts. “If money isn’t the problem, it is ok if we hire a dozen new developers and spend two million Euros, right?”
Estimation
How many resources and what throughput time will we need to build the MVP?
Never work with point estimates, use ranges instead!
The estimation has to consist of a lower and an upper bound:
- Lower bound: At least how many resources and throughput time do we to build the MVP? Even if everything is running perfectly fine, we will at least need that.
- Upper bound: With how many resources and throughput time are we very sure that we can build the MVP (90% confidence, for details see How Good Are Your Estimation Skills?)?
Of course we spilt larger projects into smaller units of work. However, we do not overdo with too many details. The number of work units depends on the size of the projects. Larger projects (in our case between 100 and 150 person days) typically have between 10 and 15 work units, seldom more. More detailed effort planning is not done upfront but during the project (e.g. Sprint planning in Scrum).
Launch Status Check
Based on the answers of these questions we discuss whether it makes sense at all to start the project. Here are some examples for things that could happen:
- We have to ask the stakeholders to
rethink the project (e.g. reduce scope, remove or postpone hard deadlines, etc.), if …
- … minimum throughput time will make us clearly fail the hard deadlines
- … minimum necessary resources already exceed the hard budget limit
- We have to ask the stakeholders
if they want to take the risk, if …
- … minimum throughput time would be ok but with maximum we will not meet the hard deadlines
- … minimum resources would be covered by the hard budget limits but the maximum is not affordable
- We can tell stakeholders
not to hesitate, if …
- … even maximum resources and throughput time allow us to finish in time and under maximum budget.
In large, complex projects we do such launch status checks multiple times. We repeat them before we start large, new modules. We use them to evaluate the feasibility of new, epic features. It helps us to think about the scope of upcoming releases.
Define Tracking Heartbeat
When we decide to start the project, we define a time and cost “tracking heartbeat”. With Scrum, the natural rhythm is the sprint length. We think it is important to establish a regular interval for talking about time and costs tracking as this brings back some stability and plannability that stakeholders often miss in agile projects.
When we do customer projects, our tracking heartbeat varies between one week and one month (our billing interval) depending on project phase, the project’s health, and the customer’s wish.
Regular Health Check
KPIs
Our article Project Reporting in Agile Projects contains an Excel template showing how we structure progress reports.
At every tracking heartbeat we gather the following KPIs:
- Elapsed project time in %
- (e.g. six weeks elapsed and 10 weeks to go until hard deadline would result in 37.5%)
- Per unit of work:
- Minimum/maximum effort estimation
- Stage of completion in %
(estimated by multiple team members and stakeholders, see also Scrum’s Planning Poker)
- Expected effort to date = Effort estimation * stage of completion
- Effective effort to date
The last item is one important reason why time tracking is relevant in agile projects. If you want to know more about why we think time tracking matters for agile teams, too, read our article Six Reasons for Time Tracking in Agile Projects
Health Check
Based on these KPIs, we do a quick health check on every tracking heartbeat. We check …
- … if our weighted average stage of completion is not falling behind the elapsed project time. If not, there is a risk of not finishing before our hard deadlines.
- … if our effective effort is within the minimum/maximum boundaries of our expected effort. If not, we are in risk of exceeding our hard budget limits.
We complement these hard facts with descriptions about the most important risks and blocking factors that the team is currently facing.
Stakeholders: Adjust If Necessary
The regular health check helps the stakeholders to adapt the project and/or the project’s parameters whenever necessary. In project meetings, I often use the mental picture of a real heart. Is the “heart” of our project healthy or do we have a sick patient? Here are some examples:
- We are faster and more efficient than we thought
- Project scope can be widened (we can deliver more than just the MVP) or
- resources can be shifted to other projects or
- launch earlier than planned.
- We are slower than expected because of a lack of resources
- Stop project or
- help removing blocking factors or
- get more resources or
- narrow project scope or
- postpone deadlines.
- Progress is ok but we need too much resources
- Stop project or
- get more money or
- help becoming more efficient.
- Progress is as expected and effective effort is within the estimated boundaries
- Continue as is or
- coach the team so it becomes even more effective.
We Don’t Predict, We Monitor
As you can see, we do not try to predict the future. That’s not possible and therefore it is a waste of time and energy. Instead, we try to validate whether starting a project makes sense with a minimum of planning effort. During the project, we constantly monitor the health of our agile project and have an open and honest discussion about effort and costs with stakeholders. That helps building trust between all parties involved in the project.
All in all, we try to reduce administrative overhead, prevent micro-management and avoid unnecessary big design upfront.
comments powered by