In the everyday hustle and bustle of user communications and the desire to serve by managing the low hanging fruits as fast as possible, project management teams are most likely to miss out on a critical aspect of a project - is it really needed by the corporation?
Most of the projects I have seen are more responses to the short term pains of a few groups of people rather than an answer to an over-arching need of the company. Most of these pains are mere symptoms of the root problem rather than the problem itself and thus there are several project teams that deliver what we call "band-aid" solutions rather than long-term pain relief.
There are some questions that help determine where the project request is truly rooted on and what need does it truly answer and some of them appear below. In several cases, just asking the project sponsor a few of these questions can get people collaborating more across peers or having them re-think their original requests.
1. Priority -> How does this project tie-up to the corporate priorities(sometimes call the CEO agenda, the company mission,etc)?
2. Cost/Benefit - > What will the company gain if we do this project? Don't forget to ask as well what will the company lose if we don't do the project? The more specific the answer - the better. It is, for example, better if the sponsor can tie it to profit growth or profit loss or if the user can tie-it to a specific business process problem that the project will address.
3. Project interactions -> Does this project tie-up with any existing or planned projects that the company is already undertaking?
4. Resources -> To what extent will the company support the resource requirements of the project?
It would be an eye-opener if our executives realize how many projects failed (and costed the company money) because the questions above were not asked(or answered) early on.
Showing posts with label project planning. Show all posts
Showing posts with label project planning. Show all posts
Saturday, June 11, 2011
Saturday, January 29, 2011
Vision Creation is Easy
I see a lot of courses offering training on how to create vision but everyday I see a lot of people creating visions and I believe that the true test for a leader is not the ability to create a vision but to see them through.
I have seen successful leaders realize their visions and I have looked at some of the strategies they applied to make them members of the rare few. Here are some of my observations.
1) They look for big gaps that require a solution - if the problem is not big enough and impact of the solution not magnificent enough - the vision is not a vision but simply a glance.
2) They connect the vision to reality including planning out resources that will be needed to bridge the gaps. Without the connection to reality - the vision is not a vision but simply a dream.
3) They are persistent in seeing the vision through and does not allow obstacles to get in the way. Without persistence - the vision is not a vision but simply a hobby.
4) They are flexible on the approach. Although they are clear on the desired outcome - they realize that challenges will be present and they constantly re-evaluate if the path they are currently taking is still the right path to get them through. Without this constant check and flexibility - the vision is not a vision but simply a task.
If you cannot make your vision realizable and see them through - a leader is not a visionary but simply a manager.
I have seen successful leaders realize their visions and I have looked at some of the strategies they applied to make them members of the rare few. Here are some of my observations.
1) They look for big gaps that require a solution - if the problem is not big enough and impact of the solution not magnificent enough - the vision is not a vision but simply a glance.
2) They connect the vision to reality including planning out resources that will be needed to bridge the gaps. Without the connection to reality - the vision is not a vision but simply a dream.
3) They are persistent in seeing the vision through and does not allow obstacles to get in the way. Without persistence - the vision is not a vision but simply a hobby.
4) They are flexible on the approach. Although they are clear on the desired outcome - they realize that challenges will be present and they constantly re-evaluate if the path they are currently taking is still the right path to get them through. Without this constant check and flexibility - the vision is not a vision but simply a task.
If you cannot make your vision realizable and see them through - a leader is not a visionary but simply a manager.
Saturday, October 9, 2010
The Project Management Circus: Act 2 - The Lion Tamer (Project Sponsor Management)
The lights go out for a few second and there is a booming voice that announces Act 2.
A spotlight shines on the person coming into the cage and inside the cage were several lions.
The person has a whip on one hand a chair on the other and he has treats in his pocket. He has been here before and he knows the lions well - each one of them. He knows not only their names but their personalities as well. He knows what makes them tick. He knows he needs them to succeed. He knows they need him to control the chaos that can happen without him. He waves his hands to his spectators as if in victory even before the show begins.
The booming voice announces him as....The Project Manager.
Each project manager deals with this situation for every new project - facing the project sponsors and working with or through them to ensure project success. What does he need to succeed in this initiative?
1. Sufficient knowledge of who the sponsors are and where they belong in the hierarchy of the organization - the pack order.
2. True knowledge of what is their stake in the project - not just what they publicly say - but what their internal agenda is.
3. Knowledge of their comfort levels, risk tolerances and when thrown into a corner - which would they primarily protect if they can only choose one - scope, cost, schedule or quality?
4. Knowledge of their pain and pleasure points which may include what information does each one want to hear, when and how and what motivational triggers can be pulled if the project manager wants the sponsors to "jump through hoops'.
5. Understanding the defense mechanism of each one. When provoked - will Lion A run away and will Lion B attack? If the project manager knows who will go into the offensive as a defensive - he needs to make sure he knows how best to defend himself.
Balancing between sponsor motivation (the treats), punishment(the whip) and defense(the chair) is a key skill that each project manager should develop. It is so much better to know how to manage them that to find your head trapped between their jaws.
A spotlight shines on the person coming into the cage and inside the cage were several lions.
The person has a whip on one hand a chair on the other and he has treats in his pocket. He has been here before and he knows the lions well - each one of them. He knows not only their names but their personalities as well. He knows what makes them tick. He knows he needs them to succeed. He knows they need him to control the chaos that can happen without him. He waves his hands to his spectators as if in victory even before the show begins.
The booming voice announces him as....The Project Manager.
Each project manager deals with this situation for every new project - facing the project sponsors and working with or through them to ensure project success. What does he need to succeed in this initiative?
1. Sufficient knowledge of who the sponsors are and where they belong in the hierarchy of the organization - the pack order.
2. True knowledge of what is their stake in the project - not just what they publicly say - but what their internal agenda is.
3. Knowledge of their comfort levels, risk tolerances and when thrown into a corner - which would they primarily protect if they can only choose one - scope, cost, schedule or quality?
4. Knowledge of their pain and pleasure points which may include what information does each one want to hear, when and how and what motivational triggers can be pulled if the project manager wants the sponsors to "jump through hoops'.
5. Understanding the defense mechanism of each one. When provoked - will Lion A run away and will Lion B attack? If the project manager knows who will go into the offensive as a defensive - he needs to make sure he knows how best to defend himself.
Balancing between sponsor motivation (the treats), punishment(the whip) and defense(the chair) is a key skill that each project manager should develop. It is so much better to know how to manage them that to find your head trapped between their jaws.
Tuesday, October 5, 2010
The Project Management Circus: Act 1 - The Tightrope Walker
I have heard several people in my career say that project management is easy - just give someone a project, resources and a goal and all he has to do is create a plan and monitor it to completion.
This is similar to what I hear from my co-spectators when I see a circus.
Truly, Project Management can be like a circus - in more ways than one and the performers are the project managers.
Take the tightrope walker as an example. What does he need to do anyway? He only needs to walk from end to end - how difficult could that be? Let see...
A tightrope walker, like a project manager, to succeed in his endeavor, would need to
a)know first where is his starting point - including information about how high he is from the ground, is there a net below him, how strong is the post he will stand on before he begis the walk, what is the length of his balancing pole, how hot the spotlights can be, etc... - much like project initiation
b) know where his end point is and what is the definition of success (eg making it to the other side alive maybe in 5 minutes), what resources does he has to reach the other point (eg does he have a pole to hold on to and use as a balance), how many steps would he most likely need to take and how much can he trust his resources(eg his rope quality, his pole quality or the net quality if he falls). At the same time, he must know the pace he needs to take and how to take the steps - much like planning, contingency allocation and resourcing
c) know how to traverse the rope and keep his balance ensuring that he checks at each step whether he is on the right track or not. He must also know what to do when something goes wrong along the way(eg an ant is biting his armpit - sometimes called management pressure - or when his rope starts to shake because of a sudden wind gust - sometimes called sponsor wind) - much like project monitoring and control
d) know what to do when he gets to the end - if he gets to the end - including putting the pole down first (let go of resources), ensuring both his feet are really on the other end and raising his arms and waving to his adoring crowd - much like project closure and team celebrations.
Easy you say? Maybe...up until you are truly the one walking the rope.
This is similar to what I hear from my co-spectators when I see a circus.
Truly, Project Management can be like a circus - in more ways than one and the performers are the project managers.
Take the tightrope walker as an example. What does he need to do anyway? He only needs to walk from end to end - how difficult could that be? Let see...
A tightrope walker, like a project manager, to succeed in his endeavor, would need to
a)know first where is his starting point - including information about how high he is from the ground, is there a net below him, how strong is the post he will stand on before he begis the walk, what is the length of his balancing pole, how hot the spotlights can be, etc... - much like project initiation
b) know where his end point is and what is the definition of success (eg making it to the other side alive maybe in 5 minutes), what resources does he has to reach the other point (eg does he have a pole to hold on to and use as a balance), how many steps would he most likely need to take and how much can he trust his resources(eg his rope quality, his pole quality or the net quality if he falls). At the same time, he must know the pace he needs to take and how to take the steps - much like planning, contingency allocation and resourcing
c) know how to traverse the rope and keep his balance ensuring that he checks at each step whether he is on the right track or not. He must also know what to do when something goes wrong along the way(eg an ant is biting his armpit - sometimes called management pressure - or when his rope starts to shake because of a sudden wind gust - sometimes called sponsor wind) - much like project monitoring and control
d) know what to do when he gets to the end - if he gets to the end - including putting the pole down first (let go of resources), ensuring both his feet are really on the other end and raising his arms and waving to his adoring crowd - much like project closure and team celebrations.
Easy you say? Maybe...up until you are truly the one walking the rope.
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.
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
Subscribe to:
Posts (Atom)
Posts
