Over here, I would like to share some thoughts with you about topics related to (IT) management out of my experience. It would be a pleasure, if some of these thoughts might be useful and valuable for you. Potentially, they even might inspire you to get in touch with me for deeper discussions. I am looking forward to it.

People in a winning team:

In my opinion, successful (IT) projects are not a coincidence, but the result of a true and practiced teamwork instead. Nowadays projects in the IT-related environment often have a complexity that makes it impossible for individuals to deal with them alone. There is the effect that more and more specialized knowledge is required in disciplines where it needs very dedicated experts to succeed.

All of this may frequently result into large teams and many people to coordinate, where one piece of the puzzle has to mesh exactly into the next, so that the business objectives are met. Therefore, large teams arise quickly and every partial work result has to fit together. Ultimately, it is like in an instrumental orchestra, where the listener is able to feel the harmony most, when the orchestra is playing and acting like a team, bringing the sound of all instruments perfectly together. From my point of view, this mental image nicely illustrates the source of the idiom digital orchestration.

Of course, such a business result may alternatively be reachable by just buying services on the market. Nevertheless, I think that at least a really good internal core team within the company is needed and most successful, when a team culture based on trust is in place. I.e. a team which feels obliged to the goals, in which the team play is important, and where trust in the working atmosphere prevails. Certainly this sounds idealistic, but I think it is feasible.

As an additional final thought on such: expert knowledge is learnable, personality is important.

Service orientation:

Service orientation is frequently an important and newsworthy topic. But how do you translate that sustainable into practice, so that it is recognizable for external customers and company-internal departments ?

Apart from continuously practicing (living) the dedication to service, the expectation management is a second important success factor within this field. You may not be able to always achieve every upcoming wish – and normally it might not even be fundable. That’s why, of course, it is considerable helpful to all involved persons, if the service level you need to perform is defined precisely (i.e. within a SLA = Service Level Agreement). In addition, this obviously gives potential and opportunities to serve some little extras and complete the client’s satisfaction.

A suitable approach to offer a good service orientation not only in the IT sector, but also within various other subject areas, is ITIL – the IT Infrastructure Library (Definition von itSMF). Basically, it is about building a professional, comprehensive and all-round service management. Such could include many different kind of external and internal services, not 'just' only the typical ones like customer service. Almost every department in a company is able to operate and organizing itself towards service orientation. According to the iterative and multidimensional ITIL life cycle of service, that is put into practice by service strategy, service design, service transition, service operation and continuously service improvement. Valuable best practices provide recommendations, e.g. a RACI-Matrix to define the roles and responsibilities of employees and departments.

In case performance, customer-satisfaction and sustainability are important for you, I think a service oriented approach is extremely helpful to fulfill these goals.

Agile projects:

Today’s economy has frequently been changing very fast, and influencing parameters like in the eCommerce sector are sometimes such volatile, that a more classical (waterfall) approach in projects with long phases of concept creations, realisation and implementation appears much too rigid. There is the risk to work hard but not achieving anything for the market in time. Within such an environment, I think agile approaches and procedures develop their full strength.

If you use agile procedures such as the Scrum method, you typically select exercises from a 'backlog' which will shape the next upcoming 'sprint' (frequently a 3 weeks time frame). After such a sprint you usually should have developed and have got already a finished serviceable first piece of product. A method like Scrum has its origins in the agile software development, but can be used in the context of many other agile projects as well.

For many users, project members and stakeholders it is important to get something tangible with a concrete and already practically orientated result within early phases of a project. It builds trust and gives an early visualisation of the solution, e.g. to use for an early verification on the market.

Of course, as it is for many situations in business life, you should be aware of the risks you are inheriting by using agile methods - and take them into account. Sometimes, there is e.g. a risk of not thinking abstractly and sufficiently enough about the entire architecture and landscape (seen from a business and/or technical perspective). That could lead to isolated solutions, media breaks or fragile paths for the long-term perspective. That is why you should avoid to have to re-build the solution after every sprint, i.e. to (partially) reject and convert the results of the last sprint each time you start a new one, because certain structures did not appear to be sustainable enough. A threat like such could even appear more dramatic in the context of master-data structures, where solid foundations are very important. The good news is, such issues and risks connected to agile methods are not inevitable, it just requires the attention and governance of professionals.

Business Process Modeling:

A topic that is always important and decisive for success is the documentation of functional and non-functional requirements for software systems and business processes (BPM business process modeling, use cases). For sure, you are aware of the fact, that if you don't have goals, you won't achieve them. And if you can not describe goals, requirements, and processes in a concrete, structured, and consistent manner, you will often encounter an implementation problem, at least in an IT-related context. The good news is that it is actually not that difficult, and there are numerous models available to make it much easier.

While non-functional requirements (e.g. response times or UX design aspects) can frequently be described with manageable effort, especially the functional requirements can quickly become complex. Furthermore, requirements from the past are typically already automated nowadays and fulfill their correct service every day. Thereby, such implemented algorithms are sometimes no longer transparent nor well documented, or even completely unknown by the current responsible staff members (e.g. due to a change of employees). The advantage of automation appears than as a challenge, when changes or expansions are required in a logical sphere.

Obviously, the message is too trivial to be cool: good documentation helps. It is not just a question of whether, but also about how. I am even sure, it's mission-critical and only those who manage to master high levels of complexity, will be able to establish successful solutions in the long term. Everything else might only be a 'flash in the pan' - which of course, depending on the business objectives, should not be criticized per se. But frequently such results into short-term (sales) successes only, with less possibility to build more sustainable next steps on. From my point of view, this entrepreneurial decision should be made explicitely and deliberately. Then the correct form of documentation can be choosen accordingly.

For a typical sustainable approach in the area close to IT / software, it is in my opinion very helpful to stay in a language and form quite easy to understand and for the use by people, who have to deal with the processes from the business side. The perfect form of documentation should be as natural as possible, ideally highly graphical, and easy to learn. It should also be useable in structured ways, so that error minimization and completeness can be assured.

In the last decade, e.g. the use of UML, the Unified Modeling Language, has become very popular. Process diagrams in swim lanes can also often be found.

I have had many good experiences, too, with BPMN (Business Process Modeling Notation) and alternatively event-driven process chains (EPC). Both are widely distributed in the world. It can be used w/o a tool, but with special software tools this is of course easier, e.g. EPC's with ARIS from IDS-Scheer respectively meanwhile from Software AG.

Often, the use of EPC's is absolutely sufficient to describe technical processes. However, whenever such algorithms are associated with a lot of different data (in particular algorithms treating with or treated by complex master data), there is an additional important aspect, i.e. the view of the data model or information model using e.g. ERD's.

Yes, it sometimes looks technical for users, with all the representations of tables, data and relationships. But I think it is in many situations very important, to really understand (business) data structures and relationships from a business process owner perspective, to make good business decisions on algorithms. Furthermore, I think in such context it is helpful to differentiate between a business data model (normalised) or information model on the one hand, and a physical data model (performance-optimised) for the more IT professionals on the other side. Such could prevent very much from anxieties for non-technical users.

Transistor counts for microprocessors nearly doubling every two years.
(Gordon Moore, 1965)

A nice analogy in my opinion to the visualization of this Moor's law: a VW Beetle from 1971 would today drive 310,000 mph and would only cost 4 cents.
(Wirtschaftswoche, WiWo published 22.05.2015, page 55)


Problems can never be solved with the same way of thinking from which they first emerged.
(Albert Einstein)