Showing posts with label Communications. Show all posts
Showing posts with label Communications. 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.
Thursday, April 7, 2011
Article: What is Scope Creep?
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/
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/
Tuesday, April 7, 2009
2009 Results of the Top 10 Obstacles to Project Success
Here are the new rankings from the "Top 10 Obstacles to Project Success" survey. We received appreciation for our ongoing efforts, and confirmation from participants that our list captured the essence of the obstacles to project success faced by Project Managers, Team Leaders, Program Managers, and Senior Management. Here are the results listed in order of frequency;
#1: Changes to project scope (scope creep) Same as last year!
#2: Insufficient time to complete the project (up from #8 last year!)
#3: Resources are inadequate (excluding funding)
#4: Inadequate project testing
#5: Critical project tasks are delivered late
#6: Key team members lack adequate authority
#7: Insufficient project funding
#8: Critical requirements are unspecified or missing (down from #2 last year!)
#9: Key team members lack critical skills
#10: Project sponsor is unavailable to approve strategic decisions (down from #3 last year!)
We've had some interesting changes between the 2008 and 2009 surveys. Obstacles such as the Challenging Schedule, Invisible Requirements, and most notably, The Disappearing Sponsor have moved in their ranking.
What do you think causes these obstacles? What are some potential solutions?
Upcoming blogs; We have interesting information to share about how the obstacles were ranked by individuals from different regions of the world, early detection symptoms, and mitigation strategies.
We want to hear from you feel free to comment!
#1: Changes to project scope (scope creep) Same as last year!
#2: Insufficient time to complete the project (up from #8 last year!)
#3: Resources are inadequate (excluding funding)
#4: Inadequate project testing
#5: Critical project tasks are delivered late
#6: Key team members lack adequate authority
#7: Insufficient project funding
#8: Critical requirements are unspecified or missing (down from #2 last year!)
#9: Key team members lack critical skills
#10: Project sponsor is unavailable to approve strategic decisions (down from #3 last year!)
We've had some interesting changes between the 2008 and 2009 surveys. Obstacles such as the Challenging Schedule, Invisible Requirements, and most notably, The Disappearing Sponsor have moved in their ranking.
What do you think causes these obstacles? What are some potential solutions?
Upcoming blogs; We have interesting information to share about how the obstacles were ranked by individuals from different regions of the world, early detection symptoms, and mitigation strategies.
We want to hear from you feel free to comment!
Wednesday, April 1, 2009
The Top 10 Obstacles to Project Success!
Its time again to gauge the obstacles to project success! Last year over 1,000 project managers from all over the world participated in a MüTō sponsored survey and answered a question we posed, "What obstacles stand in the way to project success?"
MüTō compiled the answers and identified ten frequent themes. We labeled these, the "Top Ten Obstacles to Project Success":
#10. A skill set challenged team
#9. Delegated responsibility unrelated to authority
#8. Challenging schedule
#7. Minimal or non-existent testing
#6. Tardy delivery of project tasks
#5. The resource challenge
#4. The finance challenge
#3. A disappearing sponsor
#2. Invisible requirements
#1. Spontaneous requirements
This year we thought we would take a different tack. Based on your experience, we would like you to rank the frequency of each of the "Top Ten Obstacles to Project Success." Click the link below to take our three minute on-line survey.
After April 1st we'll report the findings to you. We will invite you to join us in our ongoing discussions as we examine each obstacle separately. We'll be discussing the reality of how each obstacle manifests, talk about the early detection of their symptoms, as well as discuss potential mitigation.
The emails will be supported by a blog-spot for you to post your own impressions. The best thing about this is...ITS ALL FREE!
We appreciate your time, and look forward to your participation!
Just click on the following link at start your survey!
http://www.surveymonkey.com/s.aspx?sm=EivPdlXieQPtydoU8o2tjg_3d_3d
MüTō compiled the answers and identified ten frequent themes. We labeled these, the "Top Ten Obstacles to Project Success":
#10. A skill set challenged team
#9. Delegated responsibility unrelated to authority
#8. Challenging schedule
#7. Minimal or non-existent testing
#6. Tardy delivery of project tasks
#5. The resource challenge
#4. The finance challenge
#3. A disappearing sponsor
#2. Invisible requirements
#1. Spontaneous requirements
This year we thought we would take a different tack. Based on your experience, we would like you to rank the frequency of each of the "Top Ten Obstacles to Project Success." Click the link below to take our three minute on-line survey.
After April 1st we'll report the findings to you. We will invite you to join us in our ongoing discussions as we examine each obstacle separately. We'll be discussing the reality of how each obstacle manifests, talk about the early detection of their symptoms, as well as discuss potential mitigation.
The emails will be supported by a blog-spot for you to post your own impressions. The best thing about this is...ITS ALL FREE!
We appreciate your time, and look forward to your participation!
Just click on the following link at start your survey!
http://www.surveymonkey.com/s.aspx?sm=EivPdlXieQPtydoU8o2tjg_3d_3d
Sunday, November 23, 2008
On Business Reasons
“What obstacles do project managers face to successful completion of an Information Technology project?”
IT Consultant
Calling it an Information Technology project is one of the biggest obstacles because it focuses people on the solution before the problem or opportunity has been fully explored. Projects should be about delivering change which, when implemented, provides organisational benefits. So rather than, say, a 'Customer Relationship Management System' project, how about an
'Improved Responsiveness to Customers' project!
MüTō Observation:
In essence ALL projects have some greater purpose. I.T. tends to be a part of it, but NOT all of it. Even in an e-Company!
IT Consultant
Calling it an Information Technology project is one of the biggest obstacles because it focuses people on the solution before the problem or opportunity has been fully explored. Projects should be about delivering change which, when implemented, provides organisational benefits. So rather than, say, a 'Customer Relationship Management System' project, how about an
'Improved Responsiveness to Customers' project!
MüTō Observation:
In essence ALL projects have some greater purpose. I.T. tends to be a part of it, but NOT all of it. Even in an e-Company!
Sunday, November 16, 2008
On The Life-Cycle
“What obstacles do project managers face to successful completion of an Information Technology project?”
Manager of Operations Date Center; Communication Company
The projects that success does not have, in its great majority had not had in its phase of elaboration the development and correct preparation. Before any beginning, all the factors must be considered:
- Time
- Cost
- Resources
In the computer science industry, generally it has two types of boardings comumente used in the management of projects. The boardings of “the traditional” type identify a sequência of steps to be completed. These boardings contrast with the known boarding as agile development of software, where the project is seen as a set of small tasks, instead of a complete process. The objective of this boarding is to reduce to the possible minimum overhead. This boarding is sufficient controversa, especially in very complex projects. Exactly thus, it has conquered adepts in increasing numbers.
In the last few decades, they had in general emerged a series of boardings in the industry. Amongst these boardings if it detaches the boarding of the PMBOK, that if has become a standard of fact in diverse industries
In the traditional boarding, we distinguish five groups from processes in the development of a
project:
Initiation
Planning
Execution
Monitoramento and Controle
Closing
Nor all the projects go to follow all these periods of training, since projects can be locked up before its conclusion. Perhaps some projects do not have planning or monitoramento. Some projects will pass for periods of training 2, 3 and 4 multiple times.
The project or enterprise above aims at the satisfaction of a necessity or chance, defined in the text as initial phase in which many involved areas and/or people exist. In general always it exists more than a solution or alternatives to take care of to the same necessities. The used technique to define the final solution passes for the development of extreme alternatives. The first one of low cost that takes care of the minimum necessities to be functional. Second it tries to take care of most of the requirements of the diverse involved areas in the target that results in a project with bigger and very little competitive cost. From both the alternatives are developed an intermediate solution between the same ones, that it takes care of to a good part of the requirements with a competitive cost.
Some sectors use variations of these periods of training. For example, in the civil construction, the projects typically progress of periods of training as Daily pay-planning for Conceptual Design, schematical Design, Design of development, construction of drawings (or contract documents), and administration of construction. Although the names differ from industry for industry, the real periods of training typically follow the common steps to the resolution of problems (they problem solving): to define the problem, to balance options, to choose a way, implementation and evaluation.
The management of projects tries to acquire control on three 0 variable:
time
cost
target
Some literatures define as four 0 variable, being quality the fourth 0 variable, however the quality is one of the main components of the target. These 0 variable can be given by external or internal customers. (S) the value (you are) of the remaining 0 variable is/is in charge of the manager of the project, ideally based in solids estimate techniques. The final results must be waked up in a negotiation process enter the management of the project and the customer. Generally, the values in time terms, cost, quality and target are defined by contract.
To keep the control on the project of the beginning to the end, a manager of projects uses several techniques, amongst which if they detach:
Planning of project
Analysis of aggregate value
Management of project risks
Cronograma
Improvement of process
MüTō Observation:
There is no doubt that the life-cycle decided for a project is tantamount to its success.
What we find is that Project Managers must have specific skills, that pre-date an understanding of process. The basic capability to Communicate, the ability to Motivate others, and the ability to hold project members accountable.
These skills are fundamental to project success. Without them...any process will fail. Guaranteed.
Manager of Operations Date Center; Communication Company
The projects that success does not have, in its great majority had not had in its phase of elaboration the development and correct preparation. Before any beginning, all the factors must be considered:
- Time
- Cost
- Resources
In the computer science industry, generally it has two types of boardings comumente used in the management of projects. The boardings of “the traditional” type identify a sequência of steps to be completed. These boardings contrast with the known boarding as agile development of software, where the project is seen as a set of small tasks, instead of a complete process. The objective of this boarding is to reduce to the possible minimum overhead. This boarding is sufficient controversa, especially in very complex projects. Exactly thus, it has conquered adepts in increasing numbers.
In the last few decades, they had in general emerged a series of boardings in the industry. Amongst these boardings if it detaches the boarding of the PMBOK, that if has become a standard of fact in diverse industries
In the traditional boarding, we distinguish five groups from processes in the development of a
project:
Initiation
Planning
Execution
Monitoramento and Controle
Closing
Nor all the projects go to follow all these periods of training, since projects can be locked up before its conclusion. Perhaps some projects do not have planning or monitoramento. Some projects will pass for periods of training 2, 3 and 4 multiple times.
The project or enterprise above aims at the satisfaction of a necessity or chance, defined in the text as initial phase in which many involved areas and/or people exist. In general always it exists more than a solution or alternatives to take care of to the same necessities. The used technique to define the final solution passes for the development of extreme alternatives. The first one of low cost that takes care of the minimum necessities to be functional. Second it tries to take care of most of the requirements of the diverse involved areas in the target that results in a project with bigger and very little competitive cost. From both the alternatives are developed an intermediate solution between the same ones, that it takes care of to a good part of the requirements with a competitive cost.
Some sectors use variations of these periods of training. For example, in the civil construction, the projects typically progress of periods of training as Daily pay-planning for Conceptual Design, schematical Design, Design of development, construction of drawings (or contract documents), and administration of construction. Although the names differ from industry for industry, the real periods of training typically follow the common steps to the resolution of problems (they problem solving): to define the problem, to balance options, to choose a way, implementation and evaluation.
The management of projects tries to acquire control on three 0 variable:
time
cost
target
Some literatures define as four 0 variable, being quality the fourth 0 variable, however the quality is one of the main components of the target. These 0 variable can be given by external or internal customers. (S) the value (you are) of the remaining 0 variable is/is in charge of the manager of the project, ideally based in solids estimate techniques. The final results must be waked up in a negotiation process enter the management of the project and the customer. Generally, the values in time terms, cost, quality and target are defined by contract.
To keep the control on the project of the beginning to the end, a manager of projects uses several techniques, amongst which if they detach:
Planning of project
Analysis of aggregate value
Management of project risks
Cronograma
Improvement of process
MüTō Observation:
There is no doubt that the life-cycle decided for a project is tantamount to its success.
What we find is that Project Managers must have specific skills, that pre-date an understanding of process. The basic capability to Communicate, the ability to Motivate others, and the ability to hold project members accountable.
These skills are fundamental to project success. Without them...any process will fail. Guaranteed.
Sunday, November 9, 2008
The Project Itself...
“What obstacles do project managers face to successful completion of an Information Technology project?”
IT executive: International commercial firm
The project itself.......
MüTō Observation:
This is funny. But not far from where most Project Managers stand. I have heard a lot along these lines whenever Project Managers say things like "This project is screwed up." or "We don't have enough money." or, "The sponsors are crazy." etc.
Its funny to them, until they realize its their responsibility to communicate, motivate, and hold the project parties accountable for their specific areas of success.
IT executive: International commercial firm
The project itself.......
MüTō Observation:
This is funny. But not far from where most Project Managers stand. I have heard a lot along these lines whenever Project Managers say things like "This project is screwed up." or "We don't have enough money." or, "The sponsors are crazy." etc.
Its funny to them, until they realize its their responsibility to communicate, motivate, and hold the project parties accountable for their specific areas of success.
Sunday, November 2, 2008
Requirements Requirements Requirements
“What obstacles do project managers face to successful completion of an Information Technology project?”
Director, Information Technology (IT)
Requirements, Requirements, Requirements,.... budget
tendancy of business to use "Hope as a management strategy"
MüTō Observation:
Project Managers throughout experience the same obstacles. Not only do we all experience the same obstacles, but they are all mitigate able, on every project, every time, and it isn’t the certification, or the process that will ensure it. (although those are EXTREMELY helpful.)
When they tell me about Requirements, and Budget, I tell them its the PM's responsibility to make certain that requirements are clearly communicated, and mutually understood by BOTH the sponsors, the beneficiaries, and the suppliers.
When they talk to me about budget, I make sure the PM's understand that the budget is THEIRS, and that the prjoect requires that they be truthful to it. The suppliers MUST be held accountable to its estimation, and its use. And the Sponsor must be available to review requirements to extend it! (albeit, if the PM's doing his job, this would already be handled.)
Director, Information Technology (IT)
Requirements, Requirements, Requirements,.... budget
tendancy of business to use "Hope as a management strategy"
MüTō Observation:
Project Managers throughout experience the same obstacles. Not only do we all experience the same obstacles, but they are all mitigate able, on every project, every time, and it isn’t the certification, or the process that will ensure it. (although those are EXTREMELY helpful.)
When they tell me about Requirements, and Budget, I tell them its the PM's responsibility to make certain that requirements are clearly communicated, and mutually understood by BOTH the sponsors, the beneficiaries, and the suppliers.
When they talk to me about budget, I make sure the PM's understand that the budget is THEIRS, and that the prjoect requires that they be truthful to it. The suppliers MUST be held accountable to its estimation, and its use. And the Sponsor must be available to review requirements to extend it! (albeit, if the PM's doing his job, this would already be handled.)
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.
Sunday, October 5, 2008
On Project Completion
“What obstacles do project managers face to successful completion of an Information Technology project?”
Project Management and IT Professional
Successful completion for me does not mean a project was delivered on time or on budget it means that the projects goals were accomplished. A successful project is one that produced deliverables which met or exceeded the stated business goals.
For me the biggest obstacle to a successful project is the misstatement, understatement or misunderstanding of goals. I have worked at many companies and completed many projects and most of the stated business goals dont always seem to make it to the Project Manager. Often times the goal presented to the PM is "implement this" instead of achieve goals 1,2,3 through the implementation "of this" which goes to explain what the business is really trying to achieve. I am often forced to re-interview the stakeholders to be able to produce a statement of goals that is shared with and periodically reviewed with the project team.
Other common obstacles:
Scope creep – this is fairly common and is caused primarily by a poor understanding of the goals which causes scope statements to be incomplete. Typically discovery of this is not made until much later and almost always results in more work. The addition of business goals on the other hand is also creep but schedules can and should be renegotiated to accommodate.
Resource allocations – Ask any PM is she or he has ever had too many technical resources on a project. Chances are no. Often times other factors are used to set target delivery dates when the actual primary driver should be the availability of resources.
Schedules – There is never enough time or resources to meet project schedules and this often results in poor work. Quality and innovation always suffer the most from this. If there is barely enough time to check in the often buggy code, how innovative do you think it will be.
There are many other obstacles of course but do feel free to contact me to discuss.
MüTō Observation:
For example, the basic inability of a project manager to communicate clearly can lead to 'scope-creep', and a misunderstanding of the requirements, or worse yet, the loss of understanding of what the 'danged business objective is!'
Its tantamount that a Project Manager understand the business objective; At least in its native form. It may be a big leap between the understanding, and their particular project, but at least they would know WHY the project is important, and then they can communicate that importance to the rest of the team. Without that understanding the entire team would be working in a vacuum, and could never be properly motivated.
Sunday, September 28, 2008
On Project Stake Holders
“What obstacles do project managers face to successful completion of an Information Technology project?”
Manager MIS; National Social Group
I observed and experienced following factors based on my experience as PM in IT and non IT industry:
- Lake of interest of second tier stake holders
- Lake of understanding the importance of project by some major project stake holders
- Environmental motivation factor for project team
- Limited vision of Project Manager
- Without involving influential stake holders into the project proceedings
- Try to implement the project as a whole instead of module
MüTō Observation:
These obstacles can be mitigated through the basic ability of a Project Manager to communicate clearly.
For example, how can a 'second tier stake-holder' be considered important, if they have a lack of interest in the project? A PM can hold them accountable. If a Major Stakeholder lacks the understanding of the importance of a project, then it is the PM's responsibility to make certain they clearly understand it.
A PM's ability to motivate their project team is tantamount to the project's success. I agree. Their vision, and ability to communicate it holds a project together, and gets the project team to the next level of focus, and energy.
Sunday, September 21, 2008
On Clarity
“What obstacles do project managers face to successful completion of an Information Technology project?”
Information Technology and Services Professional: Healthcare
“1. Management not setting a clear goal and openly, honestly communicating this goal to all, and providing their support to the project.
2. Poor communication at various levels throughout the project, including not properly identifying all the stakeholders.
3. Unrealistic expectations and finger pointing.
4. Addressing each project as though it was the first one ever undertaken; each project is seen as an "exception to the rules", therefore no consistent process can be put into place.
5. Personal accountability hard to find.
6. People not being held responsible for their actions/inactions.
7. Conflicting priorities and an unreasonable rush to start coding
8. Staff not honestly invested in the project management process -- including management. Often lip-service is given, but off stage everyone tries to bypass project management.
9. Overbearing project management processes that are more about the process (religion) of project management rather than focused on steps that add (or reasonably could add) value.
10. Projects begun as a management directive instead of agreed-upon as a project that is of value (resulting in little user buy-in and often result in treating symptoms instead of fundamental problems). Any ROI is done while the project is underway, and is totally subjective and based on management directive rather an an objective analysis/review.”
MüTō Observation:
I completely agree with your 10 points! Further, I'll add that they can be referenced into three fundamental abilities of a project manager.
The short of it is;
Imagine the Project Manager that could communicate clearly, and guide a sponsor to open/honest conversation on the projects' goals, attaining their complete support. This same PM could completely understand the various parties involved to be certain they are a complete list of suppliers, stakeholders, and beneficiaries. Expectations would be normalized, and finger-pointing would be eliminated. Process would become secondary to the project's success, but intently adhered to!
Now let’s make that PM able to motivate the project team to such a point that the project is their primary objective! (Not just their day job.) When priorities threaten to conflict, a team-mate would think 'first' of the project; Opening the door to accountability.
This same PM might also be able to hold parties accountable for their specific tasks/milestones/responsibilities.
Information Technology and Services Professional: Healthcare
“1. Management not setting a clear goal and openly, honestly communicating this goal to all, and providing their support to the project.
2. Poor communication at various levels throughout the project, including not properly identifying all the stakeholders.
3. Unrealistic expectations and finger pointing.
4. Addressing each project as though it was the first one ever undertaken; each project is seen as an "exception to the rules", therefore no consistent process can be put into place.
5. Personal accountability hard to find.
6. People not being held responsible for their actions/inactions.
7. Conflicting priorities and an unreasonable rush to start coding
8. Staff not honestly invested in the project management process -- including management. Often lip-service is given, but off stage everyone tries to bypass project management.
9. Overbearing project management processes that are more about the process (religion) of project management rather than focused on steps that add (or reasonably could add) value.
10. Projects begun as a management directive instead of agreed-upon as a project that is of value (resulting in little user buy-in and often result in treating symptoms instead of fundamental problems). Any ROI is done while the project is underway, and is totally subjective and based on management directive rather an an objective analysis/review.”
MüTō Observation:
I completely agree with your 10 points! Further, I'll add that they can be referenced into three fundamental abilities of a project manager.
The short of it is;
Imagine the Project Manager that could communicate clearly, and guide a sponsor to open/honest conversation on the projects' goals, attaining their complete support. This same PM could completely understand the various parties involved to be certain they are a complete list of suppliers, stakeholders, and beneficiaries. Expectations would be normalized, and finger-pointing would be eliminated. Process would become secondary to the project's success, but intently adhered to!
Now let’s make that PM able to motivate the project team to such a point that the project is their primary objective! (Not just their day job.) When priorities threaten to conflict, a team-mate would think 'first' of the project; Opening the door to accountability.
This same PM might also be able to hold parties accountable for their specific tasks/milestones/responsibilities.
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 Corporate Politics
“What obstacles do project managers face to successful completion of an Information Technology project?”
Director - IT Operations: Retail firm
The first obstacle and largest is Buy-In. You need to have an Executive Sponsor who is active and passionate about the project. Adequate Resources (Budget, Headcount, etc) would be the second. These are often under estimated to make a project look better, but in the end limit the projects ablility to be successful.
Ensure plenty of time for testing and ensure you lock down scope.
MüTō Observation:
What you point out has a touch of corporate 'politics' and the native ability of the Project Manager; Communication/Motivation/Accountability. Going up against that ornery Sponsor who’s sacrificing their own project's success for a little momentary 'boost to their ego', could be suicidal, for the PM, if not done right.
Imagine the PM that could point out to that 'short-sighted' Sponsor, that to fail at the project would be worse than to approach it correctly. Neat trick, eh? That's a PM's ability to communicate, and his ability to motivate, that comes to bear there.
On testing, and scope lock down. YES!!! It takes an involved PM to be proactive in this way. Ensuring Testing, and Scope lock down will seem like 'too much over-work' for that ornery 'Sponsor'; again, requiring the stellar communicative/motivational skills of the PM.
Director - IT Operations: Retail firm
The first obstacle and largest is Buy-In. You need to have an Executive Sponsor who is active and passionate about the project. Adequate Resources (Budget, Headcount, etc) would be the second. These are often under estimated to make a project look better, but in the end limit the projects ablility to be successful.
Ensure plenty of time for testing and ensure you lock down scope.
MüTō Observation:
What you point out has a touch of corporate 'politics' and the native ability of the Project Manager; Communication/Motivation/Accountability. Going up against that ornery Sponsor who’s sacrificing their own project's success for a little momentary 'boost to their ego', could be suicidal, for the PM, if not done right.
Imagine the PM that could point out to that 'short-sighted' Sponsor, that to fail at the project would be worse than to approach it correctly. Neat trick, eh? That's a PM's ability to communicate, and his ability to motivate, that comes to bear there.
On testing, and scope lock down. YES!!! It takes an involved PM to be proactive in this way. Ensuring Testing, and Scope lock down will seem like 'too much over-work' for that ornery 'Sponsor'; again, requiring the stellar communicative/motivational skills of the PM.
On Change
“What obstacles do project managers face to successful completion of an Information Technology project?”
CIO: Government Department
I would stress that change management is a huge obstacle. So often technology is looked at like the magic bullet that will radically improve your process... but too often we just automate bad processes - and it isn't until we have started programming that the business unit start to dream up ideas to add features to the process - then everyone wants to add things... then the changes come - then the scope creep - then the delays, the costs, and the frustration...
It could all have been settled in the business case, charter, and scoping stages - but it rarely is... and granted, it is hard to see the building from the blueprints... so it's change management I think we really need to get a handle on - so everyone knows the impact of adding after the big "freeze"
MüTō Observation:
I firmly believe that 'Change is a Constant', and that means that a project manager must embrace it and prepare for it.
The PM is to be held entirely accountable to see that the change is mutually understood (by sponsors/beneficiaries, and suppliers), and to see the change through!
CIO: Government Department
I would stress that change management is a huge obstacle. So often technology is looked at like the magic bullet that will radically improve your process... but too often we just automate bad processes - and it isn't until we have started programming that the business unit start to dream up ideas to add features to the process - then everyone wants to add things... then the changes come - then the scope creep - then the delays, the costs, and the frustration...
It could all have been settled in the business case, charter, and scoping stages - but it rarely is... and granted, it is hard to see the building from the blueprints... so it's change management I think we really need to get a handle on - so everyone knows the impact of adding after the big "freeze"
MüTō Observation:
I firmly believe that 'Change is a Constant', and that means that a project manager must embrace it and prepare for it.
The PM is to be held entirely accountable to see that the change is mutually understood (by sponsors/beneficiaries, and suppliers), and to see the change through!
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 Project Control and a PM's Authority
“What obstacles do project managers face to successful completion of an Information Technology project?”
Independent Financial Services Professional
“In order to ensure the Project Manager's control over a project, he/she should, at a minimum, have the authority to own one side of the project management triangle i.e. if any two are altered, for example, Scope and Resources, the PM has the liberty to adjust the third (delivery timeline) accordingly or if the delivery timeline is shortened, the PM should have the authority to reduce scope or add more resources to the project.
It is essential that there is a clear understanding and communication of which side is owned by the PM in order to ensure success.
This may seem very basic, but more often than not, projects fail because businesses make changes to one or two sides of the triangle, and expect the others to remain unchanged.
In order to track and measure these changes, a robust change management process needs to be in place backed by an effective communication methodology which ensures that all stakeholders are aware of the change, its impact, associated risks and have signed it off.
So, in order to ensure the success of a project, the PM should, at the outset clearly establish and communicate which part of the triangle he or she owns.”
MüTō Observation:
To a project manager, the topic that you framed can be summarized as "Lack of authority."
I completely agree with your summation, to paraphrase "clearly communicate authority" as being a responsibility of the PM. However, we are rarely in a situation where the sponsor/beneficiary or suppliers actually understand the Resource/Scope/Timeline relationship.
So in reality, it is pragmatic to presume that the state of the project in its infancy is that these elements are not understood, and should therefore be an educational topic up front in the project, And then a topic for reinforcement throughout the project.
This places the PM in a state of 'authority' that is stronger than any expressed authority, as it is an acceptable perception of leadership.
Just imagine, the Project Manager that clearly communicates authority throughout the project, and has an expressed managed level of comfort over "the triangle".
That's only the beginning.
Independent Financial Services Professional
“In order to ensure the Project Manager's control over a project, he/she should, at a minimum, have the authority to own one side of the project management triangle i.e. if any two are altered, for example, Scope and Resources, the PM has the liberty to adjust the third (delivery timeline) accordingly or if the delivery timeline is shortened, the PM should have the authority to reduce scope or add more resources to the project.
It is essential that there is a clear understanding and communication of which side is owned by the PM in order to ensure success.
This may seem very basic, but more often than not, projects fail because businesses make changes to one or two sides of the triangle, and expect the others to remain unchanged.
In order to track and measure these changes, a robust change management process needs to be in place backed by an effective communication methodology which ensures that all stakeholders are aware of the change, its impact, associated risks and have signed it off.
So, in order to ensure the success of a project, the PM should, at the outset clearly establish and communicate which part of the triangle he or she owns.”
MüTō Observation:
To a project manager, the topic that you framed can be summarized as "Lack of authority."
I completely agree with your summation, to paraphrase "clearly communicate authority" as being a responsibility of the PM. However, we are rarely in a situation where the sponsor/beneficiary or suppliers actually understand the Resource/Scope/Timeline relationship.
So in reality, it is pragmatic to presume that the state of the project in its infancy is that these elements are not understood, and should therefore be an educational topic up front in the project, And then a topic for reinforcement throughout the project.
This places the PM in a state of 'authority' that is stronger than any expressed authority, as it is an acceptable perception of leadership.
Just imagine, the Project Manager that clearly communicates authority throughout the project, and has an expressed managed level of comfort over "the triangle".
That's only the beginning.
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.
Governance and Decision Makers
“What obstacles do project managers face to successful completion of an Information Technology project?”
MBA
“- IT Strategy/Business Strategy Integration (Governance)
- Resource Management (dynamic workforce variation mitigation)
- Availability to Project Charter Signees (decision maker involvement)
- Vendors”
MüTō Observation:
Lets boil these obstacles to three elements; The PM's ability to clearly communicate, his/her ability to properly motivate team members to an active goal, and his/her ability to hold parties accountable for their tasks.
And that doesn't mean someone giving them the authority.
Very few organizations I have been through (most of the fortune 500) have effective project governance for more than I would call one management season (before rotation occurs at senior levels)...so that one season is just the environment. It impacts the PM when they need more money...so, at a lower level sponsors can be present. That requires more PM communicate-ability.
Resource management is a bear (especially with outsourcing/offshoring so prevalent.) The dynamic nature of today's workforce literally means your assets go away. So what keeps them at a firm? What if a PM could supercharge his team into believing in the project? (I say that's the PM's responsibility.) It would certainly reduce the dynamics...but it would require a heck of a lot of work from the PM.
Availability of the Charter signers is not too problematic...people sign stuff almost naturally in the corporate world, BUT...holding them accountable! ha! That's a different story. That's the involvement part, eh? Can a PM get an answer/decision from the 'decision maker'? That's a problem...one that requires the PM to hold the chain above him/her accountable.
And finally, Vendors....I assume you are talking about them holding to milestones, or over-promising capabilities, etc. That's the trick. Holding them accountable is also a bear, but something a PM can do a lot easier than holding internal resources accountable. ("You don't deliver, we don't pay.") Still, Soprano tactics result in someone being bumped-off...not a good tactic when you need to complete a project. So, How does a PM hold a Vendor accountable?
That's a fundamental skill, and one I teach. It has to do with having a Plan "B" that everyone agrees on.
MBA
“- IT Strategy/Business Strategy Integration (Governance)
- Resource Management (dynamic workforce variation mitigation)
- Availability to Project Charter Signees (decision maker involvement)
- Vendors”
MüTō Observation:
Lets boil these obstacles to three elements; The PM's ability to clearly communicate, his/her ability to properly motivate team members to an active goal, and his/her ability to hold parties accountable for their tasks.
And that doesn't mean someone giving them the authority.
Very few organizations I have been through (most of the fortune 500) have effective project governance for more than I would call one management season (before rotation occurs at senior levels)...so that one season is just the environment. It impacts the PM when they need more money...so, at a lower level sponsors can be present. That requires more PM communicate-ability.
Resource management is a bear (especially with outsourcing/offshoring so prevalent.) The dynamic nature of today's workforce literally means your assets go away. So what keeps them at a firm? What if a PM could supercharge his team into believing in the project? (I say that's the PM's responsibility.) It would certainly reduce the dynamics...but it would require a heck of a lot of work from the PM.
Availability of the Charter signers is not too problematic...people sign stuff almost naturally in the corporate world, BUT...holding them accountable! ha! That's a different story. That's the involvement part, eh? Can a PM get an answer/decision from the 'decision maker'? That's a problem...one that requires the PM to hold the chain above him/her accountable.
And finally, Vendors....I assume you are talking about them holding to milestones, or over-promising capabilities, etc. That's the trick. Holding them accountable is also a bear, but something a PM can do a lot easier than holding internal resources accountable. ("You don't deliver, we don't pay.") Still, Soprano tactics result in someone being bumped-off...not a good tactic when you need to complete a project. So, How does a PM hold a Vendor accountable?
That's a fundamental skill, and one I teach. It has to do with having a Plan "B" that everyone agrees on.
Subscribe to:
Posts (Atom)
