DEV Community

Cover image for Lessons I have learnt from Project Management
Dylan Oh
Dylan Oh

Posted on • Updated on

Lessons I have learnt from Project Management

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).

2) 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.

3) 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.

Do follow me for more future articles on web design, programming and self-improvement 😊

Discussion (3)

Collapse
lifelongthinker profile image
Sebastian

Regarding #3: I totally agree. One common excuse (from the client perspective) for changing or adding requirements after the project has entered some crucial phase: It's just a minor thing to add/change.

The truth is: Many major pain points used to be just "minor things". If it's small enough to be "minor" it shouldn't be a big problem to postpone it to a later release.

Another pattern to watch out for here is under-specified requirements: Things that look simple at first glance but turn out to be much more complex once you get to understand them better (which typically happens during the implementation phase).

Collapse
ohdylan profile image
Dylan Oh Author

Thanks for the add on Sebastian! This would be valuable for all of us who are going through the journey

Collapse
lifelongthinker profile image
Sebastian

Oh, and thanks for sharing your experience, Dylan πŸ‘πŸ‘ Good points!!