A project has a beginning and an end.

This statement is an attribute of projects included in the widely accepted project definition.

But when does a project really start?

... and what are the requirements for a successful project start?

This is exactly what I want to discuss in this article today.

If you are clear about this, you can start projects in a way that ensures a good prerequisite for a successful project progression.

Be curious, some of my statements are once again controversial, others are self-evident and hopefully many will be helpful.

When does a project start?

I often encounter the view that a project starts when it is approved by the board, a committee, or someone with the authority to make decisions.

I disagree with this, and I will explain my reasons.

The approval of a project is always associated with significant consequences for the company.

* Funding is released,

* Resources are allocated,

* the company's profitability and thus its balance sheet are affected,

* and customer and market-relevant product decisions are taken with the project approval.

The consequences of a project decision for the company are correspondingly serious. Therefore, a project must be prepared ultra-thoroughly!

However, precisely this preparation is already part of the project because it requires a project-based way of working, a project-based organizational and communication structure, and released resources, i.e. employees.

For this reason, a project must start with an official "project start" that is well before the project decision date.

For me, starting a project means that a group of employees is commissioned to:

* Organize a project,

* Gather or develop the information necessary for making a decision about the project.

* Present it to the decision-making body for implementation decision.

If this is completed, the project decision can then be made on this basis.

The project approval itself is the decision to implement the project in accordance with the defined premises and objectives, and to allocate the necessary financial means and resources.

I will discuss the steps from project start to project approval and beyond in different articles. As I mentioned earlier, today is about the project's beginning.

The beginning of a project is not an unforeseen circumstance.

There must be a reason to start a project!

This reason usually arises from a business necessity, which can have different origins.

Many organizations have business units tasked with identifying and assessing business needs and gathering information to ensure project success.

In product projects, it is usually the product management or product strategy team that takes the lead.

So let's take a look now at what information is urgently needed for a successful project start.

What information must be available at the start of the project?

1. Defining the problem that the project intends to solve.

The fundamental question is: Why start a project in the first place?

Clearly stating and justifying the issue to be solved is crucial at this stage.

The project team should be provided with comprehensive supporting material to ensure they fully understand and assess the issue.

Keep the priorities in focus!

Clearly and precisely distinguishing which problems urgently and inevitably need to be solved and which smaller problems can be addressed simultaneously is crucial.

The first category must not change on the way to project approval and later during project implementation.

The second category will be further refined and prioritized in collaboration with the team and the organization until the project approval.

When money and resources are scarce or when goals contradict each other, such problems need to be set aside. On the other hand, if resources allow, relevant additional content can be identified and integrated into the project if feasible and beneficial.

Here are a few more tips for formulating a strong project rationale:

* Describe the actual problem, not the causes of a problem.

* Stay solution-neutral.

* Verify the real existence and the description of the issue with the person who really experiences this difficulty himself. Don't trust hearsay and postmen.

* Avoid wish lists of items that do not solve an urgent problem. Measures will be created later based on the problems identified for resolution.

2. Establish the Deadline

The second crucial piece of information concerns the deadline for actually resolving the issue.

Too often I hear: As soon as possible!

Upon closer examination, I often find that the problem has been plaguing the organization for years, but is not taken seriously until it becomes urgent.

This is very bad, because it usually leads to missing the reasonable start date, and then the crisis is already there before the project can even be decided, because there is no time left for professional work.

To avoid this, use the following procedure:

* Pick up the issues as soon as they arise.

* Specify the latest time by which the issue must be resolved.

* Write a corresponding project into a project planning list.

* Based on the expected implementation time, set a reasonable project start date that allows enough time for a meaningful project process.

In any case, there should be a forward-looking plan that lists all current and hypothetical projects with their start and end dates. This list can and should be periodically reviewed and adjusted to reflect reality.

This ensures that you don't miss a project start and that you know how much time is available to complete the project.

Commonly observed errors:

* The start of the project is postponed, although the time is ripe, because there is no money or resources available at the moment, but the implementation date is maintained.

* The urgency is exaggerated because someone wants the project at all costs.

Be aware that delaying the start of the project will either require a corresponding delay in the end of the project, or will need to be compensated for by adjusting the project content.

3. Setting the Financial Boundaries.

Budget

At the beginning of the project, it must be clear how much funding is available.

I emphasize this point strongly. The financial framework should be clearly and specifically defined.

This information comes from the company’s overall business plan and is not related to the actual project at this stage.

Knowing the available funding allows the project to be managed as it progresses towards approval, so that the content of the project does not exceed the funding available. This results in speed and efficiency by avoiding planning loops.

The following errors are commonly seen at this point:

Error 1: A budget is set that is less than the available amount.

This is usually based on faith: If I tell them how much money is actually available, they will spend it all!

This approach is dangerous because it increases the risk that valuable project components won't be implemented or that essential quality assurance steps will be skipped. Either can reduce profitability more than the saved budget could ever compensate.

The project must be planned in a way that ensures minimal resource consumption while maximizing cost-effectiveness. It should be a given that the allocated financial framework is only fully utilized in absolute emergencies. If the project team cannot be trusted with this, it may be time to look for different people.

Error 2: No budget is communicated

The reasoning behind this approach is often:

"Let’s have the team estimate how much money they need, then we’ll see if we have that amount. If not, we’ll take the planned scope and cut the proposed budget."

This creates a highly toxic situation.

It can lead to everyone requesting as much money as they can reasonably justify, anticipating that cuts will be made anyway—so they inflate their estimates to ensure the necessary minimum remains.

Setting a clear maximum budget from the start prevents the development of concepts that are doomed to fail due to insufficient funding.

Important: This has nothing to do with the business case, which only comes into play later in the project approval process.

Product Cost

Define the product cost trend.

At the start of the project, there is no need for concrete product cost targets.

It should be clear whether:

* A reduction in product costs compared to the status quo is necessary.

* Maintaining the same product costs is acceptable.

* There is a real possibility of accepting an increase in product costs to implement the necessary solution.

An increase in product costs can be justified if it is offset by an above-average pricing capacity due to new customer value, or if other costs, such as quality costs, are significantly reduced.

In fact, this insight is automatically brought to the table when the business case is calculated on the way to project approval.

However, in my experience, this often comes too late. If the product cost trend is identified early in the solution design phase, it can help prevent mistakes.

The business case can’t be fully evaluated until the concept is ready for review. However, by that point, a considerable amount of time and effort will have already gone into developing the concept. If the cost trend doesn't align, the project will face expensive and time-consuming rework.

4. Evaluating Technology Readiness

Very often it is already clear that the problem cannot be solved with the known solutions. Something completely new is needed, something we have no experience with in our day-to-day business.

New technologies need to be understood well enough so that they do not lead to unplanned project loops.

First of all, such new solutions must be available in the first place.

Never start a project assuming that the brilliant engineers will come up with a solution technology if they just think about it for a moment.

There are departments whose reason for existence is to have such solutions ready at the start of a project.

If this is not the case, then the company has an organizational problem. I will discuss this in more detail in a separate article.

Second, the potential solution technologies must be evaluated to determine whether they can be made commercially viable in the time frame available.

A technology that is not feasible within the available time and budget need not even be selected as the basis for a concept study.

To evaluate a technology for project readiness, you can use classic project risk management.

5. Identify the Major Project Risks

In addition to technological risks, all other fundamental risks must also be identified.

The real project risk management begins after the project starts.

But before you start, you need to determine whether there are risks that could jeopardize the project as a whole.

If such serious risks exist, they must be resolved before the project starts, otherwise the project will be stopped later, and money and resources will be lost.

Are you wondering what such serious risks can be?

Here are a few examples:

* To produce the new product, a new factory must be built because none of the existing factories are suitable. But there is not enough time or money for a new factory.

* There are currently no suppliers available in the market for critical components or systems.

* The company lacks essential skills that are crucial for the success of the project.

Although these examples are hypothetical, I have encountered such risks in projects. These problems are not merely hypothetical; they truly exist!

6. Gather the Essential Resources to Power Your Project

The next step is to identify the team needed for the project, from start to approval.

* Resources must be defined,

* effort must be estimated,

* and activities must be planned.

The project can start when the supervisors of the required employees have commissioned or released them.

It would be beneficial to hold a formal project kick-off meeting.

Get together all the people who are affected in any way,

* the future project members,

* their superiors,

* the management of the affected organizational units

* and the stakeholders of the project.

Let’s all come together to collectively decide on providing the necessary resources.

7. Announce the Project Start to the Entire Organization

Now we have almost everything we need to start a successful project. There is one last requirement that needs to be met.

Communicate the project start to all affected employees.

The project team is usually much smaller in the period from project initiation to project approval than the project team that implements the project after approval.

This small team will depend on the input of many people in the organisation. Therefore, everyone in the organisation needs to be informed that this project has started.

It helps to keep everyone informed about what has been done so far, so that support can be targeted and effective.

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe if you are interested to ensure you do not miss any updates.

If you have any questions, need my help or want my advice, you can contact me in the chat.

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe