Starting a new IT project is not an easy decision for many companies. The need is often clear: processes consume unnecessary time, data is not readily available, systems do not work well together or existing applications are reaching their limits. Yet there is still the concern that a manageable initiative could quickly turn into a lengthy and expensive project.
Changes and unexpected issues can never be ruled out completely in IT projects. Requirements become more concrete once the first results are visible. Technical dependencies sometimes only emerge during implementation. Missing access rights, approvals or short-notice change requests can also affect the schedule.
Professional project management therefore does not mean defining every detail from the outset. What matters is making uncertainties visible early, continuously keeping costs in view and managing changes in a controlled way.
At COViS, this starts before development even begins. We see a typical project as a collaborative process in which an initial idea gradually becomes a concrete and manageable solution.
1. Understand First, Then Discuss the Solution
For us, a project does not start with the question of which technology to use. First, we want to understand what is actually happening within the company.
Where are unnecessary manual steps occurring?
Which information is missing at certain points?
Which systems are involved?
Where do media or system breaks occur?
And what exactly should improve as a result of the project?
To answer these questions, we work closely with the relevant business teams. These are the people who know the processes from their day-to-day work and will later use the solution, for example in Sales, Service, Finance, Logistics or Operations.
For us, consulting does not mean analysing processes for several weeks and then mainly handing over an extensive PowerPoint presentation. The focus is on concrete requirements analysis together with the customer. Business teams, IT and COViS jointly look at workflows, data, existing systems and technical constraints to build a shared understanding of the solution that is actually needed.
Future users are therefore not confronted with a finished system at the end. They are involved from the beginning.
This also helps keep the project scope realistic. Not every theoretically possible feature needs to be implemented. The first priority is to identify which requirements actually create value.
2. Turning an Idea into a Manageable Framework
Technology-agnostic consulting does not mean starting a project without a clear objective.
Before implementation begins, there should at least be a shared understanding of the problem to be solved and the outcome the company wants to achieve. If that picture is still too vague, we clarify it together first.
Processes are examined in more detail, requirements are prioritised and possible approaches are evaluated. This step is particularly important from a cost perspective: questions answered before development starts do not have to be corrected later at significantly higher cost in a system that has already been built.
Based on this shared understanding, we create an initial effort estimate. It gives the project a financial and time-related framework against which progress can be measured.
This estimate is not a figure that is set at the start and then never revisited. Throughout the project, it is regularly compared with actual progress and current requirements.
Once this foundation has been established, the next step is to make requirements visible as early as possible.
3. Show Early Instead of Developing Behind Closed Doors
An iterative approach is therefore a central part of our projects.
Instead of developing a complete solution for months and only presenting the result shortly before go-live, we work in manageable steps. In regular sprint meetings, we show progress, review requirements together and agree on the next steps.
Prototypes play an important role here. They do not have to resemble an almost finished application.
A prototype can be a clickable first version of the future technical solution, allowing users to test workflows and usability. But it can just as well be a clear functional or technical concept for an individual feature.
The important thing is to make a requirement concrete enough at an early stage for everyone involved to discuss and evaluate it.
Many requirements sound clear in theory. As soon as a workflow becomes visible or testable, new questions often arise.
Is information missing?
Is a step unnecessarily complicated?
Is a feature really needed? S
hould something be prioritised differently?
These insights are a normal part of an IT project. What matters is when they emerge. The earlier a change is identified, the easier it is to incorporate into planning and development.
That is why iteration and project control are closely connected for us.
4. Transparency Instead of Surprises
Regularly discussing the project status together with the customer should be a given. The crucial point is not whether a project changes, but how early those changes are recognised and addressed together.
New requirements following initial tests, pending decisions, missing access rights or unexpected technical dependencies can quickly affect both effort and schedule. This is the real reason for regularly comparing the original plan with actual development.
We do not only look at progress. We focus particularly on the factors that could create additional costs or delays. If they become visible early, priorities can be adjusted, scope can be changed or the plan can be revised before a small deviation turns into a larger project issue.
Some of these risks, however, do not originate in development itself.
5. Collaboration Also Determines Time and Budget
IT projects often depend on contributions that only the customer can provide. These may include system access, certificates, test data, internal approvals or specific contacts.
If these prerequisites are missing, implementation may not be able to continue in certain areas. In the worst case, this can cause delays of several weeks rather than just a few days.
That is why we clarify at the beginning of the project what both sides need from each other.
Which access rights need to be available and when? Who provides which information? Which decisions need to be made at which point? Which responsibilities lie with COViS and which with the customer?
Holiday periods, internal approval processes or fixed release windows can also be considered early and appropriate buffers can be built into the plan.
When information is available on time, contacts are easy to reach and decisions can be made quickly, technical implementation also becomes significantly more efficient.
We therefore try to establish direct communication channels before implementation begins. Shared Teams channels and short, regular exchanges can prevent a simple question from turning into days of email or ticket ping-pong.
In complex projects, the human side of collaboration is therefore not a soft factor. It has a direct impact on speed, effort and ultimately project costs.
Alongside good communication, there is another important lever for making the best possible use of available project time.
6. Standards Create Time for What Is Truly Individual
An individual IT project does not mean that every organisational and technical task has to be reinvented each time.
We standardise recurring processes where it makes sense and then adapt them to the specific project.
This includes structures and templates for project and release management. Once the length of a development iteration has been defined, for example, subsequent steps such as testing, patches, approvals and production deployments can be planned in a structured way.
Automation and supporting tools also help make recurring tasks more efficient. Where appropriate, this now includes AI. It can assist with preparing release notes, structuring documentation or translating technical requirements into language that is easier for business teams to understand.
This translation between different areas of expertise is important in day-to-day project work. Development, business teams and project management often look at the same requirement from different perspectives.
These tools do not replace professional review or personal collaboration. They simply help reduce the amount of project time spent on recurring administrative tasks.
For us, standardisation therefore does not mean handling customer projects according to a fixed template. Instead, it creates more time for precisely those requirements that are genuinely individual to each company.
An IT Project Does Not Have to Be a Leap into the Unknown
Even with good planning, a software project will never remain completely static. Requirements change, initial tests generate new insights and technical conditions may prove more complex than expected.
Professional project management therefore does not try to prevent change. It ensures that changes become visible early and that their impact remains transparent.
The process starts with a shared understanding of the requirements. This provides the basis for an initial time and budget framework. Prototypes and short development cycles make progress visible early. Continuous project control helps identify deviations before they become larger problems. Clear responsibilities and standardised processes further reduce unnecessary delays and effort.
Most importantly, customers should not have to wait until the end of a project to find out whether time, budget and results still align.
Throughout implementation, they should be able to see where the project stands, what happens next and how new decisions affect effort and planning.
That level of transparency turns a difficult-to-estimate IT initiative into a project that remains manageable step by step.
