Have you ever experienced this; you are managing a project with the goal of completing a tender, but before you even get started, all parties involved have opinions about the project?
Some express, that the tendering process is essentially just boring paperwork you have to do before “the real project”. Others tell horror stories about a tendering project, where one thing led to another and the tendering process ended up spanning several years.
You note, that the means you will use to ensure a painless tendering process, involve creating clarity about the entire project course from beginning to end, including guaranteeing awareness of the fact that the strategic choices made during the tendering process, are essential to the implementation project.
Before you begin planning your management of the project, it can therefore be useful to know, that the management complexity of a tendering project is typically highest in the following areas:
Project resources and competencies
If the tender is not a ‘standard-tender’, where an item is purchased which has already been purchased many times previously, then the organization of the project can be complex. If you need to purchase a new IT-system that is able to cover several departments’ need for system support, who should then be a part of your project group? Representatives from different user groups, IT-architects, process consultants, procurement lawyers, IT-security staff etc. – the list of professional profiles can get long.
Professional competencies are one thing but articulating the content of the individual tender appendices is another thing entirely. If the project group has a hard time articulating and grouping together the content of the tender materials, outside help can be a solution.
Regardless of how you organize your project, you need to remember, that someone also needs to stay on top of the many different tendering documents, which also involves ensuring consistency between them – especially if many authors are working parallel to one another. Unless you (unintentionally) end up taking on that task all by yourself?
Stakeholder management and the end-product
The end-product of a tendering project is a signed contract with the supplier who has won the tender – this is hopefully something that most stakeholders can agree on.
Something you see a lot with interdisciplinary IT-systems, is a need for a clear matching of expectations, which includes all stakeholder-levels, with regard to compromising on the formulation, working methods and level of ambition for the demands.
It is therefore essential for you to make it clear that the contract is governing the implementation course and is not merely a paperwork exercise. This is especially important if a discussion arises about whether you require one or two weekly progress reports from your supplier. In that case, it would involve the project group actively taking a stance and not just writing two reports with the attitude that “we can always figure out whether we actually need weekly reports”.
It is necessary, that you explicitly manage expectations with all project participants and additional stakeholders and make it clear, that the project is a team effort, where everyone needs to be loyal to the tendering materials and the compromises made along the way.
If the project for instance has a reference group, who have offered input on high-level demands, that the project group has then expanded upon further, it is important to avoid, that the reference group participant threatens the project with a comment such as “no one ever asked us if the invoice-button is at the bottom of the screen”.
Timeframe for the project
A tendering project takes time to complete, both in terms of working- and calendar time. There will always be a list of externally determined deadlines which can result in a “stop-go” project, where high-intensity periods, such as periods of writing tendering materials, are succeeded by low-intensity periods such as a prequalification period.
In an attempt to accelerate the process, you typically cut down on the time which the project itself is the master of, time for market uncovering – and requirement specification, which involves that a deadline must be met right before breaks or holidays, so they are included in the number weeks, the supplier has a claim to – even when this means that the quality of the supplier’s deliverables can be expected to turn out accordingly.
Project organization
Often it can be a good idea to let the project group, who has written the tendering materials, be in charge of the evaluation of the offers and the other activities leading up to signing of the contract. This is, however, not a law of nature. If you for example are about to undertake rounds of negotiation, you might need to make adjustments to your organization. Do you also have an eye for the organization of the implementation project following the closing of a contract?
Whether you or another project manager are going to lead in this area, it is necessary look ahead. Often there is a short wait between entering into a contract and the beginning of the implementation project, and your project group typically have both their calendars and minds filled with activities during the final stretch before the contract signing, and no one has the energy to deal with the new project organization.
In these situations, it is important to think one step ahead, so you ensure, that the implementation project is prepared and ready to go – ready to pick up the baton and thereby complete the implementation project. If you have experience managing tendering projects – and would like to exchange experiences over a cup of coffee, I would love to hear from you.
