Inspired by the Isaac Asimov’s Three Laws of Robotics, and the Laws of Identity which I posted in the previous entry. I came up with my own Five Laws of Project Management based on my own personal experience in managing projects. (BTW I personally need to improve in these as well.)
Transparency, Boldness & Effective Communication: To me these are the most important personality traits required by a Project Manager. Transparency helps in managing the expectations of all stakeholders including the business, the management and the project team and boldness enables the project manager to remain transparent even in the time of crisis.
Many Project Managers who are not transparent, bold or cannot effectively communicate fail to raise the issues at the right time or bring a true picture in-front of management. The Project Manager should have a strong character and should raise the issues at the right moment. For example, issues like time limitation, lack of resources or unclear scope of work should be raised immediately and with strength. It is much better not to undertake a project or simply say “No” then to fail it, especially when you know in advance you are going to fail and you simply kept quite on that. Similarly, issues with the team like quality of work or delays in deliverables should be immediately highlighted and communicated to the team members.
Keeping this balance between the business, management and the team through effective communication while still managing the actual work is one of the most difficult challenges.
Documented Scope of Work: Most developers don’t like to write documents, instead they like to code and they start coding during or even before the requirements analysis is complete. Never write even a single line of code without a documented and clear scope of work which has been signed-off by the business or management. The lack of a signed scope of work is bound to put you in a loop. The loop of continuous changes and requests which will go back-and-forth between the client and your team for months if not years.
Also, always keep the scope document updated even with the slightest change in detail during the course of the project and get these updated documents signed. Having an updated and signed scope of work by the end of the project will save you a lot of trouble which generally people go through for project closure.
Team Work: I believe that “Only great teams produce great software”, so be very careful while selecting the team. The limitation of team members in numbers or in competence is one of the biggest reasons for failed projects. Make sure your team members are competent to do their job and are team players.
In case you are stuck with a team which is limited by number or have some members which do not have the required skills and you do not have the control to change or increase the team, then always factor in extra time in the project plan to cover for them.
Never create a project plan without knowing the team members and their skills. Many times I have seen project plans being made only with dummy R1, R2, R3 etc without even knowing or even without hiring the actual team members. Always remember that all team members do not have the same level of expertise and hence tasks cannot be assigned equally to R1, R2, R3.
Time Management: Efficient time management is also a big factor in overall success of the project. Nearly all Project Managers plan a little more time than actually required to complete a tasks, this time is called buffer. The buffer plays an important role for risk management and managing unforeseen issues and problems during the project.
However, in most cases the buffer time is used as a luxury and is wasted in the initial days of the project, either through a slow pace of work or simply relaxing because the project managers feels he has a lot of time on hand. This strains the project and the team at the end and if in case any unforeseen problem really comes along for which the buffer was originally intended, the project is delayed and gets into trouble.
So, never put-off the scheduled work for tomorrow even if you have a lot of extra buffer. Try to complete as much work as you can at the start of the project. Having some time at the end helps in better testing of the product and also helps in improving the product by adding additional (icing) features. It also saves the team from unnecessary strain.
Successful Closure: “Celebrate only after fully completing the Job”. Some project managers celebrate the achievement of certain crucial milestones in the project with great enthusiasm and consider the “Job Accomplished” without actually realizing that certain less important modules/tasks in the project are still not complete. This not only gives a wrong perception to the team but also these smaller less important things which are not considered “success factor” , in the end cause the failure or at least undermine the success.
For example, testing and documentation are a few phases which almost always take a hit because the project manager and team celebrate the “end of development” which such enthusiasm that they consider the Job completed and give less importance to the remaining phases. This results in multiple patches, service packs and fixes to the original product undermining the hard work and the success.
The successful closure of the project generally requires as much as hard work as in the start of the project. Becoming less focused at the end of the project always ends in issues which become apparent at a later stage. The Project Manager should remain focused till the Project is fully completed with all phases and in every detail so a true success can be celebrated.
Update 1: Take a look at some of humorous Project Management Laws which I found here.
Aleem's Weblog 