Best Practices of Project Management

40 Commandments of Project Management

In this article, I am trying to put Best Practices of Project Management in the form of 40 Commandments of Project Management. Project management is a complete subject like marketing, finance, or operation. It is not possible to bind do and don’t of this profession in certain commandments. But to begin with or in the absence of any formal project management system in place if a project manager pays attention to following practices s/he will be able to manage with the least pain to him, his team, and customer. My delivery experience on the business side has been in IT projects but being a project management trainer I meet people across the industry and they share their own good or bad stories. Based on all the inputs I received and my experience I and trying to put these practices in the shortest possible way. I understand there are many things that are not mentioned or elaborated enough therefore if you need any clarification or help you can write in the comment box or connect with me.

Do not get dragged away with the word “best practices”. What works for someone and his customer is best for him/her. What will work for you? You will know this only trying what worked for others. Over the years of many ups and downs, observations, conversation with other experts what worked for me and those who shared their expreience is mentioned in this article.

Planning

Involve testing team since day one of requirement gathering.
Never proceed with the plan until it is reviewed and approved by related stakeholders. If it is taking time then move with your ad-hoc plan.

Change Management (Requirements)

Have a system and processes in place that can categorize off-specification (was not asked but done), change requests (was asked but not done or differently done), defects (asked for a requirement which is implemented, but it is not working as stated).
Categorize change requests in terms of efforts. For example, <1 hour, 1-4 hours, 4-8 hours, <=1 week, <=2 weeks
Categorize change requests in terms of impact on different parts of the system. For example, none, small, medium, significant, architecture break.
The change request must be handled very carefully, impact analysis, change in plan, and approval from stakeholders need to be considered.

Scope/Requirements

Before your team starts coding or even designing understand the requirement through multiple means.
SRS must be reviewed and approved by the client-side authorized person.
HLD must be reviewed by a technical peer thoroughly and approved from the client side.
Stick to project scope; never ever go for gold plating. First, protect the scope and deliver as per the scope.
While protecting scope keep the business value of the work you are doing in mind. Do not just defend the SRS / Design while ignoring the business value of the work that is being done or should be incorporated.
If possible build a prototype first.

Work Management & Reporting

Work authentication system must be in place before we start execution on the project.
Identify metrics first so that we can measure our improvement and progress.
Establish roles and responsibilities very clearly without any grey line.
Establish reporting line very clearly.

Estimation & Planning

Wherever possible involve the team in estimation.
Never stop estimation. At every stage and phase in the project estimate the remaining work. So, post-define phase and post-design phase estimation is a must.
Sizing of the project is a must. (It helps in knowing the productivity, size variance, scope change, cost increase, etc). Size is not effort estimation.
Follow your plan. If you are not comfortable then change your plan first take the approval of stakeholders and then follow it
Always know your threshold limits for each project objective (cost, time, quality, risk, scope) and track your project progress using these.

Risk Management

Always keep a backup of resources on your project and use those resources for code review, research, documentation purpose.
Risk management is proactive work. Regularly schedule meetings with stakeholders and the project team to discover new risks. Do not look upon risk as ever bad things. They are the gateway for opportunity and threat simultaneously.
Review and update risk register on a regular basis
Be very cautious about efforts, schedule in UAT, and on Support activities. If you do not plan properly they suck a lot of time and keep resources idle.

Responsibility

For windows/web-based applications where look and feel are very important keep at least one dedicated UI designer co-located with the development team. The development team should be responsible for making UI approved by the customer (do not give this approval taking responsibility to the UI team).

Management Style

Switch your management styles from one phase to the next phase. You can be more democratic when starting the project, but more autocratic when the project in execution or toward the finish.
Striking a balance between authority and accountability is critical to take care of project reporting and escalation.
Recognize people to keep them motivated.
Do not encourage/promote heroism but a team spirit.
As much as possible take consensus, opinion and move ahead with a unanimous decision.
In projects meetings/ group discussions never be partial or favor an individual, favor an Idea.
To take a decision if you have to choose between organizational Process assets (OPA) and your personal experience then choose OPA, you will be in a better position later on.

Team Motivation

Build a team area for every project where artifacts about the project such as mission/purpose, measurable business results, project plan, daily plan, etc are posted.
Conduct daily team meetings with the entire team and make each individual on the team accountable for tasks he/she owns, monitor the project on daily basis, and resolve day-to-day issues with the entire team.
Allow team members to make their own plan for the week based on the project plan, at the same time dependency and constraints of the master plan must be respected.
Create an atmosphere in the team area that fosters open communication.
Make sure the team has fun working on the project. Be creative in setting up an environment where the team is not stressed due to work pressures. Work pressures are inevitable stress can be avoided.

Monitoring

Never be afraid of giving bad news on the time it is better than giving it late or the receiver gets it through other channels.
Verify the plan regularly to foresee early overruns. Attribute the overruns to issues/risks/defects etc. Using the established processes address these overruns timely. If in doubt whether a certain item is a valid risk/issue always raise it and make it visible to the internal stakeholders. And document the resolutions arrived upon.
No long duration sitting meeting in productive hours or productive days. 10-15 minutes meeting of entire team on everyday basis is a must.