Roland Dürre
Sunday January 15th, 2017

PM Camp Meeting 2017 – #pmcamp – Jan, 20th, 2017

It is certainly not breaking news, but next Friday, we will have our 2017 PM Camp meeting.

Once a year, the representatives of all organizational teams for PM Camps meet. This year, the organizational team Dornbirn (Eberhard, Marcus, Stefan, Roland), are the hosts. InterFace AG supports them logistically.

Consequently, representatives of the organizational teams for the PM Camps at Barcelona, Berlin, Dornbirn, Hamburg, Karlsruhe, München, Rhein-Main, Stuttgart and Zürich will meet on Friday, January, 20th, 2017 between 8 a.m. and 4 p.m. in the Unterhaching InterFace AG building.

The PM Camp meeting is traditionally where strategic questions concerning the future of the PM Camp movement are discussed. Consequently, the goals of the meeting are:

  • Looking back:
    What was the development of PM Camps over the last year? 
Reports about format experiments in 2016.
  • Status Quo:
    Where are we now? What is CURRENTLY important for us?
  • Looking towards the future:
    What do we have to be careful about and what do we need to actively promote to make sure that the PM Camp movement continues to give relevant impulses for the PM scene on the whole?

I am telling you the date because I want to enable all friends of the PM Camp movement and visitors of PM Camps to voice their opinions and ideas during the PM Camp Meeting.

If you have suggestions that might impact the future of PM Camps, please do not hesitate to send me an email. I will collect all emails and introduce the ideas during our meeting.

I look forward to many impulses by and inspiration from you!

RMD
(Translated by EG)

P.S.
On the evening before (Thursday, January, 19th, 2017), those who arrived early will meet for dinner at 7 p.m. at the Unterhaching Althaching restaurant. If you feel like meeting old friends, please come and join us.

Roland Dürre
Friday July 8th, 2016

Can We Reduce Complexity?!

A short time ago, I integrated a knowledge proposal (Wissensangebot) by Thomas Kleiner into IF-AGORA. The message was:

“How to reasonably reduce
complexity
without making it trivial!“

Thomas offers seminars to managers that enable them to come to better terms with our complex world. And basically, he is always sold out.

I also twittered his new proposal. I gave it the title “How to reasonably reduce complexity!“ In no time, received feedback came in, for example “this statement is a complete #fail“ or “well, I look forward to seeing how that is supposed to functionl“.

Unser Kater Lenin, genannt Wladi.Sein Bruder Stalin, genannt Joschi, ist ausgezogen.

Our tom Kater Lenin, aka Wladi. His brother Stalin, aka Joschi, moved out. A very complex animal, not just biologically speaking.
Owner:
Barbara Dürre (cat)
Maresa Dürre (photo)

Well, you need to know that, on the internet, there is an intense discussion about the difference between “complicated” and “complex”. There was even a PM-Camp about project management in Berlin that tried to define the two terms.

Project managers had quite heated discussions about how to differentiate between complex projects and complicated projects. Also about how to solve those problems.

Personally, I can only speculate that dominant logics will not help either in a complex world. But then, where is the surprise? After all, it even often fails in very simple worlds and with merely complicated projects.

Incidentally, I very much appreciate one of the protagonists involved in the discussion about “complex versus complicated”: Niels Pflaeging. Although I always doubt if his analyses are correct, I certainly wholeheartedly believe in his conclusions.

Back to the knowledge proposal. You need to know that Thomas Kleiner is a wise philosopher. His diploma thesis is about “The Concept of Humanity in the Work of Rupert Lay“. It was not the only reason why he studied “constructivism” – and, as I see it, he actually understood it.

The theory of “constructivism” made me even more convinced that the categorization of a system or project as complex or complicated only happens in the cognitive awareness of the listener.

I also think the complexity and complicatedness cannot be understood or measured with scientific methods or metrics. It is a philosophical topic, or, as they used to say, one of “metaphysics”.

For us, “complex” is just as hard to understand as “endless”. Complex is something you cannot rationally define. I only know metaphors that are supposed to express complexity, but not a single one of them can serve as a valid, comprehensible and objective definition.

Consequently, I think the “reasonable reduction” of “complexity” is absolutely goal-oriented and possible. After all, it concerns the subjective perception of what seems to be reality and the way we deal with it. And, of course, I also think that you should never ever trivialize complexity.

No. Complexity is something you should enjoy and relish!

Here is an example:

I need our tom-cat to illustrate what I mean. Officially, his name is Lenin. However, the family calls him Wladi because they do not like the name Lenin. Unfortunately, his brother Stalin (the family called him Joschi) moved out. He no longer got along with Lenin .

Tom-cat “Wladi“ Lenin is certainly a very complex system, just like all mammals. I will reduce his complexity by just referring to him as cat or pet. In this way, I can make use of a lot of experience humanity has gained in dealing with cats without trivializing the animal. In fact, I might even like him and be able to find his activities conclusive. Regardless of the fact that I will never understand the complexity of a cat.

Persons who think you (HUMANS) could know and realize anything you set your mind to actually scare me. They try to change “complex” system with great speed and harsh measures. My fear increases when these measures are about our environment (nature) or our health (also nature).

I witnessed the tragic fate of quite a few elderly persons. Medicine made their last years absolutely miserable because it tried to heal them with scientific rationality. It would have been so much more helpful if they had just applied the rules of reason and reduced and simplified many processes.

To me, it seems like something similar is currently happening to our planet.

Far too many persons believe you can categorize the world into complex and complicated and thus change it for the better through rationality. As I see it, this is some kind of “omnipotent mental decease”. And I fear that, as often, “the chickens are counted before they hatch”. Except that it will take a lot longer for us to realize this.

RMD
(Translated by EG)

Roland Dürre
Friday March 11th, 2016

“Inspect-and-Adapt“ Your Estimates!

td-logoI always like visiting the Munich Techdivision. For me, this event, organized by my PM-Camp accomplice Sacha Storz, is very attractive. The next event is on March, 16th, 2016, between 7 and 8.30 p.m. They finish earlier than usual, because they want the visitors to have the chance to be back home in front of their TV sets for the Bayern Soccer Game. The location is the TechDivision offices at 73, Balanstr. (building 8, 3rd floor) in 81541 München.

Here is the official call for participation:

According to estimations by User Stories, project planning still plays a central role in agile software development. Imprecise estimations will, for instance, cause higher costs than planned or a longer production time than originally agreed upon.

During a TechDivision study, we investigated the User Story Estimates in four different projects. The goal was: identify problems and propose improvements. It is a rather well-known principle – after all, there is always an “inspect-and-adapt” framework in Scrum.

But: how can it be adapted to estimates? And how are the results of the study related to the #NoEstimates discussion?

I find the topic rather interesting. After all, I am a supporter of the provocative theory: “don’t estimate“– and I can find numerous reasons for this theory. In addition, I find it quite motivating that my own son Rupert will be the speaker.

About the speaker:
imagesRupert Dürre is a consultant at the Swedish IT company Netlight. His interests are various areas of agile software development in requirement engineering and development practices, such as also the question how to organize teams in order to make an effective cooperation possible.

Note:
There is no admission fee for the event. Please register at the website: event.

Well, next Wednesday at 7 p.m., I will be at Balanstrasse and I look forward to seeing many friends!

RMD
(Translated by EG)

Hans Bonfigt
Monday December 28th, 2015

(Deutsch) Ganz agil vorbei am Ziel

Sorry, this entry is only available in German.

Roland Dürre
Thursday December 3rd, 2015

First a Norm, then a Certificate.

Or:
Why I believe that “certifying things” is often nonsense.

Created by Barbara Dürre

Created by Barbara Dürre, a certified certificate producer 🙂

In order to make life easier, people scale the world. They make certificates (Zertifikate) that prove how objects of this world follow or have been generated according to a certain standard.

The DIN is certainly a positive example (initially: Deutsche Industrie Norm). It was started by a club/association of industry partners. This standardization of technological items certainly brought considerable progress.

I am sure this made a lot of sense. The same is true for a common “metrics” in Europe or even world-wide for characteristics of objects (distance, weight, size, volume, etc.). or states (pressure, speed, temperature, time, etc.).

After the “standardization” comes the “certificate”. Stating a reliable and tested actual measure for an object is the simplest form of certificate. You can say:

There can only be a certificate if a standardization has been done before.

Wherever people are successful in a field, the underlying method will also be applied to other areas. Even if, perhaps, it does not make sense. For instance because everything that is alive cannot be reasonably standardized like a dead mass.

Brussels (the EU), for instance, now not only certifies plants and fruit. No, there are many areas – and I mean areas where it cannot be done – where they standardize and certify endlessly. For example, we have a cucumber norm and sustainability (including the certificates). Institutions and associations of all sorts also take part in the “standardizing”, using all imaginable areas for any purpose at all.

Mostly, they start with writing down collections of (allegedly) best practice. You will have won if you managed to introduce an obligatory ISO norm or some such. And then they start teaching the auditors and doing audits.

But do we really want to standardize humans, their interactions and their lives? During the last few decades and centuries, metrication and measurements have been applied to humans, nature and social systems.

Now enterprises have to have certifications saying that they function “correctly”, even though they consist of human beings. “Correct” is defined as something that follows the logic of an often very complicated and contradictory standard. And everything else is “wrong”. And more often than not, people totally forget what was intended or what was initially the problem.

They even wanted to extend the concept and include families. In the 1960ies, they discussed if people should be allowed to marry without a marriage licence. They also demanded a father or mother licence if you wanted to become parents.
(Incidentally, driver’s licences, too, are just certificates). To be sure, the intent was well-meant: they wanted to improve the situation of children.

At the time, I cynically thought how it would perhaps be desirable to also certify sons and daughters, since fathers and mothers were under consideration. After all, children should behave according to standards, shouldn’t they? Well, today, this concept became a little bit true: schools, for instance, generate their curricula following the standard child image – without ever considering how different children are.

I am glad that, in the end, the parent licence did not come after all. Regardless of many children, unfortunately, still living in rather sad conditions. However, the “parent licence” is an excellent example for the limits of standardization and certificates.

So roles in the family are not yet certified. Yet in other social bodies, they try to standardize away – for instance in enterprises when it comes to management. Just think of project, knowledge, quality management, etc. And I am sure that, sooner or later, the BGM (business health management), the common good economy and the CSR (Coporate Social Responsibity) will be certified. And, of course, before they certify them, they have to standardize them.

In my book, social systems with humans acting therein are something that nobody should try to standardize. Standardized social systems give me pause. Also, I do not believe that leadership and management can be standardized. But how can you certify something that cannot be standardized?

But let us stick to project management: 
It will not be possible to standardize PM in a rational way. So how to certify it in a rational way?

Basically, it is a pity, isn’t it? After all, they say that project managers too, (like, for instance programmers) should again learn from their masters and from practicing a lot in order to become experts – just like craftsmen.

You can get titles with money, through finishing an expensive course and by learning a lot by heart. But you will only become a master through sweat and industriousness. And it is quite possible that, in the future, only the masters will be wanted.

RMD
(Translated by EG)

P.S.
Incidentally, it is quite well worth the effort doing an internet certificate search. I was literally beaten by the multitude – also by how absurd many of them are. I will refrain from giving examples, there is no end.

CLOU/HIT at InterFace Connection

Or:
How Wolf and I eventually ended up doing it ourselves.

During the Berlin PM Camp, I related the stories of four projects from my vintage time. They were all very important to me. And I told you here  that I was going to describe them all in the IF blog.

if-logoProjekt 4

Now comes the story of my fourth project:

Even before 1983, I was fed up with working for others. At the time, I was still a Softlab employee. This is where I learned to extend my one-sided competence – with the exception of a little SNA (IBM), it was mostly Siemens technology – and learn more IBM technologies. In particular, however, I was able to learn about the different systems of the “intermediate data technology”.

I am talking machines which, dependent on their storage unit, consisted of two to three parts and had the size of Bosch refrigerators. That means they were a lot smaller and also a lot simpler than mainframe. At the time, those were especially fashionable. Consequently, there was an enormous amount of European and non-European competition with differing and often very proprietorial technology. Kienzle and Nixdorf were also among those aspiring MDT enterprises. And in those days, even in a city like Munich, the same software was developed synchronously in different enterprises for different technologies.

I am sure that Softlab was one of the most innovative German “software houses”. They, too, had a proprietorial system, the famous PET-Maestro. For me, this was the first system without the permanent frustration of data loss, because the Pet-Maestro already worked in symbols – and every symbol was immediately transferred to the hard drive. Consequently, you had a current warm start with every reset – and nothing was lost! It was such a relief to finally no longer have to fear data loss at all time when working, for example, with EDT or EDOR.

On other fronts, I also learned a lot of new things at Softlab. This is particularly true for the business sector: how to formulate an offer so that it contains the least possible risk, how to talk with the VB-s of the big enterprises (Bull, ICL, IBM, Nixdorf, Siemens – even at that time, nothing was going without the big ones), or how to write studies.

This is how I became a paper tiger (totally unrelated to paper tiger, the famous Chinese theatre movement). And in those days, it was (still) true that you got better pay per hour as a paper tiger than as a programmer. Thus equipped, I wanted to do it myself. Yet I did not dare to start all alone. So I went in search of a partner. I looked for and identified persons in my vicinity who I found nice and competent. And who perhaps also wanted to found a company. There were quite a few. But again and again, nothing came of it.

Until Wolf (Geldmacher) came. Wolf was considerably younger than I. Technologically, he was super. And our view of things was similar. Meaning that our values, expectations, interests and needs complemented each other. I was more the old style programmer – and Wolf had the knowledge about everything that was modern and new in IT. Also, Wolf knew absolutely no compromises when it came to quality. And if anybody had common sense, then it was Wolf. And I guess those are the most important factors: competence, common sense, quality awareness. Then you only need to be a nice guy…

Consequently, we founded the short version of InterFace Connection. We inherited the InterFace from Peter Schnupp, the “Connection” was our own contribution. That is what we wanted to be together with our employees: a “connection” that sticks together and later shares its success. We founded the enterprise in 1983 and started business on April, 1st, 1984.

But then, the enterprise is not the project I want to talk about. The project was about developing a product. And there were two reasons why Wolf and I wanted to have a product: firstly, we were convinced that a product would be something to be proud of. It creates an identity. Secondly, a product is easier to scale than a service.

Besides, in our eyes, the then well-established concept of “body leasing” did not have a future. Basically, we still believed in the law and as founders, it was pretty obvious to us that the common form of body leasing was exactly what, according to the AÜG, was simply illegal.

It did not take us long to become quite convinced that, in those days, Unix was the best basis for future products. Also, we agreed without hesitation that, basically, everything you needed for using computers was still missing in Unix. And in particular, we saw that a text system was sadly missing. And that the first thing you would have to develop rather quickly on Unix with its new data displays (in raw or cooked mode) and especially with the language c was a comfortable typewriter.

Since we had a huge amount of respect for the production and successful marketing of a product, we started the development of the product in cooperation with InterFace Computer. It did not take long before we had a small success in the SINIX (the Siemens Unix) environment. Consequently, the development of the product was moved to us and the InterFace Computer was put in charge of the ports and the sales on the “remaining market”.

And in no time, we also had a two-digit number of team members, all of them very young. In general, they were students. They had to have programming competence and be nice. And they had to cope with the work, regardless of their double burden of studying and working. Nothing else mattered to us.

Since Wolf and I (along with a few young employed computer scientists with academic diplomas whom we got through aforementioned body leasing and whose hours cost between 150 and 120 DM) financed the entire development, the young persons were rather free to come and go as they pleased. The only control was our assistant Heidi (Kaindl). Heidi was quite in charge of all the young persons, taking good care that everybody actually worked. The only times Wolf and I met them was during meetings (soon after our foundation, women, too, were employed).

In those days, Wolf had the role of SCRUM-Master and more (even though the word SCRUM did not yet exist). He told the team about quality. And that, first and foremost, they produced quality not for our customers, not for our sales partners Siemens and not for the InterFace Connection. Instead, being honest programmers, they needed to produce quality in their own interest. And Wolf had rather high standards and was very strict. If someone was not able or willing to deliver quality, he or she had no future at the “Connection”. But Wolf also protected the team, for instance when I tried to limit resources. And he made sure that we invested were necessary.

My task was perhaps that of the Product Owner. At least in the beginning. When I had been a young boy, I had been forced to learn stenography and typing. I used to love stenography, because it is a beautiful way of writing. It does not hurt your hand, as normal writing does. But I hated the typewriter. And I knew exactly how a good editing machine would have to look. I had also written it down in the time of our foundation.

When things got more complicated and, for instance, CLOU with its “embedded sql“ was added to our repertory, I transferred the role of Product Owner to our customers. And that was one of my best decisions ever. Because the customers actually were able to tell us their ideas about an automated chip processing. They showed us how to continue on our way.

One of our rules was that all employees – with the exception of Heidi – were able to program. Heidi was our first and most important customer. As soon as the first HIT version was available, we confiscated “nroff-makros”, her “office vi”, and she had to use HIT – which, incidentally, she did not appreciate at all. After all, the vi solution had not been so bad. Later, however, she learned to love her HIT. Surprise, surprise! After all, she was one of those who built it!

All other colleagues on the HIT team had to work hands-on. In other words, all of them had to be able to program, find errors and, above all, co-work (team work).

We were very early users of tools that would be commonly used a lot later. But this was only true for tools that actually made sense, such as “lint” for the quality control of our code or “sccs” for the source code administration. I am pretty sure that, time and again, we were the first in Munich. We were also earlier than most of the others using a “tracker” and an automatic “built”. But we never used planning software. Just as we always took pains to avoid “bureaucrazy”.

So all of us involved in the project were programmers. And we actually always coordinated in the team who was going to develop what. The personalities of the people involved were very diverse. But then, we also had the magic programmer. It was not entirely in jest that we called him “God”. But the first rule was that we were a team. Everybody helped everybody. Our motto was: “one for all, all for one”. Nobody was ever left in a lurch. And whenever you did not know a way out, you asked your colleague. Pair-programming in the strict sense did not exist, because it went without saying that this was practiced quasi automatically. Consequently, there were always several persons who knew the sources of the others. It was like an overlapping system that worked well some way or other without many words.

Of course, we had a rather complicated system with an awful lot of modules, interfaces, tools, API-s in our development. In total, a huge number of lines of code was produced. There were modules for the virtualization of keyboards, terminals or printers. We had developed the first National Language Support. Later, it became part of the X-Open UNIX implementation. We had complicated modules and modules everybody feared, as well as boring modules. Once in a while, we also had to find errors in the compilers we used.

The team always decided among themselves who was going to take on which task. Everything was part of the project: our value bank, mostly constituting of OpenSource components for source code administration, for the Built and the partly automated test, for the ports to the many end systems the Unix world then offered. Even producing the customer newsletter HITNews, which at the time was printed four times a year and determining the structure of the courses were part of it. Everything was done together, everyone .gave his best.

Naturally, once in a while there were situations when perhaps someone was unable to cope. Because maybe he did not yet have enough experience or perhaps he had underestimated the task. But then a colleague would help. The right person was always available. And when it was really necessary, there was still “God”.

Of course, everybody had his own role in the team. Each of us was a project manager and as such responsible for the appointments he had made. Some had more, others less. Each of us was a quality manager. Some more so, others less. Of course, there was something like a first contact for our customers and our partners. It was always a mutual decision (“who is the best for this job?”), but he remained in the team as a programmer. But, basically, every developer answered the questions of his customers. After all, they simply came into our office. The central bell rang, and whoever was the first to answer the telephone was talking to the customer.

Naturally, some of the colleagues were more concerned with integration, planning, configuration and the built-theme, the manual, … But every one of them was always fully integrated into the team in terms of technology.

But everybody always went back to programming. And everybody was responsible for top quality. For instance because they built automatic test environments simply as a part of the project. The responsibility was totally shared.

With the success came the necessity to have teachers for our product HIT/CLOU. During the first few years, all the developers also taught the courses. This was true for teaching the end users, the special users, the systems engineers, the operators and the programmers. Even the central persons, like Friedrich Lehn, the “father” of CLOU, taught courses where beginners were instructed on how to program CLOU.

There were instances when the developers did not appreciate this. After all, developing is much more important, isn’t it? But the courses were quite popular (because, after all, the colleagues knew what they were talking about, which certainly counterbalances the occasional “didactical” weakness). But the great thing about it was that our colleagues always knew exactly what the customer wanted and needed! This is how the customers as a whole became the Product Owners.
Due to these inter-disciplinary tasks, our colleagues grew both in technological competence and personality at enormous speed – that is also true for sales competence. More often than not, it was unbelievable how young students became experts with a huge self-esteem after a few months.

Without ever saying it out loud, we on our team understood even at that time that it is all about making all the persons in the team and in the enterprise look biggger instead of smaller. And to make them be part of everything and share everything. We knew that we often had to have really steep goals, often even bold goals. Otherwise, we would never have managed our product. But we also knew, especially in this situation, the importance of living a strong error tolerance.

The colleague in the team or the customer must never ever be the enemy or adversary. Instead, the only enemies were the challenge or the detrimental circumstances.

Wolf and I were the “management”. But we were more like visitors in our enterprise. After eight to ten hours with customers every day, we came back to our employees at home in the office for recreation. They were all our friends, it felt good to be near them. And they showed us all the great things they had, again, created. We gave our feedback and then disappeared to our next day of consultancy.

And whenever a nice result was achieved, we all celebrated. It was the best time of my life. We learned so much. We also learned that thinking normal and conservatively is often nonsense. For instance, I always wanted to deliver to our customers on time. And I had to learn that this is utter nonsense.

Because if you want to create something really innovative, you will learn again and again that deadlines do not make any sense at all. It simply will not work. If a deadline can absolutely not be met, then all that matters is a functioning communication and looking for a solution that satisfies the customer. Because when they are all in one boat and want to be a success together, then there is always a solution – and we found out that it can always be done.

I already hear your objection: 
Well, it might work for a small project. But what about a huge project?

To be sure, we were perhaps less than 50 persons. But the very same projects had failed with more than one huge concern. They had often used five times as many persons as we or even more. Expensive, experienced and highly qualified ones. But it did not work.

I believe it can be done in the same way if you have a huge or even a very huge project if many such great teams are linked and cooperate with good-will.

RMD
(Translated by EG)

Or:

The First Time I Experienced True “Project Management”.

During the Berlin PM Camp, I told the stories of four projects from my vintage timethat were very important for me. And I also announced that I was going to write about all of them in the IF blog.

Project # 3

So here comes my story of the third project:

Fernschreiber (Siemens T100) - eingeführt im Jahre 1958 - moderner Nachfolger des T50

Fernschreiber (Teletype Machine (Siemens T100 – 1958), the modern successor of T50

After my change of positions inside Siemens away from UB D WS DF 131, I shared the technological responsibility for a relevant and absolutely innovative huge project called DISPOL with a new colleague working with whom soon became my true pleasure.

Siemens had won the bid for replacing the telex network of the Bavarian Police Force by a trans-data network based on modern circuit switching. At the same time, the card index boxes were to be replaced by a database in a central host (mainframe – it was a BS 1000 system). Also, modern display units were to substitute the old teletype machines.

That was roughly between 1979 and 1981. I was still a regular Siemens employee, but I had just fled the “bureaucracy” that had started at the development department of Transdata/PDN, looking to have better luck with sales at UB D V S 3. That was short for “department data processing, sales and special projects 3“.

See also my article on Vintage Projekt #2.

My move from the laboratory to the special projects necessitated that I now had to leave the private environment I had learned to love so much and found so nice at the Ortenburgstrasse (near Siemens Hofmannstrasse) and go to Neuperlach. And it did not take long for me to understand why the new building near the Neuperlach S-Bahn station was spitefully called “data sibirsk” or “Lego City” by many people.

For me, it was even worse: I had to move into a cold skyscraper surrounded by a fenced area that reminded me of barracks. Concrete and cold high-tech were the dominant features. And I also felt billeted. The only thing that looked halfway human in the entire areas was a fruit vendor who offered his goods on a stall inside the compound.

From day one, I felt uncomfortable in the concrete bunker that only looked colourful from the outside but was rather grey inside. Mind you, this was regardless of the fact that you actually could still open the windows and that there were quite a lot of green areas inside the fenced region. Yet, even the green was domesticated in a very prosaic way – it did not look as nice as you would, for instance, imagine it on castle grounds. Instead, it was techno-utilitarian.

But I was lucky. After all, I belonged to “special projects” – and they did not happen in the office. They happened outside, in the world. And since I was quasi equipped with privileged information, I felt like I was my own master and a little king.

Consequently, I preferred to mostly be where the customer resided (Bavarian State Office of Criminal Investigation in the Maillinger Straße) and to hardly ever be available in Neuperlach, except when it was absolutely unavoidable. To me, the rooms at the police station, regardless of all the very strict security regulations looked a lot more human than the new Siemens AG high-tech venue.

My flight from the “laboratory” that had fallen victim to bureaucracy had been a success and now I was allowed to experience real life. And the project DISPOL was a great thing. A total innovation. Together with the excellent partners of the Bavarian Police, we were a wonderful team. We cooperated with a maximum of efficiency and at eye-level. But I have to say that the project was already well under way at the time I became part of it.

And there were a number of birth defects – in all imaginable dimensions of the project. Consequently, the first thing to do was overcome a series of hurdles. We had a totally stupid design which had already been partly implemented (they wanted to realize a fixed system, which was totally against the dynamic connection technology), there were diverse architectonic mistakes with both the hardware and the software that had to be corrected quickly (systems with no local storage for quick reload, inadequate testing environment,…), the total absence of a component that had been promised (one example is the telex port which was quite good at doing the protocols of the postal service, but not for the police, who were “electronically” different) and many other “normal” challenges you meet when you are doing something for the first time.…

And there was also a requirement in the contract that was rather hard to meet. Because the new product DISPOL was supposed to replace a teletype machine network. And these kinds of teletype machines had (at least in Bavaria) an availability of a hundred per cent over years, if not decades. In other words: they NEVER broke down.

And, of course, that is what the customer expected of the new solution, as well. Justly?! Since, (at the time), Siemens was, of course, not stupid, they had negotiated in the contract that the system at least did not have to be a hundred per cent available. Once in a while, it was allowed to break down. Perhaps they had a hunch that electronic data processing had its limits. But then, it said “once in a while”!

Consequently, it had been written in the contract that the product was only considered functioning if the system ran a certain amount of time (I think it was two weeks) without interruption and that the “down-time” during this time had to be only very few hours (I seem to remember it was only one).

The only problem was that re-starting our computers also took a little more than one hour. Which meant that even if one single system shut down, the two weeks started anew and thus all attempts at delivering the product were in vain after a few days, or at the least a few days before the deadline…
(Note: we solved even this problem. If you are interested, I will gladly tell you how).

Basically, there was always a shut-down, because we had a number of sporadic and hard-to-reproduce errors, one of which would always occur shortly before those four weeks were over. Well, we just had to isolate them individually. But then, isolating errors takes time. Because you have to implement traps that catch the error and make it reproducible. And due to the contract, we did not have this sort of time.

Here is a note that might be interesting:
The test was designed in such a way that the normal police procedures ran twice during the acceptance phase. The real run with the real data continued with the old technology of the well-functioning telex network. But then, the original data (punch strips) ran on the new system 1:1 after a little time had elapsed. For testing. To keep up appearances, critical data were made anonymous and less drastic, but this was not always possible. And (of course), nothing happened. We all knew that those were highly sensitive data and that we had a lot of responsibility. Today, the gentlemen of data security would probably make a huge ado about it.

But back to the topic: 
The stability problem of the system only arose during the end phase of the project (which had already gone on for quite a long time). Due to the aforementioned factors, there had been some problems earlier, as well.

Consequently, our management panicked. That was also the reason why they had made me join the project. Then they understood that there was a lot left to do and we got additional resources: consultants and young persons who had been sitting around somewhere in the concern and had not known what to do with their time. And:
A project manager was installed!

Let me first tell you about my experiences with the consultants and young persons, later about the project manager.

The Consultants

There were several of them. They were supposed to help us, but that was not really what they usually did. I particularly remember two colleagues from the PSE (that is the Austrian Siemens daughter for software development). One of them was from Vienna and the other from Graz. They both held doctorial titles, one of them in psychology, the other in physics.

They were both really nice persons. They were both not happy to be far from home. The one missed beautiful Vienna, the other Graz. To me, they both seemed extremely intelligent, if not ingenious. Both had first names beginning with an M. and both had not much knowledge about the system, and even less an idea what a good code should look like.

Yet I never told them, because I really rather liked them. Consequently, we let them play along, which they both did quite well. Except that they never really made their way to the middle of the project. One of the reasons was that, in this project, they were like mercenaries, “away on a construction job”. Which actually does nothing to increase your motivation and readiness to make a huge effort. Consequently, their added value was not really relevant.

The young people

I remember a young lady and a young gentleman who were added to the group. Both of them were terribly young (early twenties, at the time, I was not yet 30). They both had trained in the IT sector somewhere at Siemens.

They were both highly motivated, listened carefully, did what they were told and thus they quickly understood the technology and their task. I assume that they were also quite cheap – especially compared to the two consultants with their doctorial titles – and they contributed enormously towards the project success. Incidentally, they both went on to become a success story. But not at Siemens.

Now the only thing remaining to talk about is

The Project Manager

The project manager was an earnest person who always wore ties and struck me as extremely nervous from day one. Said nervousness was easy to understand for me: after all, he was supposed to solve a problem he knew basically nothing about. He sat in our room a lot of the time writing reports. The rest of the time, he had meetings in Neuperlach. His role was something like being a translator between the worlds of management and the project that consisted of technology. Since he did not know the language of technology, he never understood the project. I assumed that he did not know the language of management, either. After all, during my time at the laboratory as a supplier for a huge project, I had learned some of it. He was a lonesome wanderer between two worlds.

Our project manager had a strange voice and consequently, he was soon stuck with a nickname (Schnarrie). The idea had come from our two ladies (W. and C.), who did a good job with the coordination and customer service. Perhaps because they were angry about their roles having been cut down.

For us, Schnarrie had a double positive effect. Firstly, we no longer needed to tell management why we did what we did – which had cost Hans and me, and sometimes also our two ladies, quite some time and nerves. And he also had a budget! Which was something totally new for us. Consequently, we managed to celebrate several “victory parties” on the Siemens budget when we had found a sporadic bug or some such.…

So much about this. Incidentally, the project DISPOL was a huge success and ran for decades to the greatest satisfaction of the Bavarian Police Force. And in its wake, it brought quite a few good customers to Siemens AG, as well.

RMD
(Translated by EG)

Roland Dürre
Friday October 16th, 2015

Five Weeks to Go until #PMCampDOR

pmcamp-logo-dornbirnLate in 2010, a small group of entrepreneurs, nearly all of whom incidentally were also bloggers, met. They shared an idea and wanted to try organizing a project management barcamp. They called it PM-Camp (PM short for project management). The persons involved were: Kornelia, Eberhard, Jens, Marcus, Stefan and yours truly.

It was our intention to host a free meeting of persons, entrepreneurs, leaders and all kinds of “managers” in order to exchange experience and knowledge beyond conferences and workshops. Totally democratic and at eye-level. With a good mixture of female and male, young and old. In 2011, also in November, we had the first PM Camp world-wide in Dornbirn.

Time went by in a hurry. In exactly five weeks, the fifth Dornbirn PM-Camp will start. That means we celebrate a jubilee! In fact, we are a little proud of it. We are also proud about a movement having sprung from the first PM Camp. It is now thriving in many European places with local PM Camps.

For all of you, it is now about time to order tickets. Otherwise you might end up empty-handed. Because PMCampDOR is definitely something like the mother of all PM Camps – where many wish to attend.

This time around, we chose the metaphor “breaking with patterns” as our impulse. Consequently, the hashtags are #PMCampDOR and #musterbrechen.

🙂 Maybe will become and will turn into … Because you never know what is going to happen on a PM Camp.

Naturally, the Dornbirn organizational team wants to celebrate the jubilee with a particularly nice and successful PM Camp. Consequently, we want to make it especially easy for our “newbies”, meaning those guests attending their first PM Camp or even their first barcamp to really get under way. So I now point out to you a series of articles I wrote as early as 2013/2014 – but it is certainly still up-to-date. In these articles, I am telling you what happens during a PM Camp.

Here are the links for the five articles:

My continuing education story – personality promotion, seminars, workshops barcamps

(how I first was introduced to the barcamp idea.)

barcamps und PM-Camp (2) – why they are such a success.
(because they are great fun and all participants are happy when they go home.)

barcamps und PM-Camp (3) – typology and sessionsbarcamps and PM-Camp (3) –

(what kinds of sessions are there?)

barcamps and PM-Camp (4) – Twittering is part of it .

(why PM Camps and social media complement each other so well.)

barcamps und PM-Camp (5) – rules

(on a barcmp, you can have freedom, because people behave socially responsible.)

Another article is a general one:

The Story of and guideline for a PM Camp

(and barcamps in general)

And for all of you – not just for the newbies – I would once again wish to point out our values as we summarized them in our guidelines.  You will also find them in document.

I am sure it will be useful for you to take a second look at these materials. And perhaps you have a few recommendations for change, modification, improvement? The #PMCampDOR will definitely be the right stage to discuss all those things.

And here is a short Video on PM-Camp.

RMD 
- also in the name of the Dornbirn organizational team
(Translated by EG)

Roland Dürre
Sunday October 11th, 2015

Vintage Project Management #2 – My First Real Challenge

How I landed my second of many projects.

Project #2

Oben links meine damalige Siemens-Visitenkarte, auf dich immer noch stolz bin.

On the upper left hand, you can see my first Siemens visiting card – the first of a collection I am eternally proud of.

After my re-start in October 1971, I continued my university education, the successful finish of which lay in winning my diploma. Here is how it happened:

When I was in the then fourth semester in the summer of 1973, I noticed that it was about time to sit my interim diploma exams. And I noticed that, indeed, there was quite a knowledge gap.

Consequently, weeks of learning lay ahead. The weeks before the four oral examinations would be stressful. I fell victim to knowledge bulimia, a sickness widely spreading these days and actually an epidemic in all the school and university systems I know. After having passed the interim diploma as required (surprisingly even with quite a fair grade; “good”), I was rather worn-out and had to give myself some rest.

Resting was exceptionally great fun while breathing computer air at Siemens. They truly had a lot of hardware: large-capacity computers with BS2000 and BS1000, process computers, office systems, network computers and much more. I was truly over the top. At the TH – which was now called TU, because, after all, a university is something better than a college – the computing times allocated to students was rather scarce. Consequently, you seldom saw me there.

As a logical consequence, I spent more time at Siemens during the following four semesters than at the not very humane (and probably even then asbestos contaminated rooms) of the new southern TUM informatics building. Incidentally, said southern building was torn down several years ago. Just imagine that the building where I studied and which had been built more than 20 years after I was born was outlived by me. Now isn’t that somewhat strange? The old TH building is still prospering.

It was my good luck that my major topic, mathematics, could easily be studied out of books. They are a good substitute for attending and listening to lectures. After eight semesters, I noticed that there was a diploma thesis to be written before admission to the final exams. I found a professor (Dr. Werner Heise) – regardless of having been the youngest mathematics professor of all times at the TUM, he unfortunately died a few years ago – who was willing to hand me a really exciting combinatorics topic for said diploma thesis (it was about the assumption by George Polya which, however, had not yet been proved – which is how the theorem by Dürre came to be).

It was not easy, but it went well and was a truly great experience for me. I also enjoyed actually meeting Mr. Polya from Hungary on a combinatorics congress in Berlin. The trip to Berlin was especially fascinating because at the time Berlin was still a wonderful island in the middle of enemy country.

After the diploma thesis, the final exams lay looming – and again I fell victim to knowledge bulimia. It was even worse than before the interim diploma. But, again, the knowledge bulimia worked well. There came a day when, although totally exhausted, a very happy me held his diploma document in his hand. To be sure, I did not know if that was something to be proud of or not. But I was immensely happy to have finished the sad chapter “university”.

I was not in the mood to write dozens of applications or similar things. A journey around the world or even a vacation were also out of the question, and so I tried to find a job. I applied at Softlab. I found this company really great, because at Siemens, I had once read the hectography of a book by Peter Schnupp (structured programming) and I found said book a beacon in the darkness. And Peter Schnupp, whom I later met and who became a much-loved friend of mine, was one of the Softlab founders (along with the colleagues Neugebauer and Heldmann).

Consequently, I sent my first (four years later, there was a second one) application to Softlab. It seems, however, that at the time Softlab was undergoing minor crisis phase, which is why they sent me a very polite letter of refusal. It said that they actually were quite interested in me, but currently had no tasks appropriate for my skills. They also asked me to try again next year.

Naturally, that was not much help to me. But as matters developed, it turned out that, more than four years later, I landed with Softlab anyway – but that is another story.

“After finishing your university education, you have to work!” – that is what the bourgeois part of my super-ego told me. So I took the same documents I had sent to Softlab and used them to apply for a job at Siemens AG. I was optimistic, because, after all, they already knew me. And, yes, they took me – and they also had a real project waiting for me. It was part of a bigger project, which again was part of a really huge project.

I ended up at UB D WS ST DF 131, which is short for the department data processing, laboratory for systems, system technology, data transfer, 1st company, 3rd train, 1st battalion. The last three terms are my personal interpretation of 131. After all, the founder of the enterprise took the Reichswehr as a model for the organization of his company

The entire DF (which means an entire company of the Siemens army) worked on a hardware and operating system for realizing the data networks called TRANSDATA. Incidentally, I think it is another disgrace for the German IT that this term cannot be found in Wikipedia (I wanted to put a link right here). After all, this was the only and technologically superior competitor of “SNA“ (System Network Architecture) by IBM, who were our biggest and then perhaps only competition.

The Transdata software was called PDN (programmable data network technology) and we generated operating systems necessary for the data station computers, the network node computers and the mainframe model computers. Those two years were probably the most exciting years of my entire professional career. I could easily write several books about the time.

On this picture, you see a Siemens & Halske repair shop in the rear building at Schöneberger Straße, Berlin, on October, 19th, 1846 (Source: Wikipedia)

The official term for our facility was: laboratory. My group, the 131st of DF, developed software and was responsible for APS (short for user’s programming language). The language was supposed to make the “stupid” connecting computes do the (pre) processing as early as at the fringes of the network, for instance when it came to collecting data for a business process in the user’s dialogue. Also, it had a controlling and “intelligent routing” purpose.

Within DF, there were a number of teams, all of them developing new things. Because a computer network needs a lot of modules and, considering what times we are talking, it was rather complex (or highly complicated). And the team cooperated on a high intensity level.

Together with the customers and the partners of our FBZ (technological counselling centres at Siemens AG), we made Transdata the basis for the new big IT projects. And it all happened in a very agile, open and slim way. The minutes of the coordination meetings with the big projects and the technological counselling centres were our specification sheets. There was also a management, but their primary task was to see to it that all humans were happy. And to protect the teams from the Siemens management.

We worked in an enclave, in the Ortenburgstr. It was one of the many Siemens locations outside Hofmannstr. There was an actual bakery on the ground floor, which in itself made the location attractive. No barracks and instead tasty pretzels and rolls.

Some way or other, we all at DF were a good team and made the dice roll. We were all engineers and developed technology for real projects. And Transdata became a success. It made me proud to work on systems that often ran in important and revolutionary projects.
At the time, my job description was: 
Synchronously programming on three versions. Version A (for example 4.0), which currently was on the market, was maintenance I had to do. This was about correcting errors and communication with users. For the next version, I developed the functionality as had been agreed upon and decided (version B, aka 4.1). And then, I had to plan version C – which would be 5.0 in our example – with the project partners.

Thus, the time we invested into the future was quite considerable. Because the market was demanding and very dynamical, the competitors were quick and consequently the speed had to be high.

On top of programming three versions simultaneously, I had more tasks, too. Of course, I wrote the manual for our programming language myself. I had to do the technological supervising of our large-scale projects and teach courses for the system engineers who used our system.

On top of this, I also organized the test of our new functions with our pilot users and wrote the product flyers for our marketing. In those days, new employees were recruited all the time. After half a year, I actually was an “oldie” at Siemens because of all those “newbies”. And we also had to continue our education – which was mainly done by reading the ACM or IEEE lecture notes.

As a side-line, we organized a coffee machine and a fridge for our office – which caused quite an earthquake with the Siemens administration. A coffee machine in a Siemens office – that was against all regulations (regardless of the fact that such a machine, allegedly, could be bought at a discount by the employees at “our” shop). But we managed even that.

And then the sad times started. Management grew more and more powerful. They introduced division of labour. It was some kind of development Taylorism in the laboratory. In addition, the administrative processes grew more and more time-consuming. That was in the second half of the 1970ies. We had to kiss our laboratory idyll good-bye.

First they introduced the manual editorial office. We had to teach persons who had not the slightest idea of how IT worked what needed to be written in a programming manual. Then came quality management. Those were people who had to have tested our software before said software was prototypically used by our customers. Except they had no clue about software and testing same.

Then they introduced product management and requirement engineering. All of a sudden, there were mile-stones, such as A20, A30, B20 … B50. The waterfall model came. Even the termination of the product was defined with enormous precision. That was T50 if I remember correctly. It was called project phase model. And we were no longer allowed to do any programming. Instead, we had to think about the level of maturity our work had now achieved.

They started the budget concept and expected us to make (guess) predictions about the expected cost for all discussed functions. Unfortunately, most of the new functions were very innovative and involved a high degree of creative research. Thus, predicting the expected cost soon became more time-consuming than the actual programming. Except that we were no longer permitted to do any programming, anyway, because in order to decide if there was to be any programming, you first needed a tested and approved cost estimation.

And thus it happened that what formerly we could discuss directly and decide with the customers and the FBZ on one afternoon now was discussed at greater and greater length. Weeks turned into months. Strange decisions were the often absurd results. Again, you had to discuss them at great length – or else you were secretly building u-boats. Which is not really without danger in a well-controlled concern. But then, there is nothing you would not do for a successful project, is there?

Additionally, they decreed working times that made it clear to us all that we were not permitted to work as much as the project would have required. As a logical consequence, they later installed time stamp machines in Neuperlach for the engineers. And if you were caught continuing with your work after you had stamped out, you had to be reprimanded by works committee decree.

Even taking work home got harder and harder, because plant protection had come up with a random generator at the company portals. If the generator sounded, you were controlled (shaken down) and it was absolutely forbidden to take documents home with you.

Thus, it got worse and worse. New sessions with three or four letter abbreviations were introduced (I forgot the abbreviations). Persons from new departments you never knew could exist suddenly sat around the table. “Cross section responsible persons” demonstrated how important they were. People who had no inkling of the market and the technology but were great with common phraseology were more and more powerful in product development. This cost a lot of money and much of what was decided was just nonsense which, naturally, never materialized. If decisions were made at all. All these measures caused helplessness and frustration.

In a nutshell – it was about time to leave. Consequently, I moved – inside Siemens AG – to a department where actual projects were still realized (UB D V S 3 – company sector data processing, sales and special projects, department3). After all, you were still supposed to work on true projects and remained free from bureaucracy and management mania – at least for a short time.

I had a nice offer, because at UB D V S 3, (not only) one project that was particularly important for the leadership was suffering from a crisis. And said project was behind schedule by quite a bit. It was called DISPOL and they had to develop it for the Bavarian Government. The task was to make the police fax machines (communication), the data storage cupboard (database and archive) and the typewriter (document processing) obsolete by introducing IT equipment.

This was the project during which I, for the first time in my life, met a true project manager … He was supposed to save the project – and that was my job, too. Together, we actually managed it. Because he left the technology experts to do their thing and did not interfere. But I am not yet going to tell you more about it here, because that is the third story from my series “vintage project management as told at the Berlin PM Camp”.

RMD
(Translated by EG)

P.S.
Today, you have personal managers and service managers. A short time ago, I read “coaching manager” on a BVS.de visiting card. Human resource is about BGM (company health management). The enterprises have their knowledge management and there are certified knowledge managers. If all this does not help, you install an innovation manager and if you need even more than that, you still have the change manager. What a brave new world …

P.S.1
Here a diagramm of Siemens – is it not a wonderful example for vintage project management? Andreas Weber has sent it to me – Thanks – dear Andi!

Und danach sollte man innovative Software und Produkte entwickeln - ist doch irgendwie lächerlich.

That was the way, we should develop innovative software and new products entwickeln – ridiculous.

Roland Dürre
Thursday October 8th, 2015

Vintage Project Management #1 – My First Project

Das war erst viel später und da war es schon vorbei. Das erste Projekt war noch in Koppstr. (Nahe Hofmannstr.)

What you see on this picture did not yet exist – it only came when my project was over. My first project was realized in the Koppstr. (Hofmannstr.)

During the Berlin PM Camp, I told the stories of four projects from vintage times that were very important for me. And I also announced here that I was going to publish all four of them in the IF Blog.

So here I am now, beginning with the first small project:

Project #1

The first project of my life was but a small one. It was scheduled to last six weeks and it was my first professional activity in data processing.

In those days, I was a student of informatics starting for the second time. The first time had been in 1969, when I started studying mathematics and minored in informatics at Technische Hochschule München (THM). The only alternatives for the minor subject would have been physics – which I did not like – and business. However, I was a little sceptical, because I had been attending and graduating from the Jacob Fugger “Business Grammar School” in Augsburg. And at that school, accounting, which I was quite good at, had been an A-level subject. On the other hand, the knowledge taught in business and economics seemed a little questionable to me – which, incidentally, is even more true today. Consequently, the only thing to minor in left was informatics – and that sounded really exciting, too. Professor F.L. Bauer actually succeeded in whetting my appetite in the fall of 1969.

And then, on April, 1st, 1970, dark powers and a mixture of ill luck and ill advice forced me to serve in the Federal Army. That was not at all an April’s Fool Jest, which meant that I had to spend 18 months in rather questionable surroundings as a conscript.

And when, late in September 1971, I regained my freedom, I just started anew. Again in the first semester, again with the same combination of subjects, and again at the same college, which suddenly was called TUM (Technische Universität München).
But there was nothing new except the name. And I knew almost everything because in 1969 I had still been a rather diligent student who had listened attentively and learned with enthusiasm. Consequently, I was doing well and the Olympic Games of 1972 came along. Besides studying, I had a great job with good money at the German Railway (at the time still called Deutsche Bundesbahn) as a customer service person for guests from all over the world. And in some way or other, the entire world was mine for the asking …

In 1974, I finished my intermediate diploma successfully and again needed a little more money than I made as a TUM tutor (teaching Linear Algebra I and II and a programming course). I narrowly missed being eligible for BaföG and my parents – also working at the German Railway – said I could easily continue living at home in my room and commute to Munich like my father always did. But that was not what I wanted. Consequently, I was looking for a summer job – and, naturally, the favourite prospective employer was one of the leading high-tech and computer companies.

In those days, that was what Siemens was! Seen in retrospective, it is hard to believe what immense know-how was present in this company in a huge number of areas. They took me in at Siemens and so I was in the middle of the real high-tech world, first for six weeks in the summer of 1974 and then for the entire duration of my university education. I had direct access to computers, operating systems and programming languages – and I mean I was filled up with them to the brim, which was totally different from what they offered, for instance, at the so-called TUM.

And I got my first project at Siemens on my very first day! My (department) boss was Mr. Bieck. He was a hardware person and later became development head at one of the upcoming German computer manufacturers: Kienzle.

Kienzle was only one of the smaller Siemens competitors – but it was certainly remarkable to see what these enterprises – just like much larger enterprises, such as Nixdorf, or many smaller ones managed to accomplish in those days.

During my six weeks as a summer intern, I had total freedom – provided the actual task I had been assigned got finished. And they also told me that the problem I had been given might not be solvable at all. But that it would indeed be very much appreciated if I managed to solve it. It was actually the same I heard over the last few years from people about google: you give yourself unachievable goals, yet you get a nice tolerance for possible failure, which means you will be truly happy when eventually you actually manage to solve the problem.

The task was easy to formulate: 
The department wanted the highest possible Mersenne prime numbers. For a hardware prototype.

For non-mathematicians:
A number is a Mersenne prime number if it is a prime number derived from a power of two minus 1. In other words if (2 power n) – 1 or (2 power m) – 1, is a prime number.
That is my spontaneous definition.

Well – and my boss wanted as many n-s and m-s as possible. He was not interested in being shown how I did it – as long as I did it at all.

The background:
In those days, a lot of people were really active doing “research and development”. It was truly great. But it was not some R&D totally remote from practice. No: in almost all cases, your work would serve to promote actual applications and projects. That made it truly cool.

Practically applied R&D needs theoretical background. Business got that from the universities (in those days, there was still something you could get from them). And, naturally, Siemens AG also looked across the borders – particularly across the inter-state borders. Because the GDR universities were not so bad at all. And they gave us lots of great results.

For instance, there was a scientific work sitting on my desk – I think it had been written in Leipzig – in which someone had given the theoretical proof that it is possible to build an accidental generator from a ring connection with n binary switches.

And if you short-circuited the structure at the right place, the system would generate a maximum period of random numbers.

It would happen if and only if the number of used switches n is a Mersenne prime number. And if the short-circle is after the m-th switch – and if m is a Mersenne prime number. 
(please forgive my clumsy description, I was never much of a hardware person).

I never understood this work. Also those six weeks would probably be far too short. But then, this was totally irrelevant for my job. All I was supposed to do was deliver very high prime numbers of the type 2 power n -1. Even the prime numbers were unimportant. All that mattered were the m and the n.

For my software friends:
In the early 1970ies, it was totally utopian to build such a thing as random generator software. After all, the device was supposed to create the bit patterns rather quickly, because they were supposed to test the maximum flat modules for large-capacity computers. And those were rather fast gadgets, considering the times.

Also, Herr Bieck could not have cared less how I solved the problem – that meant it was up to me if I programmed something for the calculation or if I found the big Mersenne prime numbers somewhere else in the world. All options were open.

Consequently, I spent the next few days in various libraries (Siemens, StaBi, Unis – you have to remember that, in those days, the internet did not exist). And I quickly realized that there was no chance for me finding Mersenne prime numbers in this way, even if someone on this planet had already calculated them.

This is why I forced myself to come to a quick decision. I was going to forget the world around me and try it by myself – by just programming. I still had more than five weeks to go.

This was the first thing I learned about “project management”: 
Decide quickly, especially if it is a really hard decision and you basically know no way out.

Then I tried to do some traditional programming. I thought in terms of the decimal system, looking into integer and arithmetic calculation systems. And after two weeks, I noticed that I was never ever going to succeed with this strategy.

And this was the second thing I learned for future projects and for life: 
Whenever you do not know how to continue, you have to try new ways! Kiss old concepts and patterns good-bye, and do not hesitate!

So I decided to no longer look for huge numbers. Instead, I just saw a number as a field of bits. And all of a sudden, all those big numbers became small numbers. For instance, 2-to-the-power-of-256 was now a binary field with the length of 32 bytes. And you can calculate rather elegantly with bit fields each of which has the length of 32 bytes. All you have to do is some shifting. And suddenly, the huge number had lost all its scariness …

I told you this story for two reasons.

Firstly, because all of a sudden it became clear to me that, on top of deciding quickly and courageously, you also have to leave old mental concepts if you want to achieve something special. And I often suffered under this and under the typical “But this is how we always did it …”, because it blocked the way.

And because I am living proof that, more than 40 years ago, Siemens actually worked in the same way as they sometimes say Google does today. And that in those days they achieved really great things and that there was not much competition world-wide, perhaps IBM and Xerox or Hitachi. All the others were just in their initial phases.

In a short time, you will read my next Berlin #PMCampBER story on vintage project management. It is from a time when I had a contract as an employee – at the Siemens laboratory. That was in the late 1970ies. I will relate how Siemens did everything, and I mean really everything, to destroy its greatness.

It happened because they kissed their old virtues good-bye and introduced division of labour (Taylorism) in the creative areas such as product planning (Requirement Management) and quality management, specialized DV/IT teachers in their D-schools, manual copy editors and many more such roles.

And, above all, whenever there were things to decide, the questions they asked were: “What is the profit of this?” and “What is our advantage?”, instead of the question: “Why do we do this?” – as in former times.

At the time of my first project, there were no such things as project managers. The first project manager you will find in the world as I perceived it will come with my third project management vintage story. That was in the early 1980ies.

RMD