Martin N. Ségur-Cabanac

It is my belief that Socrates’ notion that “the unexamined life is not worth living” is true not only of our private lives, but to the same extent of our behaviour in a business environment. This text, therefore, is an attempt to impart the theories of project management and communication within organisations discussed in the course of the Everybody Manages lectures to three distinct yet in their qualities very much connected experiences of my past.

I hold a college degree in electronics and information technology. An integral part of reaching that qualification was a one-year final diploma project, in my case a computer controlled toy train system. My two team colleagues and I went about creating it without any theoretical knowledge of project management, even though we had completed assignments on a smaller scale throughout the preceding four years. We did not define our individual roles in the team beforehand, but let them grow out of what each one of us was capable of and willing to contribute. This decision however was not made consciously. Today I understand that this approach was possible only because we had known each other for years and were certain of each other’s desire to achieve the best we could – we were the top three students in our class. In terms of Bruce Tuckman’s “developmental sequence in small groups”, we had long proceeded into the “performing” stage. Owing to what I have learned in the Everybody Manages lectures, I can now identify the causes for the problems that arose with the project much more clearly than I could back then.

There was no distinct planning phase to our project – we constantly re-invented ourselves on the go, a common vision described in a short written abstract the only guiding path to a finished product. We recognised that our project consisted of two discrete areas – hardware and software – and divided our individual tasks accordingly: I was responsible for hardware design and prototype manufacturing while my colleagues would write the software. By that decision, we had effectively split our team in half. Even though we would talk about our respective developments, we would work almost entirely separate from each other from that day onward. I do recognise some advantages in collaborative team working, yet I believe it to be almost impossible (and unproductive) in a technical development process. Aside from an initial collaborative project definition phase, where a team may brainstorm ideas and define project goals together, technical product development requires distinct tasks to be performed by individual team members. This is especially true for software design. Therefore, I think that splitting our team in half was the reasonable response to the reality of our project. My two colleagues subsequently worked co-operatively on writing the software, whereas I worked almost entirely independent.

Had we heeded Laurie Mullins’ advice that “the basic planning is the foundation on which the eventual outcome will be decided,” we could have avoided many difficulties. The single most critical problem presented itself about two-thirds into the project as a direct result of our lack of planning. I had completed the hardware design and had manufactured a prototype circuit board. Now I needed the software to test it. My colleagues, however, had concentrated their efforts on the graphical user interface of the software and consequently had neglected the parts necessary to communicate with the hardware. This caused a delay in the hardware testing phase. It was only after I wrote a test software myself that I could continue. (This decision turned out to cause another problem discussed later.) Had we known about such tools as Gantt charts, the Program Evaluation and Review Technique (PERT), or the Critical Path Method (CPM) back then, we could have avoided this delay. It would have been quite clear to us that, while the graphical user interface was an important part of the overall product, it was no use without the hardware. And since the hardware was sure to take less time to design (at least up to the prototype stage) and would need software to be tested with, that part of the software would have been on the critical path of any PERT/CPM. This holds true for another, although less time consuming, consequence of lack of planning. It was only after a few months of separate hardware and software design that we recognised the need for a common interface to enable data exchange between the two. This caused only a minor delay, but the interface development, too, would have had its place early on the critical path.

However useful PERT/CPM techniques may be for project planning, I believe that “activity-on-arrow” (AOA) systems, showing events (or milestones) as circles with numbers (or letters) and the activities (or tasks) on arrows connecting them, are contra-productive. It might be a result of my IT background, where so-called “logic flow diagrams” are used in both software and hardware design, but not only does it feel much more natural to me to use “activity-on-node” (AON) systems (e.g. the one used by Microsoft Project), but I believe they are generally much easier to understand and work with. AOA systems cannot be “read” without a legend showing the task numbers with their corresponding tasks, and constant re-checking of those task numbers seems to me to present an unnecessary risk of human error. Even though Gantt charts may also incorporate precedence network information, I believe an AON PERT/CPM system is the best way to visualise procedural dependencies. Another limit I see in PERT/CPM and even Gantt charts is the fact that time and resources needed for the specific tasks of a project most of the time can only be approximated, relying heavily on past experiences. If no like project was ever undertaken by a team and/or an organisation, any time and resource allocation can only be viewed as a very rough guideline. This puts much more pressure on adequate contingency planning (i.e. risk management).

By writing my own test software for the toy train system I created a difficult situation not for the product itself, but for my team members. It took me just a weekend to write this rudimentary application, a fact that was met with astonishment from our tutor (the project supervisor) and with some resistance by my colleagues. It was just natural for the tutor to assume that I was either much more serious about the project or much more skilled than my colleagues, neither of which was true. I had simply employed a much less advanced and easier to use programming language that was better suited to the purpose. But, in terms of teamwork, I had shown off to our superior by undermining our team and presenting the achievement as mine. This led to a problem for my colleagues at the end of the year, as they were to get a lower mark than myself. As mentioned, we never defined our roles within the team, but at this stage I very much felt like the team leader (or project manager), since I had found an external sponsor for our project, had written the technical documentation for it, and had organised a separate room for us to set up a test environment. But I knew that my colleagues had put the same amount of effort into writing the software; it just turned out to be much more difficult than anticipated. Therefore, I felt responsible for their bad image. Looking back now I realise that the solution to this situation probably represents my first management decision, a decision that balanced the needs of the product with the needs of the team, effectively employing the “team management style” defined in the Blake Grid. Since I was responsible for the technical documentation, I decided to highlight the tremendous effort my colleagues had put into the software design process by including the entire code as an appendix – over one hundred pages. It was the perusal of this piece of work that led the lecturer to believe that they had indeed put at least as much effort into the project as I had. We all ended up receiving the highest possible mark.

In our euphoric post-graduation mindset, we never analysed our own performance – neither as individuals nor as a team. It is only due to this module that I now, almost eight years later, went back to do just that. And I now understand that, had I examined my accomplishments as well as my shortcomings back then, I could have embarked on various other projects much better prepared. Furthermore, as Mantel et al. recommend, had we had any regular controlling in place, we could have evaluated ourselves not just “after-the-fact”, but repeatedly during the course of the project “at a number of crucial points” to help steer us in the right direction.

Several years later I was working in the two-person IT department of the Belvedere museum in Vienna, Austria. We had just been given a multi-million Euro grant by the federal government to set up a digital storage system for high-definition scans of the museum’s paintings. As my boss had even less experience of project management than I, we again failed to adequately plan this expensive endeavour and instead jumped headlong into unknown territory. As is unfortunately often the case with IT departments, we saw ourselves as quite self-sufficient and self-serving rather than as a service provider for the museum’s various departments. Due to this erroneous mindset we did not even begin to think of the necessity of including all stakeholders to tackle the many issues we were facing. We merely asked for a specification of what was needed from those who would work with the digital archive and then never let them contribute to what little planning we did. After all, we were the experts – the others would not be able to understand the technicalities anyway. If we neglected the planning phase of our venture, we completely ignored the need for any monitoring and/or controlling mechanisms. Any existing reporting was confined to “chats” between my boss (the head of IT) and the chief financial officer. As I left the museum quite early into the project, I do not know how it proceeded and whether it succeeded or not. It could easily have fallen victim to our negligence, or at least have run considerably over budget and/or time, as Mantel et al. describe.

I consider myself fortunate to have been working in an e-commerce company at the height of the dot-com bubble right up to its collapse when the bubble burst in the early 21^st Century. As part of the e-commerce department, my main responsibilities were the website design and product placement of the DVD and video assortment. Reminiscing now, I realise that the company’s demise was in large part due to failures in internal communication, ineffective leadership and management, and groupthink.

An important aspect of the leadership culture in the organisation was the division of departments across three floors within the building. The sixth and top floor housed the chief executive and the chief financial officers as well as the marketing department, the fifth floor was home to the e-commerce and IT departments, and the fourth floor consisted of the journalism department and a web radio. These divisions resulted in a perceived level of importance corresponding to the floor level: the higher up your desk was, the more important you were. This went so far that people on the fourth and fifth floors referred to the management as “the sixth floor”. One vivid way of the psychological impact of this was the fact that the waste pipes running down from the top floor through the IT department and the web radio were not built into the wall but ran inside the rooms (it was an old building that had been roughly adapted to its new purpose). Therefore, when people in the IT department were unhappy with a management decision, they commented that, quite literally, the sixth floor was “defecating on them” again.

As a direct result of the marketing department’s placement on the top floor, its members perceived themselves as being the most important people in the organisation, and, even though we “lower floors” from time to time resented that fact, we never really questioned it. This went so far that the marketing executive starting giving orders directly to me, bypassing both the head of e-commerce and my immediate boss, the DVD/video product manager. This breaking of the “chain of command” predictably resulted in misunderstandings and therefore served only to complicate things. Today I understand that this situation could have been described (and possibly ameliorated) quite accurately by use of the Johari window. The upper left “public arena” (or “both aware”) window would have been quite small in our case, as the sixth floor managers did not know of our resentments, whereas we were probably unaware of their genuine belief that their leadership was vital and helpful in the way they carried it out. Had we disclosed more of ourselves by giving more honest feedback (even when not directly asked for it), we could probably have cleared up the situation to everyone’s satisfaction.

Another result of this division of floors was the split between horizontal and vertical communication within the company. There was a kitchenette on every floor where one could have a short break and informal conversations with members of other departments. Even though I believe these were good communication hubs, it meant that an employee from one floor would very seldom venture onto the other floors to have a break. This, consequently, made the social divisions between the floors even stronger and resulted in “informal groups” (or an “informal organisation”) along those divisions. Many other such “informal groups” were created by a culture of “hiring friends” that pervaded almost every department. I myself was referred by a close friend of mine working in the IT department. This, together with my background in IT, opened up an additional communications channel for me: I would know about advances and problems with the vital software applications sooner than the head of e-commerce or the CEO.

Those “informal groups” strengthened what, in my opinion, ultimately brought down the majority of the dot-com failures: extensive and widespread groupthink as defined by Janis. The industry-wide erroneous perception that user numbers reigned supreme over revenue was strongly present in that company. There was only one colleague of mine who once said that making money should be a higher priority, a remark for which he was ridiculed by almost everyone else, marking a perfect example of “pressure on individual members to conform”. Maybe we should all have listened more carefully to this voice of reason.

All this reminiscing about my educational and professional past has led me to wish I had known about many of the basic theories and tools of management a long time ago. Even so, I believe that the majority of those “basics” are an analysis of common sense, of an intuition that each of us shares to a certain extent. Nevertheless, just as Socrates realised so many centuries ago, it is through conscious reasoning that we must turn instinct into skill to become better at what we all do each and every day: manage our path through life.

PDF-Version including Bibliography: Management in Retrospect