The Start of a Project Is the Worst Time to Estimate Its Duration or Cost
This is only the case if those you've hired know nothing about what capabilities are needed to produce value the project, what Features are needed to produce that Value, when those Value-producing Features are needed to meet the time cost of value payback process, what risks there are for meeting those value producing outcomes, and how the work effort to produce that value are to be measured (physical percent complete) to increase the probability of success for your project. As the project progresses this understanding will, of course, improve with feedback, working product, and learning.
If those you've hired don't have some sense of these needs, to some level of confidence, you've hired the wrong people.
From Estimatiing and Reporting Agile Projects with the SRDR
The suprising discovery of Newton's is just this, the clear seperation of laws of nature on one hand and initial conditions on the other - Eugene Wigner, in Newton's Principis for the Common Reader, S. Chandrasekhar
There are 5 immutable principles of project success. Without the initial conditions of these five principles, the project has little chance of success.
If you have a Due date, you need the plan to show up on that date, with what is Due for the cost of that Due Item and have that Due Item be compliant with the attributes (effectiveness and performance) needed by those paying you.
I was asked to look at a corrective action plan this year, that had a list of deliverables that were supposed correct the root causes of the problems identified as the reason the project was not performing as planned. The right two columns were the person performing the work and the DONE date.
A big smile came to my face. I see the real root cause of your troubles here. You don't know what Done looks like. That's the first immutable principle of project success.
Without knowing what Done looks like in units of measure meaningful to the decision makers, the project has little hope of success.
Those making the original assertion need to bring evidence. Without that evidence, those challenging the assertion have no need to bring evidence. For those making the assertation to ask for evidence as to why their conjecture is correct is the Burden of Proof fallacy, which is common when the original conjecture has no basis in principle, fact, or experience - it's just a conjecture. All attempts by the original assertion author to invert this fallacy should be strongly rejected, since it shows a lack of understanding of who ideas are put forth and tested in the larger marketplace of ideas.
The speach I love is a simple, natural speach the same on paper as in the mouth; a speach succuleant and sinewy, brief and compressed not so much dainty and well-combed as vehement an brusque - Michel de Montaigne The Essays of Montaigne (1580).
When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knpowledge is of a meager and unsatisfactory kind. -- Lord Kelvin Popular Lectures and Addresses, 1889.
Without numbers, without some means of assessing the situation, the outcomes, the impacts, any conjecture is of little use.
"I am always doing that which I can not do, in order that I may learn how to do it." - Pablo Picasso
When I'm asked to help a client with something new, it's usually close to the domain I'm currently working in. But sometimes it's outside my core experiences. When this happens it's an opportunity to expand my core competencies. Program Planning and Controls applied in new domains is one example.
This learning process starts with first principles, of course, so at the very bottom of any new knowledge are similar principles. This is the case for most anything we do. Go back to first principles and determine by what principle does this new knowledge have validity? When you find that, you'll have a rock to stand on in the exploration of new knowledge. If you're exploring this new domain with no basis for recognizing good ideas from bad ideas your contribution to the client's needs is likely to be less than they are expecting for their money.
When you hear we're exploring ask if that exploration has any hypothesis that is being tested, any way to recognize that the exploration is actually moving toward some goal, that the exploration has some way to measure progress toward the goal? No, then those exploring aren't actually exploring, they are just wandering around spending their client'ss money in the hope they will find something of interest they can call discovery.
We have a bumper sticker here in Boulder
Those who wander aren't always lost.
This is not true, if you're wandering around looking for the answer, you're lost. If you're a Boulder hippy and Ward, no problem. But those paying us have a reason to spend that money. They need something we can provide.
Never attribute to malevolence what is explicable by incompetence. - Robert J Halon
When we hear all the bad things that go wrong with projects. The misuse and abuse of data, people, tools, and processes, I get a smile when I remember Halon's quote.
Removing things, changing things, installing new things will not address the root cause of bad management and especially bad project management. Only replacing the people will fix the root cause when they are willfully ignorant of how to do it right.
While this quote appears inverted in our self-centered world, the expert has eliminated the nonsensical, naive, amateur, simple minded options and narrowed the choices based principles, practices, and processes of her profession. It is trivially easy to assert I'm exploring new ways of doing things when there is no bounding governance principles to guide your exploration. If the exploration takes place in a de minimis world, the options are boundless.
Thought interferes with the probability of events, and in the long run therefore, with entropy - David L. Waston (1930)
All project work is probabilistic, driven by underlying uncertainties, both reducible and irreducible. Willing an outcome in the presence of these uncertainties does not make is so. The only useful process to manage in the presence of uncertainty is to estimate the outcome of any decisions made by the participants of the processes by which the project operates
The perfect symmetry of the whole apparatus - the wire in the middle, the two phones at the ends and the two gossips at the ends of the telephones - may be very fascinating to a mere mathematician - James Clark Maxwell (1878)
Trust is a core attribute of Agile Software Development. But any non-trivial business venture will also what to verify that to outcomes of the work effort are going to meet the needs of those paying, at the time those capabilities are needed, for the expected cost.
When you hear agile is all about trust, make sure you have a appropriate verification process in place as well. This is called governance where we work. It's risk management and Risk Management is ow Adults Management Projects (Tim Lister).
Many want us to trust but any credible governance process requires a verification process. With that verification, that trust cannot be trusted.