The Five Laws of Project Management

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.

Advertisements

7 thoughts on “The Five Laws of Project Management

  1. Pingback: The Five Laws of Project Management « Aleem’s Weblog

  2. Commenting on parts of your list, the first rule about the personality of a PM is absolutely true. I’ve observed this one. You need a thick skin and a somewhat blunt personality.

    On team work, this links into scope. The PM has to be skillful enough to keep the “gantt-demanders” at bay, who are the folks that want to see a 10,000 line gantt (for some insane reason) with every step planned out for the entire project. You have to know your team, be flexible with what you ask them to do (sometimes strict separation of duties is not possible or desirable), and tighten up the scope and the plan as you go along. However, making people sign scope revisions, as correct a goal as that is, is not always something people comply to. I’ve had stakeholder teams that refused to sign, which I later came to understand was because they wanted to find someone to blame for whatever aspect of the project!

    On time management, besides the obvious “does the team know about it and how to do it” the PM has to use axioms like Parkinson’s Law to his or her advantage.

    I disagree on the “Celebrate only after Completion”. I would revise it to say “Celebrate in Proportion” and have small celebrations for small successes in the project. Sometimes things get tense, and part of the PM’s job is to keep the machine well-oiled and happily running. Difficult, but a little tension release every now and then is not a bad thing. You just have to be careful to remind people that it’s not over yet.

    My two cents.

    Regards,
    Rick Cogley
    Tokyo Japan

  3. I agree with you on these laws and can relate to them through my duties. However, I might separate transparency and couple it with impartiality, as they are closely related. Transparency is an essential trait in a project manager, and they should not have bias or personal favorites or opinions. They do have to make many judgment calls on when to act if they see a project deviating from the path towards successful completion.

    As Rick suggested, I like the idea of celebrating milestones as it keeps the team and sponsors engaged along the journey. Even when the project is over, the most critical outcome is often the review of lessons learned from its execution, which can dampen the final celebration.

    Managing the scope is critical, which is why my colleagues at CA decided to integrate ‘requirements capture’ and ‘planning’ into PPM. Using the requirements to test drive plans is critical in delivering the right functionality. Coding the deliverable with no written requirement signed off by the customer, often leads to wasted effort and unmet expectations.

  4. Pingback: Murilo Juchem » The Five Laws of Project Management –Aleem Khan

  5. After Document slip a dilemma along these lines. It is my opinion this great site will probably assist you in preparing uncover the mobile.
    You can aquire rapid answer to open ones cell phone.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s