The absurdities of my current project (and some attempts to draw lessons)

I have spent roughly two years in a row with my current client, to which can be added at least two stints in the past, working on several related projects. Until the beginning of the latest project, roughly six months ago*, I have enjoyed the cooperation, largely through the over-average amount of thinking needed, but also due to my low exposure to bureaucracy, company politics, and the like. With this project, things have changed drastically, problems with and within the project have turned the experience negative, to the point of repeatedly having negative effects on my private life**, and I definitely do not feel like accepting another extension. I am, in fact, at a point where I want to bang my head against the wall and scream my frustration on a regular basis.

*Giving an exact number is tricky, with the unofficial kick-off and preparations taking place long before the official kick-off, combining a long phase of (often failed or useless, cf. below) requirement clarifications and study of various documents with work on other projects.

**When problems of a “political” nature occur or when my work is hindered by the incompetence or lack of cooperation from others, I often have difficulties letting go of these issues in the evening. This is one of the reasons that I prefer working as a contractor—I am less vested than I was as an employee and can (usually…) take a more relaxed attitude towards internal problems of a given client.

To look at a few problems:

(I apologize for the poor structuring below, but it is almost 1 A.M. in Germany and I want to close this topic.)

1. The originally communicated live date was end of June. This was completely and utterly unrealistic, which I and several other developers communicated from the start. Eventually, the plan was changed to first quarter 2018—not only much more realistic, but something which allowed us to use a high-quality approach, even undo some of the past damage from earlier projects with a too optimistic schedule*. Unfortunately, some months in, with development already long underway based on this deadline, the schedule was revised considerably again**: Now the actual live date was end of October, with a “pilot” release, necessitating almost all the work to be already completed, several weeks before that…

   *What is often referred to as “technical debt”, because you gain something today and lose it again tomorrow—with usurious and ruinous interest… Unfortunately, technical debt is something that non-developers, including executives and project managers, only rarely understand.

   **I will skip the exact reasoning behind this, especially since there are large elements of speculation in what has been communicated to me. However, it falls broadly in the category of external constraints—constraints, however, that were, or should have been, known quite a bit earlier.

   Queue panic and desperate measures, including scrapping many of the changes we had hoped for. Importantly, because a waterfall* model with a separate test phase was followed, we were forced to the observation that from a “critical path” point of view we were already screwed: The projected deadline could only be reached by reducing the test phase to something recklessly and irresponsibly short. As an emergency measure, in order to use test resources earlier and in parallel with development, the decision was made** to divide the existing and future work tasks into smaller groupings and releases than originally intended. On the upside, this potentially saved the schedule; on the downside, it increased the amount of overall work to be completed considerably. Of course, if we had known about the October deadline at the right time and if we had not believed the earlier claims, this could have been done much more orderly and with far less overhead: We almost certainly would have kept the deadline, had this been what was communicated to begin with. As is, it will take a miracle—indeed, even the official planning has since been adjusted again, to allow for several more weeks.

   *I consider waterfall projects a very bad idea, but I do not make the policy, and we have to do what we have to do within the given frame-work.

   **With my support on a reluctant lesser-of-two-evils basis. Now, I am used to work with smaller “packages” of work and smaller releases in a SCRUM style from many of my Java projects. Generally, I consider this the better way; however, it is not something that can be easily done “after the fact”. To work well, it has to be done in a continual and controlled manner from the very beginning.

   Planner* lessons: Never shorten a dead-line. Be wary of rushing a schedule—even if things get done this time, future problems can ensue (including delays of future projects). Never shorten a dead-line. Do not set deadlines without having discussed the topic in detail with those who are to perform the work—the result will be unrealistic more often than not. Never shorten a dead-line.

   *For the sake of simplicity, I use the term planner as a catch-all that, depending on the circumstances, might refer to e.g. an executive, administrator, project manager, middle manager, … I deliberately avoid “manager”.

   Developer lessons: Do not trust dead-lines. Even in a waterfall project, try* to divide the work into smaller portions from the beginning. It will rarely hurt and it can often be a help.

   *This is not always possible or easy. In this case, there were at least two major problems: Firstly, poor modularization of the existing code with many (often mutual or circular) dependencies, knowledge sharing, lack of abstraction, … which implied that it was hard to make different feature changes without affecting many of the same files or even code sections. Secondly, the fact that the code pipeline was blocked by another project for half an eternity. (I apologize for the unclear formulation: Explaining the details would take two paragraphs.)

2. During a meeting as early (I believe) as February, the main product manager (and then project manager) claimed that the requirements document would be completed in about a week—it still is not! In the interim, we have had massive problems getting him to actually clarify or address a great many points, often even getting him to understand that something needs to be clarified/addressed. This for reasons (many of which are not his faults) that include his lack of experience, repeated vacations and/or paternity leaves, uncooperative third parties and internal departments that need consulting, too many other tasks for him to handle in parallel, and, to be frank, his not being overly bright.

   A common problem was questions being asked and a promise given that the next version of the requirements document would contain the answer or that something was discussed in a meeting and met with the same promise—only for the next version to not contain a word on the matter. When asked to remedy this, the answer usually was either a renewed (and often re-broken) promise or a request for a list of the open issues—something which should have been his responsibility. Of course, sending a list with open issues never resulted in more than several of the issues actually being resolved—if any…

   As for the requirements document: I asked him early on to send me the updated version with “track changes” (MS Word being prescribed tool) activated either once a week or when there had been major changes. There was a stretch of several months (!) when a new version was promised again and again but never arrived. When it did arrive, there were no “track changes”…

   I recall with particular frustration a telephone conversation which went in an ever repeating circle of (with minor variations):

   Me: Please send me the changes that you have already made. I need something to work from.

   Him: Things could change when I get more feedback. It makes no sense give you my current version.

   Me: I’ll take the risk.

   Him: You can work with the old version. Nothing will change anyway.

   Me: If nothing will change, why can’t you give me your current version.

   Him: Because things could change when I get more feedback. It makes no sense give you my current version.

   …

   (And, yes, I suspect that the problem was that he simply had left the document unchanged for half an eternity, despite knowing of a number of changes that must be made, and did not want to admit this. He likely simply did not have an interim version to send, because the current state of the document was identical or near identical to the older version. Had he sent this document, he would have been revealed—hence weird evasions and excuses that made no sense. But I stress that this is conjecture.)

   The other product managers are better; however, the only one assigned to the project full-time is a new employee who has started from scratch, with the others mostly helping out during vacations (and doing so with a shallower knowledge of the project and its details).

   Some blame falls back on development, specifically me, for being too trusting, especially through not keeping a separate listing of the open points and asked questions—but this is simply not normally needed from a developer. This is typically done by either product or project management—and he was both at the time. See also a below discussion of what happened when we did keep such a list…

   Planner lessons: Make sure that key roles in an important and complex project are filled with competent and experienced people and that they have enough time to dedicate to the project. (Both with regard to e.g. vacations and hours per typical week.) Do not mix roles like product and project manager—if you do, who guards the guards?

   Developer lessons: Do not trust other people to do their jobs. Escalate in a timely manner. Find out where you need to compensate in time.

   Generic/product manager lesson: If you are over-taxed with your assignments, try to get help. If you cannot get help, be honest about the situation. Do not stick your head in the sand and hope that everything will pan out—it probably will not.

3. After the first few months, a specialist project manager was added to the team. As far as I was concerned*, he had very little early impact. In particular, he did not take the whip to the main product manager the way I had hoped.

   *Which is not automatically to say that he did nothing. This is a large project with many parties involved, and he could conceivably have contributed in areas that I was rarely exposed to, e.g. contacts with third parties.

   Around the time the October deadline was introduced, a second project leader was added and upper management appeared to develop a strong interest in the projects progress. Among the effects was the creation of various Excel sheets, Jira tasks, overviews, estimates, … (Many of which, in as far as they are beneficial, should have been created a lot earlier.) At this point, the main task of project management appeared to be related to project reporting and (unproductive types of) project controlling, while other tasks (notably aiming at making the project run more efficiently and effectively) were not prioritized. For instance, we now have the instruction to book time on various Jira tasks, which is a major hassle due to the sheer number*, how unclearly formulated they are, and how poorly they match the actual work done. To boot, a few weeks ago, we were given the directive that the tasks to book time for the “technical specification” had been closed and that we should no longer use these—weird, seeing that the technical specification is still not even close to being done: Either this means that there will be no technical specification or that the corresponding efforts will be misbooked on tasks that are unrelated (or not booked at all).

   *I counted the tasks assigned to me in Jira last week. To my recollection, I had about ten open tasks relating to actual actions within the project—and fourteen (14!) intended solely to book my time on. Do some work—and then decide which of the fourteen different, poorly described booking tasks should be used… It would have been much, much easier e.g. to just book time on the actual work tasks—but then there would have been harder for project management to make a progress report. In contrast, we originally had three tasks each, reflecting resp. meetings, technical specification, and development. Sure, there were border-line cases, but by and large, I could just make a rough approximation at the end of the day that I had spent X, Y, and Z on these three, clearly separated tasks. To that, I had no objections.

   We also had a weekly project/team meeting scheduled for one hour to report on progress. After we exceeded the time allotted, what was the solution for next week? (Seeing that we are on a tight schedule…) Keep a higher tempo? No. Replace the one big meeting with a daily ten minute mini-briefing? No. Skip the meeting and just have the project manager spend five to ten minutes with each individual developer? No. Increase the allotted time by another half hour? Yes!

   By now we have a third project manager: That makes three of them to two product managers, two testers, and seven developers. Call me crazy, but I find these proportions less than optimal…

   At some stage, the decision was made to keep a list of open questions in Confluence to ensure that these actually were resolved. Of course, the responsibility to fill these pages landed on the developers, even when emails with open items had already repeatedly been sent to product management. With barely any progress with the clarifications noticeable in Confluence, this procedure (originally agreed between development and product management) is suddenly unilaterally revoked by project management: Confluence is not to be used anymore, what is present in Confluence “does not exist”, and all open issues should be moved, again by development, to a new tool called TeamWork. Should the developers spend their time developing or performing arbitrary and/or unnecessary administrative tasks? We are on a deadline here…

   Well, TeamWork is an absolute disaster. It is a web based, cloudstyle tool with a poorly thought-through user interface. It does nothing in the areas I have contact with, which could not be done just as well per Jira, Confluence, and email. Open it in just one browser tab, and my processor moves above 50% usage—where it normally just ticks around no more than a few percent*. To boot, it appears** that the companies data are now resting on a foreigner server, on the Internet, with a considerably reduction in data security, and if the Internet is not there, if the cloud service is interrupted or bankrupted, whatnot, the data could immediately become inaccessible. And, oh yes, TeamWork does not work without JavaScript, which implies that I have to lower my security settings accordingly, opening holes where my work computer could be infected by malware and, in a worst case scenario, the integrity of my current client’s entire Intranet be threatened.

   *My private Linux computer, at the time of writing, does not even breach 1 percent…

   **Going by the URL used for access.

   The whole TeamWork situation has also been severely mishandled: Originally, it was claimed that TeamWork was to be used to solve a problem with communications with several third parties. Whether it actually brings any benefit here is something I am not certain of, but it is certainly not more than what could have been achieved with a 1990s style mailing-list solution (or an appropriately configured Jira)—and it forces said third parties to take additional steps. But, OK, let us say that we do this. I can live with the third party communication, seeing that I am rarely involved and that I do not have to log in to TeamWork to answer a message sent per TeamWork—they are cc-ed per email and answers to these emails are distributed correctly, including into TeamWork it self. However, now we are suddenly supposed to use TeamWork for ever more tasks, including those for which we already have better tools (notably Jira and Confluence). Even internal communication per email is frowned upon, with the schizophrenic situation that if I want to ask a product manager something regard this project, I must use TeamWork, for any other project, I would use email… What is next: No phone calls? I also note that these instruction come solely from project management. I have yet to see any claim from e.g. the head of the IT department or the head of the Software Development sub-department—or, for that matter, of the Product Management department.

   To boot: The main project manager, who appears to be the driving force behind this very unfortunate choice of tool, has written several emails* directed at me, cc-ing basically the entire team, where he e.g. paints a picture of me as a sole recalcitrant who refuses to use the tool (untruthful: I do use it, and I certainly not the only one less than impressed) and claims that it should be obvious that Confluence was out of the picture, because Confluence was intended to replace the requirements document (untruthful, cf. below), so that product management would be saved the effort to update it—but now it was decided that the requirements document should be updated again (untruthful, cf. below); ergo, Confluence is not needed. In reality, the main intention behind Confluence (resp. this specific use, one of many) was to track the open issues (cf. the problems discussed above). Not updating the requirements document was a secondary suggestion on the basis that “since we already have the answers in Confluence, we won’t need to have the requirements document too”. Not even this was actually agreed upon, however, and I always ran the line that everything that was a requirement belonged in the requirements document. To the best of my knowledge, the head of Software Development has consistently expressed the same opinion. There can be no “again” where something has never stopped.

   *Since I cannot access my email account at my client’s from home, I have to be a little vaguer here than I would like.

   In as far, as I have used TeamWork less than I could have, which I doubt, the problem rests largely with him: Instead of sending us a link to a manual (or a manual directly), what does he do? He sends a link to instructional videos, as if we were children and not software developers. There is a load of things to do on this project—wasting time on videos is not one of them. To boot, watching a video with sound, which I strongly suspect would be needed, requires head-phones. Most of the computers on the premises do not have head-phones per default, resulting in an additional effort.

   Drawing lessons in detail here is too complex a task, but I point to the need to hire people who actually know what they are doing; to remember that project management has several aspects, project reporting being just one; and to remember what is truly important, namely getting done on time with a sufficient degree of quality.

   While not a lesson, per se: Cloudstyle tools are only very, very rarely acceptable in an enterprise or professional setting—unless they run on the using companies own servers. (And they are often a bad idea for consumers too: In very many cases, the ones drawing all or almost all benefits compared to ordinary software solutions are the providers of the cloud services—not the users.) If I were the CEO of my client, I would plainly and simply ban the use of TeamWork for any company internal purposes.

4. Last year four people were hired at roughly the same time to stock up the IT department, two (a developer and a tester) of which would have been important contributors to this project, while the other two (application support) would have helped in reducing the work-load on the developers in terms of tickets, thereby freeing resources for the project. They are all (!) out again. One of these was fired for what appears (beware that I go by the rumor mill) to be political reasons. Two others have resigned for reasons of dissatisfaction. The fourth, the developer, has disappeared under weird circumstances. (See excursion below.) This has strained the resources considerably, made planning that much harder, and left that much more work with us others to complete in the allotted time.

   Planner lesson: Try* to avoid hiring in groups that are large compared to the existing staff**. It is better to hire more continuously, because new employees are disproportionally likely to disappear, and a continuous hiring policy makes it easier to compensate. Keep an eye on new (and old…) employees, to make sure that lack of satisfaction is discovered and appropriate actions taken, be it making them satisfied or starting the search for replacements early. Watch out for troublesome employees and find replacements in time. (Cf. the excursion at the end; I repeatedly mentioned misgivings to his team lead even before the disappearance, but they were, with hindsight, not taken sufficiently seriously.)

   *Due to external constraints, notably budget allocations, this is not always possible (then again, those who plan those aspects should be equally careful). It must also be remembered that the current market is extremely tough for employers in the IT sector—beggars can’t be choosers.

   **Above, we saw (in a rough guesstimate) a 30% increase of the overall IT department, as well as a 100% increase of the application support team and a 50% increase of the QA team.

5. At the very point where finally everyone intended for the project was allotted full-time and the looming deadline dictated that everyone should be working like a maniac, what happens? The German vacation period begins and everyone and his uncle disappears for two to four weeks… There was about a week were I was the single (!) developer present (and I was too busy solving production problems to do anything for the project…). Product management, with many issues yet to be clarified, was just as thin. There was at least one day, when not one single product manager was present…

   Lessons: Not much, because there is preciously little to be done in Germany without causing a riot. (And I assume that the planning that was done, did already consider vacations, being unrealistic for other reasons.)

Excursion on the missing developer: His case is possibly the most absurd I have ever encountered and worthy of some discussion, especially since it affected the project negatively not just through his disappearance but through the inability to plan properly—not to mention being a contributor to my personal frustration. He was hired to start in September (?) last year. Through the first months, he gave a very professional impression, did his allotted task satisfactorily (especially considering that he was often dropped into the deep end of the pool with little preparation), and seemed to be a genuine keeper. The one problem was that he had not actually done any “real” development (coding and such), instead being focused on solving tickets and helping the test department—and that was not his fault, just a result of how events played out with the on-going projects.

However, at some point in the new year, things grew weirder and weirder. First he started to come late or leave early, or not show up at all, for a variety of reasons including (claimed or real) traffic disturbances and an ailing girl-friend, who had to be driven here-and-there. Taken each on their own, this was not necessarily remarkable, but the accumulation was disturbing. To boot, he often made claims along the lines “it’s just another week, then everything is back to normal”—but when next week came he had some other reason. He also did not take measures to minimize the damage to his employer, e.g. through checking into a hotel* every now-and-then or through cutting down on his lunch breaks**. He especially, barring odd exceptions, did not stay late on the days he came late or come early on the days he left early. In fact, I quite often came earlier and left later than he did—I do not take a lunch break at all… A repeated occurrence was to make a promise for a specific day, and then not keep it. I recall especially a Thursday when we had a production release. He explicitly told me that he would be at work early the following day to check the results, meaning that I did not have to. I slept in, eventually arrived at work, and found that he was still not there. Indeed, he did not show the entire day… I do not recall whether there were any actual problems that morning, but if there were, there was no-one else around with the knowledge to resolve them until my arrival (due to vacations). One day, when he did not have any pressing reason to leave early, he upped and left early. Why? He wanted to go ride his horse…

*Hotels can be expensive, but he had a good job and it is his responsibility to get to and from work in a reasonable manner. Problems in this area are his problems, not his employers.

**In a rough guesstimate, he took an average of 45 minutes a day aside, even on days when he came late or knew that he would leave early. In his shoes, I would simply have brought a sandwich or two, and cut the lunch break down to a fraction on these days. He did not. There was even one day when he came in at roughly 11:30, went to lunch half-an-hour later, and was gone almost an hour… Practically speaking, he started the workday shortly before 13:00… He may or may not have stayed late, but he did not stay late enough to reach an eight hour day—security would have thrown him out too early in the evening…

The claimed problems with his girl-friend grew larger and larger. At some point, he requested a three-day vacation to drive her down to Switzerland for a prolonged treatment or convalescence. He promised that once she was there, there would be a large block of time without any further disturbance. The request was granted—and that was the last we ever saw of him. No, actually to my very, very great surprise, after a long series of sick notes and postponements, he actually showed up for three days, only to disappear again permanently after that, having announced his resignation and a wish to move to Switzerland. During these three days, I briefly talked to him about his situation (keeping fake-friendly in the naive belief that he actually intended to show up for the remainder of his employment) and he claimed that he actually had intended to show up two workdays earlier, feeling healthy, and, in fact, being fully clothed and standing in the door-way, when his girl-friend pointed out that the physician had nominally given him another two days. He then stayed at home, because, by his own claim, he felt that he could use that time better… In this manner, a three-day vacation somehow turned into three workdays—spread over a number of otherwise workless months.

Advertisement