This blog posting was originally composed in a Project Management Case Studies class. We discussed the qualifications of a Project Manager and how to become a PM. After some thought this was my response posted on the class discussion board.
* * * * *
The discussion in class about how to become a PM was very good. I am sorry if I was not much help. Maybe I can color in a few things here.
The skills of a PM are part art and part science.
The art part includes things like people skills, intuition, leadership, communication skills, psychologist and Den Mom. Being able to diffuse a project crisis with in the team or between stakeholders. Building relationships of trust across functional areas and with in the project team. These are the soft skills.
The science of being a project manager involves the technical “stuff” in the PMBOK: Making a Gantt chart and knowing how to use it in a project. Calculating CV, SV, CPI and SPI (PMBOK page173 – 174). Being able to identify scope creep and stopping it. Building budgets and resource plans. Being able to negotiate with vendors for material and resources. These are the technical skills.
Then there is the passion for the practice of Project Management. You have got to love it and breathe it in all you do, work and home. You have got to love taking the risk of being project owner/leader. You crave walking the line between the terror of failure and the exhilaration of success. You are willing to take a public bullet for the team and then step out of the spot light when your team pulls it off in the extra mile. You learn from failure and celebrate success. You always desire to become better and raise people up in the process.
This is the art and science of Project Management in my view. So… You still want to be a Project Manager? How do you make it happen…?
You just do it. Every project around the house use something new from the PMBOK. Judge your performance by the number of trips you make to Home Depot before your project is complete. Do PM at work. Write a brief scope statement for the latest assignment the boss gives you. Make a WBS and build a time line. Then follow it. Calculate where you actually are relative to the plan. Make adjustments. Learn the technical “stuff” of PM.
Be around senior Project Managers. Watch them in meetings, deconstruct their communications. Ask questions. Work into a PM position starting as a Project Coordinator. Become a member of PMI and volunteer to run a project for the chapter. (This is where I saw great project management modeled.) Set the goal of becoming a Certified Project Manager (PMP). Get project management input through books, magazines and the web:
Cornelius Ficthner has a podcast titled “Episode 62: How Can I become a Project Manager.” This link should get you to the podcast:
http://www.thepmpodcast.com/index.php?option=com_content&task=view&id=109&Itemid=9
Thomas Cutting writes a wonderful blog of PM lessons learned and techniques that are beneficial to him:
http://www.cuttingsedge.com/
I believe luck happens when preparation intersects opportunity. So start preparing and watch out for opportunities to be a project manager. Your preparations will open your eyes to places where the science can be applied. And as you apply the science you will improve your “artistic” skills of managing projects.
Go for it!
Showing posts with label project management. Show all posts
Showing posts with label project management. Show all posts
Tuesday, July 15, 2008
Monday, February 26, 2007
Wikis and Blogs Transforming Project Management
This link goes to an interesting article about how Wikis and Blogs can change the workflow of a company. I thinks there is application to managing projects.
http://searchcio.techtarget.com/originalContent/0,289142,sid19_gci1184607,00.html
As a project manager, I see real value in using both in project work. I like the idea of using a Blog for communicating the project status to the team and the stakeholders. The monologue with comments becomes a place where stakeholders can pull information about the project when ever they need it. Traditionally the PM pushes out information to the team. I also like the idea of having the whole project history in one place. The helps to centralize the "story" of the project and collect lessons learned for the application in the next project.
Wiki’s are a great collaborative tool. When you have a team that is separated by time and or geography, I can see how working on a project schedule in a wiki would be valuable. Each member can input the expertise into the schedule listing tasks and durations. In the end there is a complete schedule that has the whole team buy-in. Other PM areas can benefit: Risk assessments, Quality feedback, an RFP process, even laying the ground rules for the project could be hammered out in a wiki. Even a project team that is local can benefit by working together… Project the Wiki on a screen in a conference room and take meeting minutes, document assumptions and capture “group think.” Then when the meeting is over, the team can continue making additions as ideas come to mind, everyone can access the information during their project work, and the team collaboration that was started in the meeting can continue.
The interesting thing here is transparency. If used correctly there are no hidden thoughts, no undocumented assumptions and no project surprises. These two tools allow stakeholders to look inside the project as it is happening. The stakeholders can interact with the project by commenting, asking questions, encouraging the team, etc. While the stakeholder is "watching" the inter-working of the project, they are validating the scope... "Is this what I really wanted as my deliverable?" If not, corrections can be made as early as possible in the planning or execution phase. If the deliverable is right, the stakeholder is able to watch its development and have a deeper understanding of how the use and deploy the final deliverable. There is an early "bonding" of the stakeholder to the project deliverable that will reduce the chances of the deliverable being rejected at birth.
Unlike the traditional status report that is e-mailed out every Friday and not read, the Wiki and Blog put the ownership of getting the project information on the stakeholder. Any time an update is needed (even if it is not Friday) a stakeholder can get an update. This is important... these tools may keep the stakeholder from calling or e-mailing the PM, using up both of their valuable time. And in the e-mail scenario, the stakeholder is waiting for a response from the PM, when they could have checked the Wiki or the Blog for an up-to-the-minute project status.
Yes the PM is responsible for keeping the tool(s) update. I would submit, however, that the PM can push some of the administration work of updating to the project team. The team members can input up-to-the-minute information on the status their tasks on the WBS. They can report successes and road blocks. In most cases the PM is calling, meeting with or e-mailing the team members. Then the PM is reforming the information from the team into a status report for the stakeholders. This takes a lot of time on the part of the PM and the team.
The same project status information, kept more current, in a conversational medium, accessible anytime, created with team buy in, that saves time and improves communication efficiency is worth trying.
Good luck with your try and let me know how it work for you.
http://searchcio.techtarget.com/originalContent/0,289142,sid19_gci1184607,00.html
As a project manager, I see real value in using both in project work. I like the idea of using a Blog for communicating the project status to the team and the stakeholders. The monologue with comments becomes a place where stakeholders can pull information about the project when ever they need it. Traditionally the PM pushes out information to the team. I also like the idea of having the whole project history in one place. The helps to centralize the "story" of the project and collect lessons learned for the application in the next project.
Wiki’s are a great collaborative tool. When you have a team that is separated by time and or geography, I can see how working on a project schedule in a wiki would be valuable. Each member can input the expertise into the schedule listing tasks and durations. In the end there is a complete schedule that has the whole team buy-in. Other PM areas can benefit: Risk assessments, Quality feedback, an RFP process, even laying the ground rules for the project could be hammered out in a wiki. Even a project team that is local can benefit by working together… Project the Wiki on a screen in a conference room and take meeting minutes, document assumptions and capture “group think.” Then when the meeting is over, the team can continue making additions as ideas come to mind, everyone can access the information during their project work, and the team collaboration that was started in the meeting can continue.
The interesting thing here is transparency. If used correctly there are no hidden thoughts, no undocumented assumptions and no project surprises. These two tools allow stakeholders to look inside the project as it is happening. The stakeholders can interact with the project by commenting, asking questions, encouraging the team, etc. While the stakeholder is "watching" the inter-working of the project, they are validating the scope... "Is this what I really wanted as my deliverable?" If not, corrections can be made as early as possible in the planning or execution phase. If the deliverable is right, the stakeholder is able to watch its development and have a deeper understanding of how the use and deploy the final deliverable. There is an early "bonding" of the stakeholder to the project deliverable that will reduce the chances of the deliverable being rejected at birth.
Unlike the traditional status report that is e-mailed out every Friday and not read, the Wiki and Blog put the ownership of getting the project information on the stakeholder. Any time an update is needed (even if it is not Friday) a stakeholder can get an update. This is important... these tools may keep the stakeholder from calling or e-mailing the PM, using up both of their valuable time. And in the e-mail scenario, the stakeholder is waiting for a response from the PM, when they could have checked the Wiki or the Blog for an up-to-the-minute project status.
Yes the PM is responsible for keeping the tool(s) update. I would submit, however, that the PM can push some of the administration work of updating to the project team. The team members can input up-to-the-minute information on the status their tasks on the WBS. They can report successes and road blocks. In most cases the PM is calling, meeting with or e-mailing the team members. Then the PM is reforming the information from the team into a status report for the stakeholders. This takes a lot of time on the part of the PM and the team.
The same project status information, kept more current, in a conversational medium, accessible anytime, created with team buy in, that saves time and improves communication efficiency is worth trying.
Good luck with your try and let me know how it work for you.
Subscribe to:
Posts (Atom)