Showing posts with label Process. Show all posts
Showing posts with label Process. Show all posts
Monday, August 8, 2011
Article: When One Assumes
* Critical Requirements Unspecified or Missing is ranked fourth as a cause of project failure globally according to the 2010 Global Survey, Top 10 Obstacles to Project Success. This article is meant as a precursor to more in depth information regarding the; causes, impacts, early detection, and mitigation of this complex and often misdiagnosed project obstacle.
Saturday, March 12, 2011
2010 RESULTS OF THE TOP 10 OBSTACLES TO PROJECT SUCCESS
As promised here are the results of our survey on the Top 10 Obstacles to Project Success in 2010. More than 1,700 respondents took the survey and represented 22 industries, 26 countries and 47 types of projects. Here are the global rankings;
1. Changes to Project Scope (scope creep) [Third year in a row!]
2. Resources are inadequate (excluding funding)
3. Insufficient time to complete the project
4. Critical requirements are unspecified or missing [Up four from last year!]
5. Inadequate project testing
6. Critical project tasks are delivered late
7. Key team members lack adequate authority
8. The Project Sponsor is unavailable to approve strategic decisions
9. Insufficient project funding [Down two from last year!]
10. Key team members lack critical skills
Read the first article on our findings here;
http://www.mutoperformancecorp.com/2010SurveyResults.htm
Individual obstacles, trends in ranking, regional and industry based differences are just a few of the subjects we will cover in future articles.
Feel free to comment!
Thanks!
The MüTō Team
1. Changes to Project Scope (scope creep) [Third year in a row!]
2. Resources are inadequate (excluding funding)
3. Insufficient time to complete the project
4. Critical requirements are unspecified or missing [Up four from last year!]
5. Inadequate project testing
6. Critical project tasks are delivered late
7. Key team members lack adequate authority
8. The Project Sponsor is unavailable to approve strategic decisions
9. Insufficient project funding [Down two from last year!]
10. Key team members lack critical skills
Read the first article on our findings here;
http://www.mutoperformancecorp.com/2010SurveyResults.htm
Individual obstacles, trends in ranking, regional and industry based differences are just a few of the subjects we will cover in future articles.
Feel free to comment!
Thanks!
The MüTō Team
Tuesday, June 3, 2008
On Process
“What obstacles do project managers face to successful completion of an Information Technology project?”
Project Manager: Large financial firm
The answer to this question depends on the environment in which project management is deployed. Traditional waterfall SDLC and ceremonial PMLC in a mature organization will provide predictable results, challenges and solutions.
Organizations in transition with mis matched SDLC and PMLC will have a different set of challenges in managing the triple constraints due to mis matched toolsets.
Organizations in the latest trend of Agile project management with matching SDLC will find the greatest challenges in the area of ensuring proper communication.
To summarize, the question is broad and needs to provide more background in order to get a specific answer.
MüTō Observation:
My point is that the biggest obstacles a PM faces are personal; Their inability to clearly communicate, their disregard for their teams motivational foundations, and their lack of understanding of how to hold parties accountable to their tasks combine as the evolutionary 'muck' from whence all other obstacles are born.
Project Manager: Large financial firm
The answer to this question depends on the environment in which project management is deployed. Traditional waterfall SDLC and ceremonial PMLC in a mature organization will provide predictable results, challenges and solutions.
Organizations in transition with mis matched SDLC and PMLC will have a different set of challenges in managing the triple constraints due to mis matched toolsets.
Organizations in the latest trend of Agile project management with matching SDLC will find the greatest challenges in the area of ensuring proper communication.
To summarize, the question is broad and needs to provide more background in order to get a specific answer.
MüTō Observation:
My point is that the biggest obstacles a PM faces are personal; Their inability to clearly communicate, their disregard for their teams motivational foundations, and their lack of understanding of how to hold parties accountable to their tasks combine as the evolutionary 'muck' from whence all other obstacles are born.
On Project Definition
“What obstacles do project managers face to successful completion of an Information Technology project?”
Information Technology and Services Consultant
“It is vital to define project boundaries.
Use a series of Product Descriptions to refine requirements & get Signed Agreements ... to include: Textual Description & Code ... Component Parts & Codes ... Performance Criteria ... Quality Criteria & Methods ... Responsibility for both Build & Test.
THE AGREEMENT SHOULD ENCOMPASS...
The Size, Scope & Deliverables ... How Big? ... What Features? How Many? ...By When? ... How Much? ... Quality Defined?
DOCUMENT ALL ASSUMPTIONS ... AND AGREE ON CHANGE CONTROL PROCEDURES. "
MüTō Observation:
These are among the top obstacles listed by Project Managers. I completely agree that defining the boundaries of the project, clarity in requirements, and solution (all unequivocally understood by ALL parties, equally) is tantamount to project success.
This requires a certain basic skill in the PM, called the ability to Communicate.
Just imagine the project manager that can bring parties together, and clearly negotiate the facilitate discussions so that at the end, requirements are clear to everyone, equally. Then helping to prompt the technologists/suppliers in such a way as to facilitate their expression of a solution in such a way that the sponsors/beneficiaries TRULLY UNDERSTAND what they are getting, and what it will do for them. Not to mention, the clear communication of all authority/responsibility/task accountability.
Then lets imagine the PM that can energize their team to a point that ALL issues/risks are promptly raised (instead of cya'd), and all focus is on driving the project to successful completion, not just because its a job.
Then, lets imagine that the PM can exert authority, and be on everyone's priority stack (placed on top) even when they are not around. ;)
Or, how about a PM that could do just 10% of that....
The entire responsibility for getting what you recommended done effectively, sits squarely on the PM. No-one on a project is more perfectly positioned than the PM to provide that facilitation.
But that's only step one eh?
On Process Etc.
“What obstacles do project managers face to successful completion of an Information Technology project?”
Information Technology and Services Professional
Every project is unique, and even the same project in two different companies is also unique. However, from personal experience, these are the biggest gotchas....
1. Ready, Fire, Aim! - Spend time BEFORE you begin. Amass all of the information, scope, expectations, deliverables, etc. If your project is successfull, it will expand. Leave room to grow at the end without having to start all over from square one.
2. Expect resistance. As the PM, you have had potentially years to understand the change(s) coming. Thus, you are comfortable, whereas the end-users are being force fed very quickly. Where possible, have end-user driven meetings answer questions, provide updates, and anticipate how much help you will need come launch day
3. Change orders - These are ineviteable, but don't let change become the project. Group them into categories (e.g., critical to launch, SP1 Priority, or simply nice to have) and move on.
4. For large or complex projects, I liked to hold "Proof of Concept" testing where possible and let the end-users be the testers; and audit or risk management as the lead. Why? A) Proves it can fly; b) Gives the end end-users a chance to fly it too; c) Get's Audit or Risk Management involved and hands-on; d) Provides an early look into ease of use or where training may need to focus (just be clear on concept versus final product to address misconception; e) Let's someone else test and document so you can keep the project moving; f) allows you to observe instead of drive; and g) Hope for failure somewhere. If the first "pre-test" is perfect, something is definately wrong!
5. Budget busters - "measure twice, cut once". Upgrades always have gotchas.......plan for them in contingency funds up front. Anything totally new is either very simple and straight-forward; or your worst nightmare come true when it now won't run on the old routers you forgot to consider.
6. Build Disaster Recovery into the project, DO NOT wait to come back to it later on. We are a 99.9% uptime world today, if you think otherwise...it's been nice knowing you
7. Launch quietly with your best. Unless there is some compelling need to do so, launch quietly, in parallell, and in person with your best group, team, region, etc. Full scale launch on day one is full scale disaster guaranteed.
8. What are your customers doing while you wait for your IT group to arrive to fix some problem? Plan for customer issues. Everyone seems to think of every issue that can go wrong, but never considers what your customer is doing while your employees are running around half insane! Don't surprise your customers above all else. Ensure all your managers are present that day and their only job is to greet customers. Ensure your Senior Management are in synch too so that everyone is focused. So many fail to see this one coming, but then wonder where the customers are going!
9. Launch - Designate a back offce team to be the temporary point of contact/help desk. This "crisis team" is specific to the launch only....leaving your Help Desk free to deal with the usual problems too...not just the launch issues. Begin transitioning support back to the Help Desk as the implementation issues ease in the days ahead. Amazingly simple and VERY effective if done correctly!”
MüTō Observation:
When I read the list you provided I noted that for the most part they typically assume a certain higher level of competence in PM's than other challenges I have been reading. For example; In order to 'hold Proof of Concept testing' or 'launch quietly' a PM would have to be able to hold his suppliers/testers accountable to support his aims, AND support a given corporate process. This will require skills in the PM that likely only come with experience, or specific training.
Ever meet a PM that follows the 'book' to the letter, without pause, or change, but fails anyway when faced with that dynamic project? Or perhaps a PM that fails to charge up his team, then wonders why they won't provide answers, support, when needed? Or maybe that PM that says "But they should be doing it...its their job." not realizing that people do not work because they have jobs, they have their priorities, and the PM has failed to make his, their utmost concern?
Any of the PM's I labeled above would not have a chance at tackling the issues you listed. So you are definitely talking about advanced topics.
Information Technology and Services Professional
Every project is unique, and even the same project in two different companies is also unique. However, from personal experience, these are the biggest gotchas....
1. Ready, Fire, Aim! - Spend time BEFORE you begin. Amass all of the information, scope, expectations, deliverables, etc. If your project is successfull, it will expand. Leave room to grow at the end without having to start all over from square one.
2. Expect resistance. As the PM, you have had potentially years to understand the change(s) coming. Thus, you are comfortable, whereas the end-users are being force fed very quickly. Where possible, have end-user driven meetings answer questions, provide updates, and anticipate how much help you will need come launch day
3. Change orders - These are ineviteable, but don't let change become the project. Group them into categories (e.g., critical to launch, SP1 Priority, or simply nice to have) and move on.
4. For large or complex projects, I liked to hold "Proof of Concept" testing where possible and let the end-users be the testers; and audit or risk management as the lead. Why? A) Proves it can fly; b) Gives the end end-users a chance to fly it too; c) Get's Audit or Risk Management involved and hands-on; d) Provides an early look into ease of use or where training may need to focus (just be clear on concept versus final product to address misconception; e) Let's someone else test and document so you can keep the project moving; f) allows you to observe instead of drive; and g) Hope for failure somewhere. If the first "pre-test" is perfect, something is definately wrong!
5. Budget busters - "measure twice, cut once". Upgrades always have gotchas.......plan for them in contingency funds up front. Anything totally new is either very simple and straight-forward; or your worst nightmare come true when it now won't run on the old routers you forgot to consider.
6. Build Disaster Recovery into the project, DO NOT wait to come back to it later on. We are a 99.9% uptime world today, if you think otherwise...it's been nice knowing you
7. Launch quietly with your best. Unless there is some compelling need to do so, launch quietly, in parallell, and in person with your best group, team, region, etc. Full scale launch on day one is full scale disaster guaranteed.
8. What are your customers doing while you wait for your IT group to arrive to fix some problem? Plan for customer issues. Everyone seems to think of every issue that can go wrong, but never considers what your customer is doing while your employees are running around half insane! Don't surprise your customers above all else. Ensure all your managers are present that day and their only job is to greet customers. Ensure your Senior Management are in synch too so that everyone is focused. So many fail to see this one coming, but then wonder where the customers are going!
9. Launch - Designate a back offce team to be the temporary point of contact/help desk. This "crisis team" is specific to the launch only....leaving your Help Desk free to deal with the usual problems too...not just the launch issues. Begin transitioning support back to the Help Desk as the implementation issues ease in the days ahead. Amazingly simple and VERY effective if done correctly!”
MüTō Observation:
When I read the list you provided I noted that for the most part they typically assume a certain higher level of competence in PM's than other challenges I have been reading. For example; In order to 'hold Proof of Concept testing' or 'launch quietly' a PM would have to be able to hold his suppliers/testers accountable to support his aims, AND support a given corporate process. This will require skills in the PM that likely only come with experience, or specific training.
Ever meet a PM that follows the 'book' to the letter, without pause, or change, but fails anyway when faced with that dynamic project? Or perhaps a PM that fails to charge up his team, then wonders why they won't provide answers, support, when needed? Or maybe that PM that says "But they should be doing it...its their job." not realizing that people do not work because they have jobs, they have their priorities, and the PM has failed to make his, their utmost concern?
Any of the PM's I labeled above would not have a chance at tackling the issues you listed. So you are definitely talking about advanced topics.
Subscribe to:
Posts (Atom)
