Technical writing – Project Self-reflection

Written by: Timur Radman

I have worked on Neesh, a project founded by Bin and Ying (former pre-MDM students), for two months. I was the project manager in my team, which is not something I usually do at all. But this is why I joined the pre-MDM program, to get out of my comfort zone and do what my dream job would someday require.

As we started the project, my tasks were simpler than my teammates, even if they were not necessarily within my field (that is, development.) The team at first didn’t make much sense, two developers, and the rest are graphics and UI/UX designers, and as far as we could tell, we had to deliver something well-made but not necessarily practical for the project just to be graded. However, we were told that our deliverables must satisfy our clients working on an actual project. Suddenly, the structure of our team started to matter a lot.

This is the first time I have done this. I’m talking about running a team that has to deliver a prototype of a new or improved feature that has been tested at least twice. I didn’t know how or where to start, but I knew I had to start.

The first step was to analyze the prototype our clients had already. We were blown away by how detailed their project documentation was and how polished their prototype was. It simply seemed as if nothing we could do about it, yet we had no choice but to surf through it in hopes of finding something.

After we finally found what we thought would make a good change/improvement for their prototype, we came across the first challenge any team would experience at least once, rejection, which is a tough pill to swallow (nailed it.)

After a long debate, our clients made it clear that our proposition changed the core of what they wanted in their app. Additionally, the fact that they gave us two days to decide on a feature to test and iterate added more pressure as we had to submit documents based on our choice.

We had an urgent meeting that day, and we ended up going for something that I didn’t believe would work. We decided to work on the notifications system: add more features and improve the design. This proved to me the value of working in a team because I didn’t think our clients would approve of our choice, but I was surprised that they liked it a lot and even said that this was a part of their project not satisfied with.

With the feature to modify approved, we started working on the documents. Thanks to Liting, a teammate of mine experienced in real workplaces and projects, I learned how to arrange meetings and make the best use of our time there. And just like I was pushed out of my comfort zone and do project management, I recommended my teammates do the same. Han, for example, instead of working on visuals which she and 3 other teammates are good at, had to do research and design questionnaires which is something she didn’t do before, using a tool that she wasn’t familiar with, Google Forms.

As a project manager, the success of my team’s work determines my success, so I was often paranoid about getting things right. Seeing my teammates learn something new that I recommended made me feel like I was doing my job right. And because of my role in the team, I had to communicate with our clients and tell them about our weekly progress weekly on our Wednesday meetings; I was the one in the front line constantly. And I can’t say it was easy, but it got easier over time, and I’m still working on it.

After a couple of weeks, we were asked to conduct a user test before making a final design choice. We did precisely that and tested our design with multiple users (over 40 users,) got our data together in a detailed report and presented it to our clients in an official presentation. To my surprise, they were stunned by what we did and said it was better than what they had in mind, which significantly boosted our morale.

Although conflicts were something that we were expected to come across during our two months of work, we managed to stay away from them throughout the duration of the project. This doesn’t necessarily mean our opinions and ideas didn’t clash, especially mine and other teammates, but we managed to handle it like a team and adults. And I was occasionally reminded that I could be wrong even when it seemed to me that what I was doing was right by a simple technique that we just did naturally, voting. Every time we have two different opinions within the team, I call for a vote, we vote, and the disagreement is settled.

I’m fully aware that things won’t be so peaceful and smooth in the future. Still, I think a relaxed environment like the one I had for Neesh helped me get better in other things like improving my low self-esteem, taking it easy when speaking in public, realizing that I can lead a project successfully and learning more about tools I never used before like Canvas and Figma.

Eventually, after conducting a quantitative and qualitative test and polishing our final prototype, we had a big final presentation where we recapped everything we did during the two months and showed it off to an audience that was bigger than I thought possible to have in our classroom. Even though it was stressful, I am so glad that Aida took the time and effort to invite people to see us.

It was one hell of a journey, and despite the relief of being done with it, I will miss my team and the time we spent together.