If you are reading this, either you are already managing a project or will be in those shoes shortly.
This is not a post on the multiple ways to become a good project manager, as I believe there is no definite recipe to become a succesful project manager.
I'm no Management Guru, but my experience coupled with multiple discussions with my fellow project managers and other experienced managers at different levels has brought me to the conclusion that there are three important attributes in managing a project. If you succesfully manage these three attributes, you are almost there; yes almost there because there is no perfect recipe.
Let's start the otther way round, what was the wrong step which failed that project of yours . I'm sure none of us can point to one reason. When I was working with Shrikanth(name changed), a senior project manager I asked him the same question. His answer was plain 'aah the client manager wanted all the functionality under earth for peanuts '. ok, this can be one of the reasons but how many of us really have that sweet person to face everyday on the other end of the phone. The person at the other end is paying for the software we are supposed to develop, he has all the reasons to be bossy.
Kavita is a QA manager, my former colleague, she attributes failures to too many change requests from business to accommodate additional features. This, when happens at the QA or UAT phase is a real pain. Manager needs to convince his/her team to accommodate the changes. If his/her organization strictly adheres to processes, there are atleast 3 documents before the developer can proceed with the change. In a hierarchical organization, the change request from the business flows to the onsite manager on a fine Monday morning , say PST. Onsite manager does his/her analysis, sets up a meeting with the business users on Monday noon. The meeting gets pushed to Tuesday PST due to unavailability of the business users for discussion. On Tuesday noon , the meeting concludes that these changes are mandatory and critical for business. The onsite manager calls for an emergency meeting at midnight Tuesday IST to convey shrewdly that these changes are to be implemented ASAP and he needs the estimates by Wednesday morning PST. Offshore managers agree to send ball park estimates.
Offshore team has had a long day on Tuesday IST due to incorrect deployment errors of a previous release, they step in on Wednesday at 12 noon. Manager breaks the news of the changes and asks Team Lead to give him ball park estimates and also instructs the team that these changes will be taken up only after a discussion on the need for the change. Estimations are sent by EOD IST to onsite manager, who is pleased to see these estimations. There will be atleast two calls with all the top managers of offshore and this onsite manager to negotiate on the estimations. There will be discussions on the reasons to incorporate the changes and the emergency of the hour.In all these negotiations the term "ball park" of the estimations is lost is thin air .By the time the conclusion that "the change has to be incorporated" reaches the person who has to actually make the change its Thursday noon IST. Now, according to the estimations given by Lead it takes 16 hours , now its the offshore Manager's turn to get tasks done. Manager convinces the team to start work on Thursday noon and deliver it by Friday EOD IST. Where are the estimations ?
So, the first and foremost reason for a project's success or failure is CHANGE/(S) . If you master the art of managing changes you have won one third of the battle.
Keep reading this space for effective ways to manage Changes and about the other two attributes...
-- Courtesy - PM Focus Group Meetings @ ValueMomentum
This is not a post on the multiple ways to become a good project manager, as I believe there is no definite recipe to become a succesful project manager.
I'm no Management Guru, but my experience coupled with multiple discussions with my fellow project managers and other experienced managers at different levels has brought me to the conclusion that there are three important attributes in managing a project. If you succesfully manage these three attributes, you are almost there; yes almost there because there is no perfect recipe.
Let's start the otther way round, what was the wrong step which failed that project of yours . I'm sure none of us can point to one reason. When I was working with Shrikanth(name changed), a senior project manager I asked him the same question. His answer was plain 'aah the client manager wanted all the functionality under earth for peanuts '. ok, this can be one of the reasons but how many of us really have that sweet person to face everyday on the other end of the phone. The person at the other end is paying for the software we are supposed to develop, he has all the reasons to be bossy.
Kavita is a QA manager, my former colleague, she attributes failures to too many change requests from business to accommodate additional features. This, when happens at the QA or UAT phase is a real pain. Manager needs to convince his/her team to accommodate the changes. If his/her organization strictly adheres to processes, there are atleast 3 documents before the developer can proceed with the change. In a hierarchical organization, the change request from the business flows to the onsite manager on a fine Monday morning , say PST. Onsite manager does his/her analysis, sets up a meeting with the business users on Monday noon. The meeting gets pushed to Tuesday PST due to unavailability of the business users for discussion. On Tuesday noon , the meeting concludes that these changes are mandatory and critical for business. The onsite manager calls for an emergency meeting at midnight Tuesday IST to convey shrewdly that these changes are to be implemented ASAP and he needs the estimates by Wednesday morning PST. Offshore managers agree to send ball park estimates.
Offshore team has had a long day on Tuesday IST due to incorrect deployment errors of a previous release, they step in on Wednesday at 12 noon. Manager breaks the news of the changes and asks Team Lead to give him ball park estimates and also instructs the team that these changes will be taken up only after a discussion on the need for the change. Estimations are sent by EOD IST to onsite manager, who is pleased to see these estimations. There will be atleast two calls with all the top managers of offshore and this onsite manager to negotiate on the estimations. There will be discussions on the reasons to incorporate the changes and the emergency of the hour.In all these negotiations the term "ball park" of the estimations is lost is thin air .By the time the conclusion that "the change has to be incorporated" reaches the person who has to actually make the change its Thursday noon IST. Now, according to the estimations given by Lead it takes 16 hours , now its the offshore Manager's turn to get tasks done. Manager convinces the team to start work on Thursday noon and deliver it by Friday EOD IST. Where are the estimations ?
So, the first and foremost reason for a project's success or failure is CHANGE/(S) . If you master the art of managing changes you have won one third of the battle.
Keep reading this space for effective ways to manage Changes and about the other two attributes...
-- Courtesy - PM Focus Group Meetings @ ValueMomentum
