Sep 19

・2 min read

In smaller companies, we often have to be both the developer and project manager at the same time. This has made me to become a more all-rounded engineer and possess skills that are not technical-related, such as communication, project timeline management and resources allocation skills. Throughout these project management experiences, I would like to share some valuable lessons that I have learnt.

1. Do not rely (or over-trust) project manager / coordinator from clients.

As a software consulting company, we often have to deal with the project manager from the client side. According to my experience, not all the project managers possess IT / software knowledge and therefore you might want to explain most of the things in layman terms. Ensure that both parties have the common understanding before proceeding with the implementation (in order not to hear some statements like: 'Oh... this is kinda different from what we discussed...' in the future).

1. Single source of truth + meeting notes

You might want to use a proper documentation tool to keep track of all the discussed matters. Solely by emails is not a good option as we receive tons of emails everyday and some important information might be buried down the email threads. Docs management tool such as Confluence, is useful to document down proper product requirements and meeting notes. Besides, send the updated requirements docs to all the parties to ensure everyone is one the same pace and understanding.

1. Try not to amend the original requirements after the project kickstarted, unless both parties agree to delay on the timeline

We often easily agree on extra requirements that users / clients bring up DURING the development phase of the software or features. The whole project might be delayed due to these "extra little" requirements and most of the time these responsibilities fall upon our shoulders. This is my personal experience where I helped to fulfil some extra requirements throughout the development phase (which was not agreed in the original product requirements), and ended up with the consequences that users were not able to test them in time. If there are new requirements being brought up during the development phase, we should always negotiate these for the next phase of the project, else all parties have to agree on the delay of project timeline before implementing.