We have already touched on the topic of digitization in several articles. But how do you implement this appropriately as a company when all IT employees are already fully occupied with ongoing support and employees in other departments also have no time for projects?

1. Start the digital transformation with the infrastructure and bring it into the cloud.

Often at this point I hear arguments such as "that's too insecure" or "that's too expensive" or the other day an acquaintance said to me "but you must have read that a data center of a cloud operator burned down and the data of hundreds of companies was lost".

Upon closer analysis, it mostly turns out that these arguments do not stand up to closer scrutiny.

Let's start with the last point, which can be somewhat compared to fear of flying. Of course, it is true that every now and then a fire breaks out and destroys production facilities and thus servers. If this happens once every few years at a cloud provider, the media are full of it. If it happens at a company that has the data in-house, you read about it in small print in the local section at best. Flying is and remains safer than driving, and the same applies to outsourcing data. By the way, reputable cloud providers mirror the data at two geographically different locations, a luxury that unfortunately does not exist when it comes to flight safety.

The same applies to the topic of data transfer. Of course, it can never be ruled out that a corrupt employee at a cloud provider sells data to the competition or that a hacker cracks a cloud provider. However, cloud providers live on the security of data, so they invest a lot in security and also in background checks of their staff. Hackers always take the path of least resistance and a non-IT focused construction or real estate company is always an easier victim than a specialized cloud provider.

In terms of price, it is correct that software purchases seem to pay for themselves after just a few years compared to cloud solutions. However, ongoing maintenance and support costs as well as flexibility are not priced in here. A detailed analysis of under what circumstances the payback periods shift and how would go too far at this point, but construction companies like real estate developers should ask themselves two simple questions:

First; do I really want to have an IT firm in my company just to possibly earn a few percent here? (if so, consider whether you really have the right people for this), and

Second; especially as a construction company, from a financial point of view, you don't live on the high margin, but (ideally) on the fact that you earn it with very little capital investment (see also my blog on the optimal EK share of a construction company). So do I really want to tie up capital in software investments?

My honest advice; focus on your core business and leave side shows to specialists.

This does not mean that construction companies or real estate developers should not have in-house IT resources, on the contrary. But they should add value to the business and drive much-needed digitization, rather than doing software updates.

Give your IT the role it should have in 2021, namely as a competitive factor, not as the nerds from the early 90s.

I usually avoid concrete product promotion in my blog posts, but Microsoft 365 with Sharepoint and Teams have done really well, especially regarding the important topic of collaboration, and no company can manage without Word and Excel anyway. Take advantage of these achievements and use this opportunity to bring the rest of your servers, your telephone system and similar standard equipment into the cloud.

2. Once you have your infrastructure in the cloud and your IT staff has time, turn to applications (ok, you may need to make some staffing changes at this point).

In application development, a strong trend towards agile development methods has emerged in recent years. This was and is due to the annoyances and cost overruns that projects processed according to the waterfall methodology often entailed. As annoying as the often annoying queries from IT staff in the course of a load specification are and as unpleasant as project cost overruns are, it would be fatal to believe everything the sellers of agile methods say.

Of course, it sounds like music to the ears of an overburdened manager when the consultant suggests to him that "a man of his stature has everything in his head after all and that he doesn't need to write any specifications. He simply tells the programmer what he needs in a relaxed atmosphere and the programmer then implements it".

Honestly, if something sounds too good to be true, it usually is not.

This does not mean that agile methods are not absolutely justified, but as a certified scrum product owner, who has also written classic specifications in the past, I take the liberty of taking a differentiated view of the topic.

But let's start with two recommendations detached from the discussion waterfall vs. agile project management.

First, I recommend the template approach, which is often sold as an agile methodology per se, in which one starts from an already finished standard product and then adapts only those points that need to be adapted. In the light of day, the battle for productivity is decided in only a few processes. I am convinced that 2 construction companies or even 2 real estate developers can have 97% of their processes the same, one is highly profitable, the other is fighting bankruptcy.

Standard software makes absolute sense, but it would be quite conceivable to write a "difference specification".

Second, when introducing new software, I recommend making sure that the vendor has mastered the art of automated testing. Testing the entire system manually after every change simply does not belong in the 21st century.

But which approach is better suited to meet the requirements of the construction and real estate industries?

A generally valid answer is difficult, but some tendency statements can be made.

• • Agile methods have advantages when the look and feel of an application is in the foreground (front-end development).
  • Agile methods have advantages if the requirement is still a moving target at the beginning
  • Agile methods have advantages when the speed of the project is in the foreground
  • The writing of requirement specifications is advantageous if a lot of calculations or many legal specifications must be represented in the software
  • The writing of requirement specifications is advantageous when IT resources are the scarce commodity in the company

My advice for a concrete decision: Have the project plan incl. resource planning by roles set up twice (agile and waterfall) before a large project, ask your consultant specifically what effort will be lost/added for which role in which setting and discuss both scenarios in the presence of the consultant and your own IT people.

If the consultant does not have plausible answers to the above questions, he is the wrong person and just wants to sell you something. And if your IT has a say in the approach, it will be motivated and will implement the project in the best possible way.