After about 2 years in my current company (BGlobal) and successfully completing several projects, naturally many new lessons were learned and I will be listing those below.
- When there are a lot of pending tasks that haven’t been prioritized, ask the client for prioritization.
- The ‘Notes’ tab (double click on task and select ‘Notes’ tab) of MPP files can be put to good use by entering the relevant information from the approved scope/requirements documents as well as other information such as assumptions etc (i.e. a WBS dictionary entry).
- Try to review requirements that are emailed in English. Some, developers may not ask for it or admit it, but they would definitely appreciate your help in understanding the requirements due to their English language deficiencies.
- If there is a big high priority task in progress, break it down and share timeline with client.
- If there is a high priority task to be delivered the same day and work is in progress beyond expected delivery time, inform the client that work is still in progress (and we hope to deliver today) – otherwise client may start making changes on their side. This is especially applicable if you are working on the client’s server.
- If you are expecting revision rounds, inform the client beforehand.
- For a highly personalized/customized site such as RTime there are likely to be many PSD designs and hence the corresponding PSD to HTML conversion work.
- Security and performance measures must be built into the site from the very beginning of development.
Very important for developer to discuss individual approaches to a functionality, so that no issues arise during merging different modules. Scrum meetings can be platform for such discussions.
- Merging issues mentioned above can also be mitigated through the creation of a project plan with appropriate task breakdown.
- Be wary of adding more resources when working on a tight budget; it can become very difficult to control the hours logged.
Be wary of the scenario where there are multiple profiles in one account – need to ask questions such as “Who’s photo will be shown on the dashboard?”; i.e. where will user get option to edit items common to the account or all profiles.
- SVN code conflicts are very likely to occur. Raise awareness of the problems that arise when such conflicts are not resolved properly (code is overwritten so that previously working functionality does not function any more) and guide people on how to use available tools (such as Tortoise SVN) properly.
- Before testing on live site and creating test accounts etc., need to plan beforehand how the test data will be removed.
- If you notice people/team members slipping (not performing at optimum level, not taking full responsibility etc.) inform relevant personnel/manager ASAP (discreetly if necessary); don’t wait until later.
- It’s very important to find a way to deal with stress. What worked for me is when I am with my dear and loved ones, I tried to spend a cheerful time, not allowing the work related stress to creep to the forefront of my mind.
- Even when being bullied by the client, getting loud is not the right approach. Always be polite!
- If the client keeps on finding bugs, be prepared to do some free changes to keep the client happy (and of course fix the bugs too).
- For dynamic pages (pages with ? or = in url, generated from content stored in DB), discuss from the onset whether they should be SEO friendly and what we can do to make them SEO friendly as such URL are inherently discouraged by Search Engines.
- A complimentary message from the higher ups (client, management) midway through a project (especially one that is perceived as at risk) can go a long way in boosting moral.
- Don’t agree to provide a timeline until all requirements have been clarified.
- If all required development resources aren’t available during a production deployment, inform the client accordingly – the client may agree to postpone the production deployment.
If possible, initiate the process a day early.
- Access to any site.com can be blocked using a basic authentication via .htaccess file.
- Even if the client hasn’t said anything about it, beware of any test content in the site before going to production.
- Ask client for a staging site where they will review and approve for deployment to production. If client doesn’t have one, we can create two sites: one “dev” where testers will test and one “stage” where client will approve.
- If you are a client its a great idea to have twice weekly meetings with the outsourcing company – great way to maintain momentum on the project.
- Once you ask for more (in a fixed budget project), even if for genuine reasons (such as out of scope work, or new changes) beware that client is going to be very critical about everything and can make a huge fuss about very simple issues or even blame you for things that you are not responsible for.
- Domain propagation (change server/hosting associated with a domain name) can take upto 72hrs, though in the US and similar countries it can happen within 7-8hrs, I.e USA will see the affect of the change in 7-8hrs. Hence, the site will show in USA from the new server in 7-8hrs.
- In general keep everyone informed about what is happening with the project including developers. For, example client is paying extra for changes – let the developers know. This will prevent them from propagating misinformation or wrong information such as “we are receiving new requirements after work is completed” (implying PM not doing his job properly).
- If negotiating a budget increase even for valid reasons such as accommodating change requests, be prepared for greater scrutiny and a more critical client.
- Definitely need to discuss change management or how handle enhancements in the contract or start of the project.
How do we handle things that were not specified and we had to take a decision?
Change Management MUST be defined UNAMBIGUOUSLY in the contract.
- Some clients can lie when it is convenient for them…
- Be wary of a situation/project where there is no dedicated QA team/personnel.
- If collecting client’s requirements, need to break it down into modules that can be used to create the project plan.
- The resources you work with are very important; they determine the success of your project as well your success as a manager.
- If something has to be made live before a long weekend/holiday, ask the client if it really has to be made live before the holiday because there may be issues after the launch and no one will be there to fix.
This way client can decide based on the importance of the feature.
- QA full cycle or go ‘back’ (regression testing) as much as possible.
- Whether your communication tactics/techniques will be effective or not depends in part on whether your opponent/counterpart has the same objectives or not.
For example, your only objective may be successful completion of the project but your counterpart may have additional objectives such as saving face or establishing authority.
- From the very beginning (or, starting from requirements collection) ask client to prioritize each and every requirement; i.e. indicate the importance of each requirement. This information can be used to rank the requirements by order of importance and hence, be delivered accordingly.