Becoming a master of estimates


In software development the purpose of estimates is to reach an agreement with the involved parties. Estimates are tools of communication. They are warrants for the expected budget, duration or scope of a given project or product. The project’s business case will be evaluated on the basis of these warrants.


But be careful. Estimates are not hard facts, they are but guesses. And how dare we professionals to base huge budgets and business critical products on warrants that are guesses knowing that they by nature are uncertain?

 Making the uncertain as certain as possible

“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable”

Guessing on any future event holds no guarantees. One could even go so far as to say “do we really know anything for certain?” I won’t dive into that question!

But what we can do is to make those guesses as likely as possible. Our guesses should be so good that an agreement can be made based upon them meeting the expectations of the parties involved. However, what is a good guess that will be a solid warrant? It’s not the cheapest or most expensive guess or even the average. In fact it’s not even about numbers.

The best estimate you can make is, given a set of conditions is the most probable one, with risks explicitly stated.

Problem and difficulty concept

Dealing with the risks

If you want, you can even make contingency plans for the risks, and estimate those as well. But remember, even then, it’s still a guess and you should make sure that everyone knows what the estimation process is focusing on: increasing probability. Then, you have used the estimate as a tool to shed as much light as possible on the issue for all parties to see and reach a consensus that is agreeable to reason.

And by the way, talking about risks and the natural fact that humans make mistakes, early on in a project, is critical. Once the task or project is underway, mistakes will be made and you should learn from them.[] Or opportunities will arise, that you should seize. If the initial business case includes these eventualities, no one has to spend their time arguing about why the estimates are not being precisely met

There are many named methods you can use, to find the numbers – But I won’t cover them here. Instead, I’ll describe what factors we can try to control, to increase the probability of our guesses.



If we want to make highly probable guesses that agrees to reason, we need to be aware of, and  maximize these factors to the best of our ability. We need to understand the business case and the conditions surrounding the project, when doing the estimates.


How much time is available to do the estimates, before the opportunity is missed?


How easy is it to draw on past experience? How do you put the team of estimation together?

  • Personal
  • Organizational
  • None/external


What do we know about the task?

  • Everything
  • Something
  • Nothing

The optimal conditions are: Having personal experience with the task, all information available, and all the time in the world. However, that is rarely the case. So start by assessing how many of these three factors are available, and improve them as much as possible.

Not unlike the project management triangle, these factors can be used for identifying what we should focus on. We should build a foundation for estimation:

  1. If you can’t get time – get information and experience
  2. if you can’t get information – get experience and time
  3. if you can’t get experience – get time and information

I’m fairly sure that, whatever estimation method you use, your estimates will be highly probable by using this foundation up front.

My colleague Thomas Eldblom wrote a great blogpost about the developer view on the estimation process .

Ved du hvad digital asset management er?

When your best guesses are wrong

Nobody likes being wrong. But at least you (and hopefully the project organization) are proven right in the fact that “estimates are not facts”. People can hold very different definitions of the term “estimate”, and therefore expect something very different from the project result, -process, -communication and -priorities. Either you have planned with contingency based on risks, or if not: You need to start scoping out.

Scoping out is a way of hitting the estimates more accurately based on information you have gained during the project and the current use of resources. In that case, the current remaining time/budget becomes a constraint, a timebox, in which the team must complete the work.That means, you prioritize the remaining tasks and whatever tasks do not fit into the timebox are scoped out of the project.

This method of scoping out can be a very counter-intuitive surprise for a project owner, and in worst case have negative contractual implications. Or, it can be a previously agreed upon action that follows naturally, and the project finishes – fulfilling the business case. It all depends on how the estimates are defined and used to align the project to reason.




Follow us for similar blogposts:

Share the blogpost with your network:

Project Planning

You can’t produce reality by planning

It’s important to realize that even though you have created the perfect project plan by using the correct template, referencing the proper methods, and communicated it to stakeholders, reality will change it.
Monitoring these changes is an important task for a project manager, but has no value without acting on them and communicating the consequences.
Therefore the plan should be updated often to be a product of reality, and a common ground for decision making, communication, educated guesses and opportunities. This is what makes a project move forward, in reality.

Mistakes and stakeholders

At any given time, you can only make a plan based on the knowledge available at that time.
Not having foreseen an event, or not knowing every detail in a future process does not automatically imply incompetence or negligence. And don’t forget, not all surprises are negative.
The plan you make, should however prevent you from repeating mistakes, and should include processes to learn, take advantage of opportunities and make new decisions together with the stakeholders.
No project has an unlimited budget, timeline and scope. So before the project begins, understanding the project management triangle in this context is essential for all project members and stakeholders as a basis for decisions.

  1. “Making mistakes is the key to making progress.”
  2. “The secret is knowing when and how to make mistakes, so that nobody gets hurt and everybody can learn from the experience”

– Daniel Dennett. How Things Are, J. Brockman and K. Matson, eds., William Morrow and Company, New York, 1995. pp. 137-144. :

Before you start

Know where you are going. Making good decisions in a project often comes down to knowing the overall goals. The same goes for initial planning. If the goals are not crystal clear, you cannot make a long term plan or expect to end the project. In this case make a plan for crystallizing the goals. You might find that different stakeholders have different goals, and aligning the stakeholders before you start is well worth the effort, compared to a never ending project.

Don’t make the plan

Present the goals! And then get input from the people who will do the actual work, or input to the process. The plan should be a transcription of their input, seasoned with your experience and knowledge. This is an important step as it also commits the team to the plan, which increases the likelihood of it actually being realised.

The kind of input you need is

  • Activities
    • Duration
    • Flow
  • Proces
    • Dependencies
  • Communication lines
    • Who needs to know what, when and how
  • Risks
    • Mistakes
      • Mitigation
    • Opportunities
      • Adaptation
  • Resources
    • Humans are not robots
  • Organization
    • Who makes decisions about the goals
    • Who makes decisions about changing the timeplan

A team’s understanding of the above, gives you all the building blocks you need, to create a timeline that’s realistic within the planning horizon. And the team is committed and self reliant in making short term scheduling decisions.

The horizon and beyond

You have your building blocks and can now make an initial timeline for the project.
The start up activities are certain, and you can start to focus on the future.
The longer into the future you look, the more uncertain your plan is. Since you “didn’t make the plan” you can trust your team to handle current activities, freeing you to look up, towards the horizon, to verify agreements, align expectations and clear the critical path to increase the certainty of your plan.

Sacrifice your plan on the altar of goals

If you find yourself planning current events most of your time, things are not going great. And that means you are not planning next week – which means more trouble next week. This happens, as we know mistakes are made, or opportunities must be seized. But continuing like this for a longer period of time will almost certainly cause your project to fail. In this situation of prolonged reactive planning, you should discard your plan, find the root cause and fix it. This will mean disappointing stakeholders, but you are already doing damage control, unsuccessfully.


The end of a project is never a date in a timeplan. The project ends when the stakeholders agree that goals have been reached.

The time of the project manager

Taking the above into consideration, you will roughly be spending your time as described below


Spend little time looking towards horizon
Spend most of your time on current events

  • Clarify goals
  • Present goals – make sure everyone understands priorities
  • “Don’t make the plan”


Spend little time on current events
Spend most of your time looking towards horizon

  • Clear the critical path
  • Align expectations

Problems arise

Spend little time looking towards horizon
Spend most of your time on current events

  • Find root cause
  • Learn
  • Know when to sacrifice the plan


Spend most of your time on current events
Spend little time looking towards horizon

  • Make sure stakeholders agree that the goals have been reached
  • Handover the product for the next phase in it life cycle

What about the past?

If you get good at learning from mistakes, and you know your goals, you don’t have to revisit the past.

Follow us for similar blogposts:

Share the blogpost with your network:

Projektledere – hvad fanden skal vi med dem?


Gareth Keenan – mellemlederen fra helvede.

Gennem de sidste 4-5 år har den generelle opfattelse af projektlederens nødvendighed heldigvis ændret sig. Før-billedet var præget af en manglende forståelse for hvorfor, man skulle kyle midler i nakken på en projektleder, når nu man kunne bruge pengene på ”rigtige” ressourcer, såsom udviklere og designere.

Nu er opfattelsen mere pragmatisk. Virksomhederne har indset, at projektlederen giver værdi til projektet i form af proaktiv effektivisering, brug af de rigtige mennesker på de rigtige tidspunkter samt eliminering af problemer før de rammer ”de rigtige ressourcer”. På den måde får de ”rigtige ressourcer” mulighed for at koncentrere sig 100 % om at udvikle og være kreative.

Der er imidlertid en række faktorer, som både projektlederen og kunden skal være opmærksomme på, hvis man skal opnå en fælles succes.

Kald det hvad du vil

Metode! Agil, SCRUM, PRINCE2 – kært barn har mange navne, og alt for ofte ender man i endeløse diskussioner om hvilken metode, der skal anvendes. I virkeligheden drejer det sig om at finde en fælles referenceramme og en fælles metode, der er forankret i én eller flere af ovenstående metoder.

Alle metoder har fordele og ulemper, så den endegyldigt bedste metode findes ikke. Det er en vurdering fra projekt til projekt. En dygtig projektleder kan, ud fra projektets karakter, håndplukke fra de forskellige metoder til projektets bedste.

Skal en dygtig projektleder så pinedød være certificeret og uddannet i de forskellige metoder? Næ. Men vi kræver det alligevel, fordi det skaber en fælles referenceramme, en fælles platform, som vi kan bygge rammerne på – og dét er en uvurderlig evne.


 ”Jeg forventede…” eller ”Jeg forventer…”

Forventningsafstemning er verdens bedste idé. Overskriften herover forklarer det vel bedst. Hvilken situation er nemmest at gøre noget ved? Hvilken situation er mest konstruktiv?

I vores daglige arbejde anvender vi bl.a. projekttrekanten som redskab til forventningsafstemningen. Den går efter vores overbevisning aldrig af mode. Den er nemlig baseret på sund fornuft.

Du kan ikke få alt til den halve pris på en tredjedel af tiden. Så hvad vil du gøre? Vil du sænke ambitionsniveauet for at blive færdig tidligere? Vil du poste flere penge i budgettet for at få flere funktionaliteter? Prioritering, prioritering, prioritering. Trekanten skal være i balance for at projektet skal lykkes.

Vi afsætter normalt mellem 10 og 25 % af projektets timer til projektledelse. Den investering giver altid et godt afkast. Projektlederen er nemlig den faktor, der får processen til at glide og overholder de rammer, der er aftalt. Så er andre fri for det og kan koncentrere sig om at udvikle.

Involvér – Innovér

Vi er skidegode til det, vi laver. Og vores kunder er skidegode til det, de laver. For at projektet skal lykkes, er det derfor vigtigt, at begge parter involverer sig. Begge parter skal byde ind på de områder, de hver især er eksperter i, så projektet løfter sig.

Som vi oplever det, er der en direkte sammenhæng mellem, hvor meget kunden involverer sig i projektet og kvaliteten i slutresultatet.

Så altså…

Digitale IT-projekter er meget mere end teknik. De er også vigtige forandringsprojekter, der lader din virksomhed vokse ind i den digitale fremtid. I den forbindelse er projektlederen den nødvendige smørelse, som sikrer retning og fart. Så det er altså, hvad vi skal bruge projektledere til.

Follow us for similar blogposts:

Share the blogpost with your network: