I have been working as a Project Manager for about 6 months now (before that I worked as a Project Coordinator). During this period I took over a project from another project manager and saw it through to completion. Below are some of my observations on software project management and the lessons learned in the past 6 months:
- Don’t assume anything; if necessary ask redundant questions just to be sure.
- When preparing any schedule always keep in mind time for breakfast, lunch, sick leaves and casual leaves.
- When planning something, walk through the entire process/solution to identify dependencies and whether any steps have been missed.
- Work/tasks may not be completed within their estimates.
- A high priority task may arise in a more commercially important project and resources may be shuffled.
- Resource taking an unplanned day off or calling in sick.
- Jira issues or existing bugs that must be fixed for free.
- Need to update documentation (LLD etc.) to reflect changes made to fix these bugs. Also new documentation requests.
- Need to work on change requests that are billable.
- New bugs (Jira issues) reported in bulk during the weekend. Resources are not interested to work on weekends though lots of new issues are reported in the weekend.
- People not registering time to appropriate tasks.
- When there are multiple errors/changes, need to prioritize which fix/change must be made first.
- Always keep some buffer time before communicating any deadline. The buffer time may be used to fix last minute bugs or for QA. Specially useful if this is not disclosed to rest of the team; i.e. they will know that the deadline is one day before.
- We had 10 changes – 5 were approved, 5 were awaiting approval. The deadline for all 10 tasks was fixed with duration of 15 days. After 10 days they approved the remaining 5. But now we have only 5 days to finish 5 bugs while the first 10 days were quite relaxed. SO WE MUST HAVE IDENTIFIED THE 5 TASKS (THOSE AWAITING APPROVAL) AS A RISK AND COMMUNICATED AT THE VERY BEGINNING THAT WE MAY REQUIRE AN EXTENSION. OR, MAYBE WE COULD HAVE STARTED WORK WHILE AWAITING APPROVAL – BUT SHOULD CONFIRM WITH CLIENT BEFORE STARTING WORK.
- Crisis Management:
1. Get rid of as many errors as possible to regain client confidence.
2. For this team may have to work on the weekend. To motivate offer them extra payment such as 1.5 times of usual.
3. Tell them work is coming to an end, so, this is the final push.
4. Appoint a dedicated QA (if there is none).
5. PM should be the central point of contact even though it’s not the most convenient position.
- New bugs steadily being reported which tend to have high priority as they are bugs in existing system. Also bugs have different severity levels.
- Most changes (but few bug fixes) have a corresponding documentation change. It might be good to complete the documentation as soon as the task is completed.
- Some errors may actually be a requirement change. So, need to be careful about such changes disguised as errors and how they should be billed. Also, there is a documentation change in such cases.
- Need to set a schedule for each chunk of work.
- Seek process efficiency, for example, if email can be replaced by maintaining a common Excel file.
- Always have something/work for all resources.
- Rarely anything happens on schedule – WHEN POSSIBLE, ALWAYS KEEP ONE DAY IN HAND.
- The client likes/prefers to talk on the phone. So, when any questions/doubts just call them up instead of creating confusion over email, especially regarding deliveries etc. (DK: 10AM = BD:3PM)
- Deploying in the first half of Thursday could be a good option because it gives client (who follows CET time) time to test in the afternoon and provide us feedback. This also gives us time to work on any feedback.
- When committing to a deployment on a tight schedule, such as tomorrow (or the next day), first confirm with the team what they can deliver/deploy. Second, to manage expectation, inform client that there may or may not be reopen issues (which may be reopened by client testing) which we may or may not be able to accommodate. Third, if the team identifies that there may be tricky issues that may require extra time, definitely inform about it. Finally, if you have the luxury, definitely keep 1 day in hand.
Continued in Part 2.