FGZ Project Debriefing
|
+
|
+/-
|
–
|
-
Documentation Project
|
-
Testing
|
-
Change after “Commitment”
|
-
Management Organization Phase CheIT
|
-
Programming by CheIT
|
-
Internal Organization Phase Management
|
|
|
11. Triangular FGZ- Rosarot-OneLine
|
-
Desktop Design
|
|
|
12. GoLive
|
-
Mobile Design
|
|
|
13. After Go-Live
|
-
Time Plan
|
|
|
|
10. Communication tool Slack
|
|
|
|
14. Budget
|
-
Changes after "commitment" (-)
For this project we had a "commitment", but we still had to come under a certain budget. This means we had to break down the original quote in more detail (effort) and make a new quote that fits within the new parameters set.
What if these new framework conditions are no longer to our advantage? "Commitment" is already there and the time factor is also already running….
Learning:
Additional remarks:
-
Project documentation (+)
The documentation (specifications as well as further additional tables, e.g. address or employee list) were correspondingly extensive and clearly arranged on the part of Rosarot for the scale of the web project.
Additional remarks:
-
More specifications. Functions like client backend forms etc.
-
Description was more overviewing, a lot of questions regarding logic, user flow, email notifications.
-
Different remarks in Figma than documentation
-
Generally more detail documentation, everything in 1 place
-
Internal Organization Phase Management (-)
When we received the design and specifications, we only really realized the magnitude (e.g. 50 individual pages or complex logics forms etc.) of this project. This when we already had the "commitment". This is definitely not to OneLine’s advantage. There is already a first pressure because time is running out and we are forced to move.
For smaller or more manageable projects, it may not be a killer factor to study the web project in detail during the organization phase. This can be done later, if necessary.
For a web project the size of FGZ it is a killer factor. When we received the specifications & design from the Rosarot, we theoretically should have taken the time to look at and understand everything in some detail. This would have benefited us because we:
-
would have identified certain issues earlier and could have fed back early.
-
we would have known the project better during the operational phase and thus would have been more efficient.
Learning: We must take more time before the operational start.
Additional remarks:
-
Management Organization Phase CheIT (+)
CheIT, and Anna in particular, worked very well during the organization phase. They met the short deadlines and delivered the necessary information on time. In addition, they very quickly dived into the complexities of the web project and clarified many important ambiguities. Moreover, the response times to questions from our side were short.
Additional remarks:
-
More time for exploring, more information about the project, little time for the initiation stage.
-
Targets, aim, stakeholders, responsibilities etc. (documentation from CheIT)
-
1 Google doc for comments etc.
-
In general more details
-
Desktop Design (-)
The desktop design was flawed and unclear. Because of this, we had to comment a lot. During this phase, we theoretically should have stopped and sent the design back for revision.
However, we did not stop the communication between CheIT and Rosarot for a long time. This was the second and most important killer factor.
When we later contacted Rosarot to place our displeasure, Rosarot made us understand that they could not do a revision of the design for efficiency reasons.
As a result, we settled on a squishy "not pixelperfect". This was well kept across the project, but we or our technicians had to interpret things over and over again (inefficiently).
Furthermore, there were phases during testing where we had to point out this "not pixelperfect" agreement in pink.
The design was often adjusted afterwards by Rosarot. This is an absolute no-go.
Learning: The design must meet a certain standard. Obviously heavily flawed design will cause extra work for us, "not pixelperfect" is not a solution.
Additional remarks:
Suggestion: When Rosarot finishes design, they integrate all the blocks in separate tabs.
-
Mobile Design (-)
The mobile design was submitted later for capacity reasons (pink). Again, we theoretically said yes to something uncertain.
The design was even more flawed than the desktop design. On one page, simple boxes were not placed at the same height.
The statement from Rosarot would be, when in doubt, the desktop design is the standard. Again, a lot of room for interpretation (inefficiency) for our engineers.
Learning: The mobile design must be submitted with the desktop design. In particular, we will talk about virtually exclusively individual pages.
Additional remarks:
-
Time Plan (-)
We set up and delivered a schedule. This schedule included the classic phases of a web project. However, the schedule was overturned due to the manual input of the content by the customer. We "had to" accommodate the client’s absences in this regard. This changed the entire planning. Additionally, we decided to do the testing sprint-wise. During these sprints many change requests were received. Due to these change requests, the schedule suddenly went wild. Towards the end of the programming phase it was no longer clear when the next sprint would arrive and when OneLine or Rosarot would have to stop testing. A rather dangerous state for a project.
Learning: We need to create a clear schedule at the beginning and stick to it. If change requests change the schedule, we have to recalculate the plan or postpone the change requests to the after-go-live.
Additional remarks:
If we do some type of time switch we inform the client about the changes in advance.
-
Testing (+/-)
Due to the scale of the web project, the decision to test in sprints was correct. This helped to test with a certain focus level.
Testing in Excel is not optimal. In the end we had 3 task lists
-
Internal task list
-
Tasklist Pink
-
Task list FGZ
Transferring tasks from one list to another is not efficient.
Rosarot tested within a reasonable time. The problem was rather that the "not pixelperfect” was interpreted differently at times. A certain level of detail was expected, which in our opinion did not match the level of detail of the delivered design. In addition, certain tasks suddenly appeared in sprints that had already been completed. We therefore had to repeatedly retest areas that had already been tested. This led to a lack of overview and inefficiency.
Learning: For large projects, we need to evaluate new testing tools. Tested areas must remain closed. If new tasks are added again and again, time becomes critical.
Additional remarks:
-
Programming by CheIT (+/-)
The programming from the home page was good. Only a few tasks could be found.
During the sprints the delivered pages were very faulty. At a certain point, certain pages had to be sent back for reworking.
In addition, after testing certain areas, errors reappeared at a later point in time. This must be kept within limits.
Learning:
Additional remarks:
-
Communication Tool Slack (-)
Communication with the technicians via Slack is suboptimal. In the hot operational phase, so many threats were open in Slack that the overview was lost. Communication histories could no longer be found. At times, communication was switched to mail to maintain an overview.
Learning: One channel for the whole project? New tools?
Additional remarks:
-
Triangular Communication FGZ- Rosarot-OneLine (+/-)
Talking directly to the customer has certain advantages (e.g. shorter lead times, fewer misunderstandings…).
At the same time, the FGZ often approached us with requirements that were not in the specifications. If the FGZ had to go directly through Rosarot, communication in this context would be more efficient.
Furthermore, in this project, the statement "one can assume that…" was often made. The reference was to functions that were not explicitly mentioned in the specifications. For example, automatic deletion of agenda entries with a date in the past,
Learning: Direct inquiries about missing functions to Rosarot? It would be good to have a Single Point of Contact with customers.
Additional remarks:
-
Go-Live (+/-)
The going live process was suboptimal. On the day of going live, certain accesses (recaptcha key, backend access) were still requested, which brought uncertainty into the process. This could have been clarified beforehand.
At the same time, it was communicated that a placeholder screen would be displayed, but this was not actually displayed. This also led to uncertainty on the part of the customer (Are there problems with going live?).
To go live with this project on the exact day is a success. Moreover, the site has been launched according to schedule.
Learning: (Not specified)
Additional remarks:
-
After Go-Live (+/-)
After the go-live, errors suddenly appeared on the page, which were corrected. After deeper research, we have been told by CheIT that these errors occurred due to a speed optimization error.
-
How can this happen?
-
Why were we not informed about this?
Learning: (Not specified)
Additional remarks:
-
Budget (-)
According to Toggl, OneLine’s time expenditure was 295 hours. This number probably speaks for itself.
Learning: Communicate extra work earlier. Mid-project meeting?
Additional remarks:
Overview
Retrospective
Friday 
