Changes in Project Scope (Scope Creep) is the current leading cause of project failure globally according to the 2010 Global Survey, Top 10 Obstacles to Project Success. This article is meant as a high level overview of this complex and often misdiagnosed project obstacle.
To read the full article go to http://www.mutoperformancecorp.com/2010SurveyResults.htm
We welcome your comments. Join our blog at http://top10obstacles.blogspot.com/
Showing posts with label ROI Scope Creep. Show all posts
Showing posts with label ROI Scope Creep. Show all posts
Thursday, April 7, 2011
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
Thursday, April 16, 2009
There's Nothing Creepy About Scope Creep!
When 83% of our survey participants responded that scope creep reared its ugly head on almost every one of their projects, we immediately said, "here we go again!" Scope creep is the scapegoat for most of our troubles with projects. Our analysis showed that there are two types of changes to the scope of a project; those that are legitimate, and those that are illegitimate.
Each has its own impact, causes, early detection symptoms, and solutions. Suffice to say, that illegitimate scope creep must be stopped, and legitimate scope creep must be managed effectively otherwise, the obstacle will manifest! Legitimate scope creep cannot possibly damage your project, so let's be careful about blaming it for our project's demise.
We may not like where the blame winds up sticking.
For the FULL ARTICLE, CLICK HERE!
For a complete listing of MüTō Articles, CLICK HERE!
Each has its own impact, causes, early detection symptoms, and solutions. Suffice to say, that illegitimate scope creep must be stopped, and legitimate scope creep must be managed effectively otherwise, the obstacle will manifest! Legitimate scope creep cannot possibly damage your project, so let's be careful about blaming it for our project's demise.
We may not like where the blame winds up sticking.
For the FULL ARTICLE, CLICK HERE!
For a complete listing of MüTō Articles, CLICK HERE!
Sunday, October 26, 2008
On Requirements and Estimates
“What obstacles do project managers face to successful completion of an Information Technology project?”
Technology Management; Technology Infrastructure
I agree that most project has some unique obstabcles, all project that i have worked with or been aware of have had 3 common problems
1. Incomplete requirements or lack of visibility to full requirements
2. Poor estimation of effort
3. Scope creep
MüTō Observation:
These are three very common problems. I often find that a project manager's inability to communicate clearly, encourage proper motivation, and hold others accountable is at the core of all three of the problems you listed.
Technology Management; Technology Infrastructure
I agree that most project has some unique obstabcles, all project that i have worked with or been aware of have had 3 common problems
1. Incomplete requirements or lack of visibility to full requirements
2. Poor estimation of effort
3. Scope creep
MüTō Observation:
These are three very common problems. I often find that a project manager's inability to communicate clearly, encourage proper motivation, and hold others accountable is at the core of all three of the problems you listed.
Sunday, October 19, 2008
On Clients and Scope Creep
“What obstacles do project managers face to successful completion of an Information Technology project?”
Technology strategy leader: private equity fund
The biggest obstacles I encounter in implementing technology projects are
1) client commitment to participating in the project definition process and
2) change in scope along the way, which is always caused by #1.
These obstacles can be avoided through frank and up-front discussion with the client of worst case scenarios and establishment of firm milestones that track a project progress.
If the client isn't participating (skips or cancels meetings or progress reviews, refusals to make decisions to guide the project), it's time to let the client know that they are causing the project to slip and make it clear what they need to do to get it back on track.
None of this is easy -- it takes lots an lots of open, honest communication to make a project a success.
MüTō Observation:
The ability to Communicate clearly to everyone on a project, the ability to Motivate a proejct team to hold the project MOST important, and the ability of a project manager to hold all the parties of a project accountable, are tantamount to a project manager's successful completion of a project.
Technology strategy leader: private equity fund
The biggest obstacles I encounter in implementing technology projects are
1) client commitment to participating in the project definition process and
2) change in scope along the way, which is always caused by #1.
These obstacles can be avoided through frank and up-front discussion with the client of worst case scenarios and establishment of firm milestones that track a project progress.
If the client isn't participating (skips or cancels meetings or progress reviews, refusals to make decisions to guide the project), it's time to let the client know that they are causing the project to slip and make it clear what they need to do to get it back on track.
None of this is easy -- it takes lots an lots of open, honest communication to make a project a success.
MüTō Observation:
The ability to Communicate clearly to everyone on a project, the ability to Motivate a proejct team to hold the project MOST important, and the ability of a project manager to hold all the parties of a project accountable, are tantamount to a project manager's successful completion of a project.
Tuesday, June 3, 2008
On Scope Creep (again)
“What obstacles do project managers face to successful completion of an Information Technology project?”
Certified IT Professional: Healthcare group
“As others have notes in their answers, the biggest issue I've encountered as a Project Manager of a project to develop a dynamic mapping extension for a commercial software product was "scope creep." Without a detail Functional Specification developed with user input/client input at the beginning of the project you're constantly faced with requests to change widgets, colors, adding features & functionality. It takes a lot of time up front for the Functional Spec but it saves a lot of time, frustration, and confrontational communications as the project moves forward.
Be sure you understand the deployment environment -- e.g., SQL 2000 or SQL 2005, Internet Explorer/FireFox/Mac, etc. so the application is developed to work in the appropriate environments.
Also, good change control with tools such as Visual SourceSafe is highly recommended.
Finally, engage users, both sophisticated and non-sophisticated in product design.
MüTō Observation:
That veritable virus "scope creep"! I can't agree with you more. If its not fully controlled, a Project Manager will lose all direction when Scope Creep rears its ugly head.
If a project manager has an ability to communicate clearly, these obstacles become manageable.
If they can properly motivate their team, then issues about the environment are brought to their attention, and risks are raised earlier. If the project manager can hold his team-mates, suppliers, sponsors, and beneficiaries accountable, then issues surrounding requirements (scope creep), environments, technology, delivery of milestones, funding, etc... become less risky to the project's success.
Certified IT Professional: Healthcare group
“As others have notes in their answers, the biggest issue I've encountered as a Project Manager of a project to develop a dynamic mapping extension for a commercial software product was "scope creep." Without a detail Functional Specification developed with user input/client input at the beginning of the project you're constantly faced with requests to change widgets, colors, adding features & functionality. It takes a lot of time up front for the Functional Spec but it saves a lot of time, frustration, and confrontational communications as the project moves forward.
Be sure you understand the deployment environment -- e.g., SQL 2000 or SQL 2005, Internet Explorer/FireFox/Mac, etc. so the application is developed to work in the appropriate environments.
Also, good change control with tools such as Visual SourceSafe is highly recommended.
Finally, engage users, both sophisticated and non-sophisticated in product design.
MüTō Observation:
That veritable virus "scope creep"! I can't agree with you more. If its not fully controlled, a Project Manager will lose all direction when Scope Creep rears its ugly head.
If a project manager has an ability to communicate clearly, these obstacles become manageable.
If they can properly motivate their team, then issues about the environment are brought to their attention, and risks are raised earlier. If the project manager can hold his team-mates, suppliers, sponsors, and beneficiaries accountable, then issues surrounding requirements (scope creep), environments, technology, delivery of milestones, funding, etc... become less risky to the project's success.
On Management Support, and Project Scope
“What obstacles do project managers face to successful completion of an Information Technology project?”
IT Manager: Financial Services Firm
“Some ideas that come to my mind:
- Lack of support from Management;
- Unclear project scope or too much flexibility if asked to add new features or redesigning previously defined ones;
- Wrong casting of business team members (if needed);
- Project plan not entirely formalized and understood by Management on points such as resource allocation, scope and project timmings;
- Use of new technology or business process changes not taken in consideration during the planning phase.”
MüTō Observation:
In most of the projects we deal with the PM's inability to communicate effectively, others with the PM's inability to hold parties on the project accountable to their responsibility, the remainder has to do with the PM's disregard for the team's motivational factors.
Imagine if the PM could establish a sense of accountability in Management? Would support come from them easier, or harder? Could the PM exert influence on proper resourcing/skill-set training? Some PM's struggle with fighting that battle...but that's a personal choice, right?
As a facilitator a properly skilled PM could easily promote a clear understanding between sponsors/beneficiaries/and suppliers on both the requirements of a project, and the proposed solution. The ability to communicate, and facilitate is tantamount...seemingly difficult with certain people, but not impossible.
IT Manager: Financial Services Firm
“Some ideas that come to my mind:
- Lack of support from Management;
- Unclear project scope or too much flexibility if asked to add new features or redesigning previously defined ones;
- Wrong casting of business team members (if needed);
- Project plan not entirely formalized and understood by Management on points such as resource allocation, scope and project timmings;
- Use of new technology or business process changes not taken in consideration during the planning phase.”
MüTō Observation:
In most of the projects we deal with the PM's inability to communicate effectively, others with the PM's inability to hold parties on the project accountable to their responsibility, the remainder has to do with the PM's disregard for the team's motivational factors.
Imagine if the PM could establish a sense of accountability in Management? Would support come from them easier, or harder? Could the PM exert influence on proper resourcing/skill-set training? Some PM's struggle with fighting that battle...but that's a personal choice, right?
As a facilitator a properly skilled PM could easily promote a clear understanding between sponsors/beneficiaries/and suppliers on both the requirements of a project, and the proposed solution. The ability to communicate, and facilitate is tantamount...seemingly difficult with certain people, but not impossible.
On Communications
“What obstacles do project managers face to successful completion of an Information Technology project?”
PMP: Technology Project Manager
“The largest obstacle seems to be proper communication. Frequently the technicians will assume things that the business people have no idea about, and the business people will assume things the technicians have no idea about. A good example is a recent project that I was brought into to solve a communication problem. The business people and tech had met, and determined that data feeds could be accomplished between the company and the vendor. The business people assumed the standard feed would work. The vendor assumed they would get the feed formated the way the rest of their clients sent the data. After several weeks of trying to determine why the feeds were failing, the collective they discovered it was a formatting issue in the feeds. This sort of thing was what I was brought into the project to resolve. Techs and Business people do not speak the same language, and assumptions are made on both sides. This leads to requirements that are not documented or incorrectly documented. This in turn cascades into variance in estimates, and impacts both schedule and budget.
Another item is that the charter is either not done or is not correctly linked back to core business goals. The charter should spell out why a project is being done. The project should tie back to departmental and organizational mission statements. Documents withing the project book should go into expected return on investment, potential risks and OPPORTUNITIES, stakeholder analysis (why is it good for the manager of this group and such), so that when support wanes for a project the PM has all these tools ready to keep the project going. Part of the risk and opportunity plan should be a reaction to possibilities script. So if there is an opportunity to enhance the ROI of another project that might occur, there should be a plan on how to do that if it does. Planning to mitigate the risks is only half of risk management. By taking advantage of opportunities we can not only enhance the value of a project to the organization, but maintain support for a project.
A solid grasp of scope creep and change management is necessary for an IT project to succeed. It happens to us all. One minor change can be absorbed, maybe even 10. Unfortunately they pile up, and before you know it the pile of minor changes don't link back to requirements or the project mission. It is far better to implement change requests for all changes. If the change is minor, the impact should be minor, but it gives a PM some justification when they say "We'd like to put that request in the next version of the product."
Some things that get skipped sometimes are:
- A formal communications plan
- Formal stakeholder analysis
- Exploration of other solutions (I like Ishikawa diagrams and FMEA, but their are other tools)
Lessons learned. (either never done, or never reviewed to take advantage of them)
The other main issue I see is an undervaluing of the PM resource. Too many PMs operate without administrative support. That's OK if you're the only PM, but as a department has more projects running and more PMs it makes sense to get administrative assistants in for them. Simply on the basis that the assistant can do things for them, which in turn allows them to do more PM work.”
MüTō Observation:
Communications is a fundamental Project Management tool. Motivating a Team, and holding parties Accountable are the other two tools.
But, Communications is the BIG ONE. No-one but the PM sits in a seat on a project with the ability to SORT IT OUT.
PMP: Technology Project Manager
“The largest obstacle seems to be proper communication. Frequently the technicians will assume things that the business people have no idea about, and the business people will assume things the technicians have no idea about. A good example is a recent project that I was brought into to solve a communication problem. The business people and tech had met, and determined that data feeds could be accomplished between the company and the vendor. The business people assumed the standard feed would work. The vendor assumed they would get the feed formated the way the rest of their clients sent the data. After several weeks of trying to determine why the feeds were failing, the collective they discovered it was a formatting issue in the feeds. This sort of thing was what I was brought into the project to resolve. Techs and Business people do not speak the same language, and assumptions are made on both sides. This leads to requirements that are not documented or incorrectly documented. This in turn cascades into variance in estimates, and impacts both schedule and budget.
Another item is that the charter is either not done or is not correctly linked back to core business goals. The charter should spell out why a project is being done. The project should tie back to departmental and organizational mission statements. Documents withing the project book should go into expected return on investment, potential risks and OPPORTUNITIES, stakeholder analysis (why is it good for the manager of this group and such), so that when support wanes for a project the PM has all these tools ready to keep the project going. Part of the risk and opportunity plan should be a reaction to possibilities script. So if there is an opportunity to enhance the ROI of another project that might occur, there should be a plan on how to do that if it does. Planning to mitigate the risks is only half of risk management. By taking advantage of opportunities we can not only enhance the value of a project to the organization, but maintain support for a project.
A solid grasp of scope creep and change management is necessary for an IT project to succeed. It happens to us all. One minor change can be absorbed, maybe even 10. Unfortunately they pile up, and before you know it the pile of minor changes don't link back to requirements or the project mission. It is far better to implement change requests for all changes. If the change is minor, the impact should be minor, but it gives a PM some justification when they say "We'd like to put that request in the next version of the product."
Some things that get skipped sometimes are:
- A formal communications plan
- Formal stakeholder analysis
- Exploration of other solutions (I like Ishikawa diagrams and FMEA, but their are other tools)
Lessons learned. (either never done, or never reviewed to take advantage of them)
The other main issue I see is an undervaluing of the PM resource. Too many PMs operate without administrative support. That's OK if you're the only PM, but as a department has more projects running and more PMs it makes sense to get administrative assistants in for them. Simply on the basis that the assistant can do things for them, which in turn allows them to do more PM work.”
MüTō Observation:
Communications is a fundamental Project Management tool. Motivating a Team, and holding parties Accountable are the other two tools.
But, Communications is the BIG ONE. No-one but the PM sits in a seat on a project with the ability to SORT IT OUT.
Subscribe to:
Posts (Atom)
