What is the most common problem you face regularly and how you can avoid it?
I wonder if we, as a community, will agree on the same thing?
I ask for some short answers (just in a few words) to share our experience.
-
4This is a thought-provoking question and is one that could benefit this community. I do want to point out that it does fit within the bounds of the What kind of questions should I not ask here? section of the FAQ. One suggestion is to edit your question to describe a particular problem you're facing. Other than that, I look forward to seeing the answers.– jmort253Commented Feb 22, 2012 at 21:00
-
Schedule, Scope, Quality. These are the 3 things you can adjust in a project. Quality should never be sacrificed (in terms of code quality). If you increase scope, schedule needs to be extended; the inverse is also true. It's a 0 sum game, and so scope change can be the only true answer. But, that begs the question - what are the reasons for scope creep for which there are great answers to that question below.– JodyCommented Mar 3, 2012 at 16:41
Add a comment
|
17 Answers
Uncontrolled scope creep - the project starts with the best of intentions. It is well defined and understood, but somewhere along the way, someone asks for an extra bit of functionality, or a new interface, or some additional management information. Sure, it's not in the original specification, but it is only a small change... But unfortunately it is one of many, and none has been through proper governance - so the impact on cost, risk, time, and quality have not been considered. The decision to include some of these minor changes may even be left to a junior technician, rather than being a senior management responsibility. Designs may change. Integration begins to get more complex. Cost rise, deadlines slip, and the benefits don't get delivered. All because someone kept on saying "Yes, sure, we can just slip one more minor change into the project."
How to avoid this? - Proper controls. Whether you are using traditional methods or more agile processes, make sure that the right person is making the right decisions, and for the right reasons. Consider deferring new features until release 2 (or 3 or 4). Make sure that the focus remains on what you set out to deliver - or make the change deliberately, consciously, and with all due diligence.
-
Very interesting. A small change in the original planification of the project can have a major impact. I would concentrate all the decisions making power in the hands of the project manager (one person only). It the project is too big, I would create tow different teams with one project manager each and with completely separated tasks. The tow projects managers can meet regularely to coordonate the global perspective. Commented Feb 26, 2012 at 23:06
Some good answers, but the most important one seems to be missing, the one that addresses al of the others - the main factor that causes projects to fail is weak project management.
Looking at all of the answers so far, all of them can and should have been addressed and controlled by the PM. Scope creep, change control, project kick-off, assumptions, requirements - ALL are the responsibility of the PM.
It's the PM's responsibility to be clear on all of these, and to make sure everyone's in agreement on them before the project starts, and to then monitor and adjust as the project proceeds.
answered Feb 23, 2012 at 15:54
-
2I like this answer, and would suggest that Trevor's final paragraph implies another cause of projects missing their goals: lack of communication. If the PM documents all that has been agreed, and continually reinforces the methods and strategies that are being adopted to shape and drive the project, the likelihood of success is multiplied many times over.– Iain9688Commented Feb 23, 2012 at 18:25
-
Some people have managerial abilities, some don't (even with business diplomas). Some planify easily, others with difficulty. The higher management must put the right person at the right place at the right moment. That seems obvious, but it is not, because human ressources are limeted most of the time. Commented Feb 26, 2012 at 23:16
-
I don't agree that blame can be placed in one place. Projects, businesses and culture/politics are large complex systems that create all sorts of outcomes. While a weak project manager can be the undoing of a great project, I have seem many a strong project managers given order from on high to "control" project aspects while "managing" all of their requests. The project manager's success is still tied to his team, environment and support. Commented Feb 28, 2012 at 2:26
-
Erin, true enough. There are any number of factors, but the question was what is the 'main' factor. And the main factor in the majority of project failures is the PM not adequately doing his/her job. Commented Feb 28, 2012 at 17:39
If I should pick one it would be poor or/and infrequent communication in as many aspects as you can name.
Poor or/and infrequent communication
- with client leads to poor requirements, problems with scope, issues with prioritizing, decreasing feedback loop and many more, delivering different from what the client wanted
- within the team leads to code duplication, missing the main goal of the project, conflicts, poor architecture, poor understanding of the whole project at all
- with stakeholders leads to poor risk management, problems with managing change, inadequate people allocation
I'm sure you we (as a community) can name many more consequences of poor communication. Fill free to add more.
answered Feb 23, 2012 at 16:32
-
1When the team spirit is low; people do not communicate that much. Trust is missing. Technology in those kinds of situation can be detourned (not answering emails for example). The first thing to do to encrease communication is to built a team spirit and a trusted invironment. Now a day, it looks much more as a dream than a reality. But we should not quit on the "American way of doing business" to fast. Commented Feb 26, 2012 at 23:29
From experience turning around too many messy situations:
Weak vision - poor understanding of the end goal. (Symptom: focus on features over the business case)
Undocumented requirements - too much in peoples head. (Symptom: new requirements in testing)
Poor metrics - lack of rigorous quantifiable progress updates. (Symptom: late slips of large magnitude despite no red flags in status)
Narrow boundaries - not anticipating external interfaces. (Symptom: System works but can't pass acceptance testing or realize value due tonconnectivity issues)
-
-
3+1 for lack of documentation. If it's documented, it cannot be reason for despair / delays. Commented Feb 23, 2012 at 21:11
-
I am more and more convinced that being able to take in charge a project requiers a serious training. A solution may be to associate a new project manager to an experienced one (a mentor) on a specific project. He could see righ away if the "new one" have what it takes or not; if he or she does, then the training by the mentor can begin. I mean the mentor coaches the new manager giving him his tricks and insights. Commented Feb 26, 2012 at 23:24
-
Yes. At my firm we've seen it take 6 months of heavy duty shadowing and mentoring Commented Feb 27, 2012 at 3:30
In my experience the single biggest problem is communication. With communication you can get everybody on the same page, agree on simplifications, avoid unnecessary work, identify problems, address problems, resolve issues, mitigate risk, and all the other ingredients of a 'decent' project.
Therefore more recommendation would always be: Fix the communication problem and you have can improve the chances of success substantially. (This could mean that you may have to replace people in some leadership roles.)
Poor project kickoff, chartering: One of my agile mentors, Ainsley Nies, has been a very successful retrospective consultant for the last decade. In more than 80% of the project level retrospectives she's facilitated the cause was traced to a poor project start (poor requirements definition, unrealistic constraints, team issues, etc). All things that could have been identified if the time was spent up front.
The final validation? Ainsley and Diana Larson (Co-Author of a leading Agile Retrospectives) just published "Project Liftoff," a book on agile chartering.
"Eight hours of planning will save eight weeks of work."
answered Feb 22, 2012 at 21:04
-
I totally agree. At the beginning of a project, we do not feel as much pressure as in the end. But if you do not want to feel too much pressure at the end, you must have a rush at the very beginning. To put your project on tracks and be sure it will stay on them. Commented Feb 26, 2012 at 23:34
Inaccurate or poorly communicated assumptions - At the start of the project, the project sponsors, management, an other key stakeholders have a vision about what the project will do and how it will likely progress. To do that, they have to make some logical guesses on how things stand now and what will happen soon. Often times, that "common understanding" or "obvious conditions" are not really true. Even if they are true, they may not be communicated.
The project team may launch down a particular path that does not match the pre-launch assumptions and a lot of time and energy can be spent doing thing that the stakeholders did not actually intend.
-
What you describe is the "I think he knows" process. A project manager wants to show he trusts his team members. He wants to show he is not controlling. So the project manager do not ask too much questions. He assumes that everybody knows how to do his job and will ask is he needs something. Receipy for disaster, unless it is an old team used to work togheter. Commented Feb 26, 2012 at 23:52
Attempts to create certainty where no certainty exists.
This usually results in over-detailed specifications around new, complex areas, with the same detail then being carried into the simpler parts of the project which were already well-understood anyway - so, scope creep.
However, it also results in managers trying to fit their employees to the model they already thought of, or architects trying to shoe-horn a project into some particular shape of stack /technology that they dreamt of ahead of time, or business experts specifying a project as if it will be successful when what they really want is a prototype to try out, or teams making assumptions about each others' interfaces without actually wiring them together to see.
It tends to hide risk under the carpet until late on in a project, when it's too late to do anything about it. This isn't unique to Waterfall projects, either - I've seen it happen in Agile projects, with over-specified story backlogs and arguments about what can or can't be delivered happening way ahead of any reasonable data to support them.
Human beings hate uncertainty. The only way to avoid pretending it doesn't exist is through education, by teaching them about this tendency, and exposure, by putting people into places where it's safe to fail and letting them see how experiment and fast feedback can help. Conversations are really great ways to run mental experiments and provide feedback, which is why they're so important.
There is no way to avoid it in companies that don't make it safe to fail.
-
You found the key of a great project manager career: being safe to fail, especially when you begin your career. We always learn more from our mistakes than from our successes. But in your question, I conclude that everebody has his own safe hidden agenda. The problem, as you describe it, it that those safe heavens are far from the original project. So trying to avoid failure, they provoke it instead. Commented Feb 27, 2012 at 0:02
-
I've actually seen a few companies where they've made it safe to fail and learn, even for management. Truly amazing work going on there. I don't think there's any simple solution, though, just because the dislike of uncertainty is so innate to human nature!– LunivoreCommented Feb 27, 2012 at 14:43
-
There should be some management courses on how to benefit from a failure. Commented Feb 27, 2012 at 21:03
I have read in different places, like in the introduction of "Applying UML and Patters (Craig Larman)", that the main reason for IT projects to fail (hmm, maybe your question is not IT-related) is having bad requirements (as in vague, insufficient, full of implicit assumptions, etc). That is, not knowing what you want to get built or why.
Without getting into a waterfall-ish approach, it is crucial to know what needs to be built, for whom, and why. Using techniques from User-Centered Design and Contextual Enquiries can help a lot both the "client" and the "production" sides understand what they really need and what expectations they have.
A consequence of "doing it wrong" is feature creep and other usual problems.
-
The trap of an IT project is to drown in his tecnical issues. There are some basic general management laws or principles that applies to any situation. The one that you discribe is planification. It is the most important one to my point of view. Commented Feb 26, 2012 at 23:39
Enforcement/Commitment All projects adhere to certain rules of conduct. When these "rules" aren't being enforced, things go down the drain rapidly. This can range from CEOs that ask for last minute changes twice a week without going through the normal RFC process to coders that say "Lets do that unit test later" or "I'll document the stuff later". Once enforcement becomes lax, it quickly gets out of hand and creates a downward spiral. A big part of project management is accountability, once that gets eroded, it becomes very hard to get it back.
Sure there will be times when this is inevitable, but these should be the exception and not the norm, no one should think that its "ok" or "normal" to short cut the system or the team will be dysfunctional eventually.
-
Accountability vanished from our world since the 1980's. Fewer basic business rules disappeared along the way too. The result is the major economic crisis we are in. It is very difficult to rebuilt a economic and financial system based on accountability when, in the current busines culture, most people do not know exactly what it means anymore. Commented Feb 26, 2012 at 23:44
LACK OF VISION AND FOCUS (often misinterpreted as scope creep)
More than anything else, using scrum/agile specifically always seems to uncover the lack of real business vision and focus and how often the team is left confused or misdirected. Often what is uncovered is how often we are asked to change direction (this could also be accounted towards "scope creep").
answered Feb 26, 2012 at 4:46
-
I totally agree with you. All the efforts are invested in implementing the model and the project is left aside. A "managerial recipe" should only be an inspiration to improve or validate what you are actually doing. Commented Feb 27, 2012 at 0:07
In my experience a common failure theme is "promise" failure
1.Makerting over promising to customers without bothering about technical feasibility or achieveability
2.(And often in turn) Project management falsely &/or meekly promising to deliver (such) unrealistic schedules or deliverables .
3.Delivery team in this situation are rendered messengers or manisfestation of the bad news .
How to avoid -
Do the hard research and learning early on and resist every new shiny thing
PMO and Delivery leadership in general needs to be fearless in saying No. Loud and persistent.
answered Feb 26, 2012 at 13:55
-
I never understood why so many marketing department or sales department sell, most of the time, undeliverable package deals. Commission? Bonus? Liking to much risk? You put money in your pocket, and others pay the price for you. Short term, it can go unnoticed, mid and long term, you will create a nigthmare environment to work in and eventually put your compagny in risk of bankruptcy because you will have destroy all the trust realtionships with your clients. Commented Feb 27, 2012 at 0:19
I have done 10 full life-cycle large IT (SAP CRM) implementation projects in the past fifteen years and the conclusion I get from both successful projects and projects ended miserably is always the same, it's the people.
And of course the higher you look on that ladder the more it matters.
The first thing is the people, point, if you have a great team of experienced professionals you have great chance of success. As Gary Klein greatly explained in a final chapter of his great book a good team read each other mind. Sure, you must have good communication in place, you must document what you are doing, you must adopt the right tools to support you, you need to know how to manage change, how to manage the customer, how to cope with adversities... But all these things are always there, what makes a difference? The team, the people. As Warren Buffet once said: "Surround yourself with people better than you and you will drift in that direction..."
The second thing is PMO, which is not just that guy the project manager, it's a culture, it's an habit, and it's not a methodology or any methodology, it's keeping things simple but under control, all things, every thing, every little detail. It requires time, and usually is underestimated, it's often boring, and often seems there are more important things to do than update a gantt, a to-do list, or write the documentation. And often people do these things just because they thing they have to, or they are asked, or because it's a deliverable. In some other cases it's overdone, that's true.
Which drag me to the conclusion.
It's a matter of finding the right compromise; the perfect project doesn't exist, the perfect people does not exist, the perfect customer does not exist, the right time doesn't exist. You need to find the right compromise given the resources, time and money you have at your disposal, you need to do not take things too seriously, but seriously enough, you need to have the sense, and the sensibility. You need to have all these things, all these great people.
And of course chance are you will fail anyway... :-)
It's a damn perilous path...
When you, your team and the client don't do their best, at being their best
-
That is the motivation factor: what motivates someone to do his best most of the time. Money is not always the first factor. You can get motivated by a great team spirit for example or having your say in the decisions making process that concern the tasks you are doing, etc Commented Feb 28, 2012 at 19:52
-
That is very true Simon. When you've worked on a project that went absolutely smooth. What was the main reason? People were motivated. When motivated people get setbacks, in terms of a problem or lak of time, they either find a good solution or stay up the hole night. They make an extra effort to get things going, to get thing done and to do things right. They even get more confidence. A complication is therefore no longer just extra work, but also a challenge that they strive to complete. I think people often forget that it's not the individual, but the entire team that makes set difference. Commented Feb 28, 2012 at 20:33
-
Avoiding conflict.
Either with the customer/stakeholder or the team. Builds up a backlog of issues that only get resolved in the 11th hour and with inevitable pain and dissatisfaction from all.
-
That is the main problem, most people wait for the problem to "jump in their face" to notice it. Human nature? Commented Feb 29, 2012 at 13:53
-
You answer gave me the idea of my last question I asked on the site. Commented Mar 1, 2012 at 15:58
old but still valid: why IT projects fail
- Poor planning
- Unclear goals and objectives
- Objectives changing during the project
- Unrealistic time or resource estimates
- Lack of executive support and user involvement
- Failure to communicate and act as a team
- Inappropriate skills
- Undocumented requirements.
- Documented requirements but not updated.
- Over-promising to customers.
- Under-estimating tasks.
- Building before build-specification is signed off.
