Most of us, unfortunately, were not given the choice that Neo was given in the movie The Matrix and we typically either land in a matrix environment or not.
I lived in both worlds and I can attest to the fact that whichever organization structure you are in - they all have their pros and cons. I can say, though, that it is the matrix environment that required me, as a project manager, to develop some specific skills that allowed me to navigate it.
Why is it tricky to navigate? For one, aside from your immediate project team, most of the people you need to be successful do not directly report to you. That means that, chances are, their priorities are different from yours and they can derail your project with less of a concern in terms of performance reviews - as long as their real boss agrees with them. There is also this need to have more communication channels which open your team up to a lot of possible miscommunications.
So what skills did I need to succeed in this environment?
1. Influence - John Maxwell, in his book, Developing The Leader Within You actually said that "Leadership is Influence" and never is it more apparent than in a matrix environment. Unlike a direct report, you need to influence more a person or team that does not report to you to buy into your plan and work with you to succeed
2. Communication - Communication takes on a deeper meaning in a matrix environment since it is the glue that keeps everyone pasted onto your objective as you try to move everyone to the goal and as I mentioned, I realized that in a matrix environment, there is a need to have more communication channels laterally since one characteristic of a matrix environment is that the org chart is a lot flatter but broader.
3. "Ball Handling" - The matrix was created for several good reasons and one of them is to allow expertise to develop in a group while allowing these experts to work in your projects - sounds good but this requires that, as a project manager, you should know when to pass the ball and to whom. This message got imprinted on me in a workshop when excepts of the movie Goal! - The Dream Begins was shown to us.
4. The ability to see the bigger picture - There were times that I needed to admit that truly my project was less of a priority than a project my matrix team was working on and I had to give way and replan my project because at the end of the day - the question is "which project stands to give the company the best possible benefit vs cost". Some days - that project is not yours.
So why does the matrix still exist amidst the complexities it has? It is only the matrix environment that allows a company to have the expertise and flexibility to execute projects through different resources. For it to be as productive as possible though - the matrix must move as one as a project manager - you are one of those people that steer it.
Thursday, September 30, 2010
Tuesday, September 28, 2010
What Difference 3 Seconds Make
Have you ever seen how politicians, CEOs and other famous people react during an interview after being asked an important question? They pause... for at least 3 seconds.
This 3 seconds technique is a very basic method but you would see it differentiates the mediocre interviewee from the great ones. Why is that?
The 3 seconds technique gives you sufficient time to
a. control your emotions. 1 second.
b. complete the translation of the question and straighten your thoughts. 1 second.
c. form in your mind how you would like to deliver your response with your intent in mind. 1 second
The 3 second technique gives its user better credibility and control and it gives the message better form and impact. Truly - what a difference 3 seconds make.
This 3 seconds technique is a very basic method but you would see it differentiates the mediocre interviewee from the great ones. Why is that?
The 3 seconds technique gives you sufficient time to
a. control your emotions. 1 second.
b. complete the translation of the question and straighten your thoughts. 1 second.
c. form in your mind how you would like to deliver your response with your intent in mind. 1 second
The 3 second technique gives its user better credibility and control and it gives the message better form and impact. Truly - what a difference 3 seconds make.
Tuesday, September 21, 2010
And the Sponsors Said "Let There Be...A Project". And There Was.
Everusince I was a young boy, around age 7, I have always been drawn to the power of the engineer to create something...a bridge, a house, a new material..even the next type of fuel. My favorite toy was even the LEGO.
I was so attracted to the idea of creation that I eventually graduated from the university with a Mechanical Engineering degree, finished 4th on the National Board Examination and I was so excited when I created my first professional design in Autocad and I saw it constructed and working - it is like fatherhood in a way when you see your creations at work.
I eventually entered the field of Information Technology due to its promised career acceleration and for awhile I missed the adrenaline rush of creation ..until my career eventually took a turn and I started managing projects.
Project creation and management brings back the thrill of creation for me. You start out with an idea - a thought. You then proceed with defining the framework on how to realize the project benefits..create your team..draw up the project plan and execute it to completion.
I am so addicted to the thought of project success that I envision it fully from the start and I guess that is one of the things that I learned from being an engineer - you have to see your final product in your mind even before you begin lifting your pencil to draw.
I have always lived by three words since I was an engineer and these words still carry me to success today - Conceive...Believe...Achieve.
I was so attracted to the idea of creation that I eventually graduated from the university with a Mechanical Engineering degree, finished 4th on the National Board Examination and I was so excited when I created my first professional design in Autocad and I saw it constructed and working - it is like fatherhood in a way when you see your creations at work.
I eventually entered the field of Information Technology due to its promised career acceleration and for awhile I missed the adrenaline rush of creation ..until my career eventually took a turn and I started managing projects.
Project creation and management brings back the thrill of creation for me. You start out with an idea - a thought. You then proceed with defining the framework on how to realize the project benefits..create your team..draw up the project plan and execute it to completion.
I am so addicted to the thought of project success that I envision it fully from the start and I guess that is one of the things that I learned from being an engineer - you have to see your final product in your mind even before you begin lifting your pencil to draw.
I have always lived by three words since I was an engineer and these words still carry me to success today - Conceive...Believe...Achieve.
Sunday, September 19, 2010
The Beauty of the RACI
The RACI chart is a standard document in most projects and I would say that it should be a standard in ALL projects ..but what is a RACI chart anyway?
RACI is an acronym and different organizations have different takes on what each letter means and that is why as a project manager, you should be aware of the standards of your client's company with regards to a RACI chart - take the time to ensure you have the right definitions because it can cause confusion later on. It is usually created when a project has just been conceptualized.
Typically RACI stands for Responsible, Accountable, Consulted, Informed. In other organizations, it can mean Responsible, Approver, Consulted, Informed or even Responsible, Approver, Coordinator, Informed. Whatever it can mean, it always answers the need to know who are the people responsible in defining and delivering the project and what is their role in EVERY task in a project. Most RACI chart requires there is only one R for each task or only one A for each task if the A means accountable - a good practive to have.
I recommend having a template of all the possible task that a project can take vs lumping them into generic work that may cause issues later on. The template can then be "customized" based on what a project requires. Remember - a task that says "complete the design document required for all data interfaces" is much more trackable and thus controllable that a task that says "complete design documents".
What is the importance of a RACI when you have a solid, trustworthy team? Each project is unique and in my experience, there is always room for assumptions and one assumption that team members usually make is that if the task is unfamiliar to them - then it might not be theirs and will taken cared of by another team member. Another situation is when the task can be performed by more than one person in a team - you can either have a case of two people doing the same work or noone doing the work.
By having a RACI chart from the start, you ensure that each person knows their role, the extent of their role, what they are expected to do in each task, if any, and how they relate to other people and their roles - a perfect recipe to prevent roles and responsibilities issues later on.
RACI is an acronym and different organizations have different takes on what each letter means and that is why as a project manager, you should be aware of the standards of your client's company with regards to a RACI chart - take the time to ensure you have the right definitions because it can cause confusion later on. It is usually created when a project has just been conceptualized.
Typically RACI stands for Responsible, Accountable, Consulted, Informed. In other organizations, it can mean Responsible, Approver, Consulted, Informed or even Responsible, Approver, Coordinator, Informed. Whatever it can mean, it always answers the need to know who are the people responsible in defining and delivering the project and what is their role in EVERY task in a project. Most RACI chart requires there is only one R for each task or only one A for each task if the A means accountable - a good practive to have.
I recommend having a template of all the possible task that a project can take vs lumping them into generic work that may cause issues later on. The template can then be "customized" based on what a project requires. Remember - a task that says "complete the design document required for all data interfaces" is much more trackable and thus controllable that a task that says "complete design documents".
What is the importance of a RACI when you have a solid, trustworthy team? Each project is unique and in my experience, there is always room for assumptions and one assumption that team members usually make is that if the task is unfamiliar to them - then it might not be theirs and will taken cared of by another team member. Another situation is when the task can be performed by more than one person in a team - you can either have a case of two people doing the same work or noone doing the work.
By having a RACI chart from the start, you ensure that each person knows their role, the extent of their role, what they are expected to do in each task, if any, and how they relate to other people and their roles - a perfect recipe to prevent roles and responsibilities issues later on.
Friday, September 17, 2010
Motivation and Team Advertisement
We all know that self-worth and recognition motivate employees more than salary although the same people would most likely say "salary" first when directly questioned.
One of the most basic way to motivate your team and improve their careers (and yours at the same time) is to recognize their achievements and allow them to develop their sense of self-worth. Always remember -even if you are the project manager, the successful delivery of a project is not due to you but because you worked with your team.
Here are some ways you can do this:
1. Give your team a wide-enough playground to play in. You can opt to define the limits of how much authority they have to decide on a project task but allow them sufficient space to be creative in the way they can deliver the task.
Resist the temptation to micro-manage and allow yourself to have a bigger role - a coach. Direct them with regards to the what, when, why and who of the project but give them space to define the how. Micro management of a project should only be considered when the project is already at a risk level that is too high for any tolerances.
2. Give them opportunities to self-advertise. If you are the only mouthpiece the project has and all communications are only going through you - you can become one of the most dreadful cause of delay -> a communication bottleneck.
By giving your team opportunities to present their ideas and communicate directly with senior management and major stakeholders, you bolster their sense of self-confidence, develop their thought processes, allow senior management the opportunity to know the names of your teammates and allow the stakeholders to recognize your capacity to form, build and manage an excellent team.
3.Make a splash for every worthy success. Don't just gather everyone together for a drink or lunch - for really worthy success stories, including the achievements of key milestones - make a splash about it! Send a communication to stakeholders, commend your team and state the new benefits or capabilities that your team has just delivered! If there were huge challenges surpassed through the leadership of individuals, mention it.
Always keep in mind that you are only as successful as the team working with you to deliver the project.
One of the most basic way to motivate your team and improve their careers (and yours at the same time) is to recognize their achievements and allow them to develop their sense of self-worth. Always remember -even if you are the project manager, the successful delivery of a project is not due to you but because you worked with your team.
Here are some ways you can do this:
1. Give your team a wide-enough playground to play in. You can opt to define the limits of how much authority they have to decide on a project task but allow them sufficient space to be creative in the way they can deliver the task.
Resist the temptation to micro-manage and allow yourself to have a bigger role - a coach. Direct them with regards to the what, when, why and who of the project but give them space to define the how. Micro management of a project should only be considered when the project is already at a risk level that is too high for any tolerances.
2. Give them opportunities to self-advertise. If you are the only mouthpiece the project has and all communications are only going through you - you can become one of the most dreadful cause of delay -> a communication bottleneck.
By giving your team opportunities to present their ideas and communicate directly with senior management and major stakeholders, you bolster their sense of self-confidence, develop their thought processes, allow senior management the opportunity to know the names of your teammates and allow the stakeholders to recognize your capacity to form, build and manage an excellent team.
3.Make a splash for every worthy success. Don't just gather everyone together for a drink or lunch - for really worthy success stories, including the achievements of key milestones - make a splash about it! Send a communication to stakeholders, commend your team and state the new benefits or capabilities that your team has just delivered! If there were huge challenges surpassed through the leadership of individuals, mention it.
Always keep in mind that you are only as successful as the team working with you to deliver the project.
Thursday, September 16, 2010
The "3 Whys" and its Power in Scope Control and Management
One of the most successful tools in your PM toolbox should be your "3 Whys".
It is a conscious process of not advocating your thoughts or countering an idea until you have been able to at ask your client aat least 3 Why questions.
An example scenario is when your client would ask you to add something in scope.
A series of Why questions can be the following set and all of them will help you to a)understand your client's motivations in making the request, b)determine the perceived value of the request from the client's perspective and c)give you sufficient knowledge to start a negotiation discussion if need be.
1. Why do you want to add that to the project's scope?
2. Why do you think that by adding it it will add value to the project's outcome?
3. Why do you think that by not doing it we will jeopardize the success of the project?
There are several PMs who rush to a decision or conclusion when a change in scope is requested without fully evaluating the true nature of the request and if it can truly benefit or not a project and its outcome.
By asking at least 3 Why questions (and more if need be), you will not only place yourself in a better position to assess the request but it will also give your client that reassurance that you are interested in more than simply execution.
It is a well known fact that one of the common questions in the PMP exam is the question of what should a PM do when a scope change is being requested. Remember - the most no-no answer is to simply say no.
A good PM should always assess the impact first of the request and the "3 Whys" gives you that good start.
It is a conscious process of not advocating your thoughts or countering an idea until you have been able to at ask your client aat least 3 Why questions.
An example scenario is when your client would ask you to add something in scope.
A series of Why questions can be the following set and all of them will help you to a)understand your client's motivations in making the request, b)determine the perceived value of the request from the client's perspective and c)give you sufficient knowledge to start a negotiation discussion if need be.
1. Why do you want to add that to the project's scope?
2. Why do you think that by adding it it will add value to the project's outcome?
3. Why do you think that by not doing it we will jeopardize the success of the project?
There are several PMs who rush to a decision or conclusion when a change in scope is requested without fully evaluating the true nature of the request and if it can truly benefit or not a project and its outcome.
By asking at least 3 Why questions (and more if need be), you will not only place yourself in a better position to assess the request but it will also give your client that reassurance that you are interested in more than simply execution.
It is a well known fact that one of the common questions in the PMP exam is the question of what should a PM do when a scope change is being requested. Remember - the most no-no answer is to simply say no.
A good PM should always assess the impact first of the request and the "3 Whys" gives you that good start.
Wednesday, September 15, 2010
The Lion, The Witch and the Project Manager (How to Manage Scope Creep)
The Lion - the stakeholders who roar the most and try to add scope without willing to add resources or bend to new schedules. They hope that since they are the supposed Kings of the Jungle - the only thing they need to do is roar loud enough and whatever wish they have will come true. They sometimes also go by the names of sponsors or key stakeholders.
The Witch - the stakeholders who brew several potions or stories to get you to support the scope addition and with her magical spellcasting, she tries to have you understand that what she wants is truly as natural as breathing and that to not support it is foolishness. She also uses her craft to convince you that the natural addition should not result in any schedule or cost changes. They sometimes go by the names end-users or business partners.
The Project Manager - the lone knight who has to protect the project and the team from the Lion and the Witch and what is the secret weapon you say? The Sword of Truth.
As a project manager, we all know that adding scope cannot have a zero effect on the other constraints, you can minimize them but zero impact is rare, most notably impact to schedule and costs. By stating the truth, the Lions can be silenced and the Witches can be bound.
Question the benefit vs costs of adding the request to scope. Ensure all stakeholders are aware of the impact of the addition and ensure that if the addition is agreed upon - that the decision was not made because the Lion roared nor because the Witch spellcasted but with full clarity powered by the Project Manager's truth.
The Witch - the stakeholders who brew several potions or stories to get you to support the scope addition and with her magical spellcasting, she tries to have you understand that what she wants is truly as natural as breathing and that to not support it is foolishness. She also uses her craft to convince you that the natural addition should not result in any schedule or cost changes. They sometimes go by the names end-users or business partners.
The Project Manager - the lone knight who has to protect the project and the team from the Lion and the Witch and what is the secret weapon you say? The Sword of Truth.
As a project manager, we all know that adding scope cannot have a zero effect on the other constraints, you can minimize them but zero impact is rare, most notably impact to schedule and costs. By stating the truth, the Lions can be silenced and the Witches can be bound.
Question the benefit vs costs of adding the request to scope. Ensure all stakeholders are aware of the impact of the addition and ensure that if the addition is agreed upon - that the decision was not made because the Lion roared nor because the Witch spellcasted but with full clarity powered by the Project Manager's truth.
Tuesday, September 14, 2010
And My Knees Still Shake...
Today is another workshop day and this time for project requirements that require the participation of several global representatives from different regions.
I have participated in several of these in my lifetime. I coordinated several of these and I led several of these types of workshops as well and today was the simplest one I will participate in in the past 3 years - I only need to welcome the team, give them the vision of the end result, tell them why this project is important to the company, my team, and me and yet - my knees still shook prior to the talk - the same knees that shook during my first ever public talk. This time though - there is a difference. I knew it would happen and I knew how to control it.
Unknown to my team, I was actually preparing for the 30 minutes of talk for a few days now - forming the structure in my head, deciding what I needed to say and what I need to accomplish. I probably played the whole thing in my head for several hours already- each time tweaking - each time enhancing - I made sure I knew what my message should be, how to impress that message to the audience I knew would be there and ensure they leave knowing how important the project is and more importantly, how important they are in ensuring its success.
That is my mission - get them not just on board the boat - but rowing - rowing like no man has rowed before - rowing with a determination to reach the destination I need us to reach with ferocity and perseverance.
I need them to be partners, not spectators. I need them to be fully engaged, not a temporal being. I need them to know that without them, this project will not succeed. I need them to know that they are the team that will see this to the end - and that we will succeed together or fail as one.
I know that during this project, as the rest I led, problems will pop up, conflicts will happen but after today - they all know that we are all responsible for each other, for the project and for the company.
My knees shake no more...
I have participated in several of these in my lifetime. I coordinated several of these and I led several of these types of workshops as well and today was the simplest one I will participate in in the past 3 years - I only need to welcome the team, give them the vision of the end result, tell them why this project is important to the company, my team, and me and yet - my knees still shook prior to the talk - the same knees that shook during my first ever public talk. This time though - there is a difference. I knew it would happen and I knew how to control it.
Unknown to my team, I was actually preparing for the 30 minutes of talk for a few days now - forming the structure in my head, deciding what I needed to say and what I need to accomplish. I probably played the whole thing in my head for several hours already- each time tweaking - each time enhancing - I made sure I knew what my message should be, how to impress that message to the audience I knew would be there and ensure they leave knowing how important the project is and more importantly, how important they are in ensuring its success.
That is my mission - get them not just on board the boat - but rowing - rowing like no man has rowed before - rowing with a determination to reach the destination I need us to reach with ferocity and perseverance.
I need them to be partners, not spectators. I need them to be fully engaged, not a temporal being. I need them to know that without them, this project will not succeed. I need them to know that they are the team that will see this to the end - and that we will succeed together or fail as one.
I know that during this project, as the rest I led, problems will pop up, conflicts will happen but after today - they all know that we are all responsible for each other, for the project and for the company.
My knees shake no more...
Monday, September 13, 2010
Estimating Project Costs based on One-liner Scope Statements
A lot of project managers typically encounter situations wherein they are asked to give a high level estimate of cost and schedule for certain projects during the initiation process - much too early to have the detailed requirements that most PMs would need to give an accurate estimate. Some companies go through this exercise to plan for next year's budget.
In my experience, these numbers are typically used for planning purposes or initial feasibility assessments and the following formula has shown great success in this exercise so far for the software development projects that I lead.
1. Base project costs which include labor (direct and indirect), hardware costs(whether purchased or leased), software licenses, separated by capitalizable costs and expensed costs which may differ based on your company policy +
2. Risk Costs (which is the amount required to recover the project and only for those risks with a 25-50% probability of happening that is identified as risks that are still recoverable - anything more than that is not a risk - it is an issue!). This risks reduce/increase as the project develops. The total of 1 and 2 is then multiplied by
3. A factor as contingency (which is dependent on how much you know of the project at the point of estimation although I typically use the following: 30 - 40% for one-liner scope statements and more if less is known and 20-30% for more developed requirements). This contingency reduces as the project develops. The new total is then multiplied by
4. A factor for management contingency and the factor that typically works for me is 10%
Some things to remember:
1. Labor rates may vary but you can use a blend rate for estimation purposes
2. Labor rates may increase/decrease over the time of the project so blend with this in mind
3. Ongoing Support and Maintenance Costs considerations including depreciation for the capitalizable items
In my experience, these numbers are typically used for planning purposes or initial feasibility assessments and the following formula has shown great success in this exercise so far for the software development projects that I lead.
1. Base project costs which include labor (direct and indirect), hardware costs(whether purchased or leased), software licenses, separated by capitalizable costs and expensed costs which may differ based on your company policy +
2. Risk Costs (which is the amount required to recover the project and only for those risks with a 25-50% probability of happening that is identified as risks that are still recoverable - anything more than that is not a risk - it is an issue!). This risks reduce/increase as the project develops. The total of 1 and 2 is then multiplied by
3. A factor as contingency (which is dependent on how much you know of the project at the point of estimation although I typically use the following: 30 - 40% for one-liner scope statements and more if less is known and 20-30% for more developed requirements). This contingency reduces as the project develops. The new total is then multiplied by
4. A factor for management contingency and the factor that typically works for me is 10%
Some things to remember:
1. Labor rates may vary but you can use a blend rate for estimation purposes
2. Labor rates may increase/decrease over the time of the project so blend with this in mind
3. Ongoing Support and Maintenance Costs considerations including depreciation for the capitalizable items
Sunday, September 12, 2010
KNOW your team
As a project manager, I would argue that KNOWing your team is one of the most important thing you should do, especially if you are a program or portfolio manager who will have several projects running at the same time with different stakeholders and the only consistent, binding link you have with all these projects is your team.
How do you know your team and how do you use the knowledge? I typically ensure that I have or can get the following for each of my team members:
1) Basic Information - name, experience, expertise, skills, education - all your general resume-level information. This is his "what was and what is" information.
2) Career Goals - and based not just on "where do you think you are in 5 years" type of questions. A person may be an expert today at a certain skill but is dying to get out it and hates doing the same thing again. This is his "what is the future he wants to see" and can it be in your team.
3) Work Preferences - is he the type of person who prefers to work alone or in a team setting. I have seen individuals who excel when doing some tasks all by themselves. Don't discount them immediately out of your team if you know he has a fit in your team.
4) Culture Fit - will he fit with the "culture" of the overall team, including yours
5) Leadership Potential - regardless of what role he might play in your team, although this comes more in handy when you are a program or portfolio manager obviously. This also is an important input in your "9-box" analysis of your team which is anothe topic in itself
6) Current Rate and perceived self-value growth rate
7) Unique traits and situations - for example - does he have any pet peeves that may affect his work?
Knowing the above for each of your team members and knowing your project - you can now do your "mission impossible" team selection and formation ensuring that each role is critical and that each player playing the role will complement the rest of the team.
How do you know your team and how do you use the knowledge? I typically ensure that I have or can get the following for each of my team members:
1) Basic Information - name, experience, expertise, skills, education - all your general resume-level information. This is his "what was and what is" information.
2) Career Goals - and based not just on "where do you think you are in 5 years" type of questions. A person may be an expert today at a certain skill but is dying to get out it and hates doing the same thing again. This is his "what is the future he wants to see" and can it be in your team.
3) Work Preferences - is he the type of person who prefers to work alone or in a team setting. I have seen individuals who excel when doing some tasks all by themselves. Don't discount them immediately out of your team if you know he has a fit in your team.
4) Culture Fit - will he fit with the "culture" of the overall team, including yours
5) Leadership Potential - regardless of what role he might play in your team, although this comes more in handy when you are a program or portfolio manager obviously. This also is an important input in your "9-box" analysis of your team which is anothe topic in itself
6) Current Rate and perceived self-value growth rate
7) Unique traits and situations - for example - does he have any pet peeves that may affect his work?
Knowing the above for each of your team members and knowing your project - you can now do your "mission impossible" team selection and formation ensuring that each role is critical and that each player playing the role will complement the rest of the team.
Saturday, September 11, 2010
I did everything the PMBOK says and yet my project was still a failure. What went wrong?
First and foremost, it is a major - MAJOR - mistake if you think that the PMBOK is THE one and only project management bible that will solve every problem in every situation. Even PMI has a section in its book that says “Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances”.
Second, if you did everything the PMBOK says - chances are you don’t really know what you are doing. The PMBOK is very helpful in providing the industry with tools and best practices that you may and can use to help you in managing your project BUT you have to use your experience, knowledge of the project and sensibility to know which tools would be the most appropriate to use for a particular job. Imagine that you are a carpenter and you have a truckload of tools - would you use all or even most of them - say to put up a drywall? Of course not. Same with the PMBOK.
What can help make your project a success then?
1. Know as much as possible about what you and your team need to deliver.
2. Be extremely familiar with the environment you will be working in and what assets and resources are available to do the project
3. KNOW who should be on your team and we are not talking here about simply knowing their names and roles. You should know them sufficiently enough to know how to lead and manage them to success
4. KNOW yourself, your capacity, your experience and what is required of you as a leader and manager to deliver your objectives with your team
5 Understand the tools and know which tools you need and how to use them properly to help in executing the project.
Ultimately, it is not the PMBOK that determines the success of a project but the project manager.
“PMI”, the PMI logo, “PMP”, “PMBOK” are registered marks of Project Management Institute, Inc. Excerpt from PMBOK above copyrighted 2008, Project Management Institute, Inc.
Second, if you did everything the PMBOK says - chances are you don’t really know what you are doing. The PMBOK is very helpful in providing the industry with tools and best practices that you may and can use to help you in managing your project BUT you have to use your experience, knowledge of the project and sensibility to know which tools would be the most appropriate to use for a particular job. Imagine that you are a carpenter and you have a truckload of tools - would you use all or even most of them - say to put up a drywall? Of course not. Same with the PMBOK.
What can help make your project a success then?
1. Know as much as possible about what you and your team need to deliver.
2. Be extremely familiar with the environment you will be working in and what assets and resources are available to do the project
3. KNOW who should be on your team and we are not talking here about simply knowing their names and roles. You should know them sufficiently enough to know how to lead and manage them to success
4. KNOW yourself, your capacity, your experience and what is required of you as a leader and manager to deliver your objectives with your team
5 Understand the tools and know which tools you need and how to use them properly to help in executing the project.
Ultimately, it is not the PMBOK that determines the success of a project but the project manager.
“PMI”, the PMI logo, “PMP”, “PMBOK” are registered marks of Project Management Institute, Inc. Excerpt from PMBOK above copyrighted 2008, Project Management Institute, Inc.
Friday, September 10, 2010
The Great Differentiator
I was asked today by one of my team members the following question - "what makes a great project manager?" Is it his ability to consistently deliver projects on time, on budget, in scope, with quality and with full user satisfaction?
I said "All those qualities make a project manager but not a great one".
A lot of project managers can claim all those in all his projects and I would argue that if the KPIs for a project manager are simply doing all these, he has but achieved the basic expectation of a project manager. Every project manager, or those who claim to be one, must strive to AT LEAST do all these.
The great differentiator in my opinion between the good project manager and the great project manager lies in HOW he executes his projects to achieve his objectives - his leadership and people skills.
A project manager can deliver a project on time, on budget but he did so through intimidation, fear or extreme politics. A project manager manager can deliver his projects on time and on budget but he failed to nurture and sustain productive relationships within and outside of his team in the process. He could consistenly deliver his projects on time, on budget and yet at the same time - consistently breed distrust and disloyalty by claiming all the glory to the dismay of his team.
At the end of the day - what makes a great project manager? It is the one who can consistently deliver his hard deliverables through excellent leadership and people management skills.
I said "All those qualities make a project manager but not a great one".
A lot of project managers can claim all those in all his projects and I would argue that if the KPIs for a project manager are simply doing all these, he has but achieved the basic expectation of a project manager. Every project manager, or those who claim to be one, must strive to AT LEAST do all these.
The great differentiator in my opinion between the good project manager and the great project manager lies in HOW he executes his projects to achieve his objectives - his leadership and people skills.
A project manager can deliver a project on time, on budget but he did so through intimidation, fear or extreme politics. A project manager manager can deliver his projects on time and on budget but he failed to nurture and sustain productive relationships within and outside of his team in the process. He could consistenly deliver his projects on time, on budget and yet at the same time - consistently breed distrust and disloyalty by claiming all the glory to the dismay of his team.
At the end of the day - what makes a great project manager? It is the one who can consistently deliver his hard deliverables through excellent leadership and people management skills.
Thursday, September 9, 2010
Start Digging!
I finally decided to find the time to extend my daily grind and start a project management blog.
Everyone says that I can't seem to stop talking and living project management so I thought I would give them an additional source of inspiration (or pain depending what boat you are on on this topic) by also writing about it.
Just to give you a short blurb about me and then lets have a contest later to see how you think I actually look like (relax - the prize is not a dvd of me talking project management!) - I have been living in the planet called project management for more than 10 years now - years before the acronym PMI even became popular in my native country and even before I even heard of MS Project. You might be saying - how old is this guy? Remember those 5 1/4" floppy disks - I actually used them to boot my PC to program in BASIC!
I have managed projects on a country level, a region level and on a global level - and maybe if anyone needs someone to manage a project outside the global I would also volunteer for that. I am passionate about creating and seeing my creations work its wonders.
For me - project management is not work - it is a way of life! I would argue that everything you do daily can be patterned around project management...and in this blog - I will show you how it revolves around my daily life.
Time to start digging!
Everyone says that I can't seem to stop talking and living project management so I thought I would give them an additional source of inspiration (or pain depending what boat you are on on this topic) by also writing about it.
Just to give you a short blurb about me and then lets have a contest later to see how you think I actually look like (relax - the prize is not a dvd of me talking project management!) - I have been living in the planet called project management for more than 10 years now - years before the acronym PMI even became popular in my native country and even before I even heard of MS Project. You might be saying - how old is this guy? Remember those 5 1/4" floppy disks - I actually used them to boot my PC to program in BASIC!
I have managed projects on a country level, a region level and on a global level - and maybe if anyone needs someone to manage a project outside the global I would also volunteer for that. I am passionate about creating and seeing my creations work its wonders.
For me - project management is not work - it is a way of life! I would argue that everything you do daily can be patterned around project management...and in this blog - I will show you how it revolves around my daily life.
Time to start digging!
Subscribe to:
Posts (Atom)
Posts
