7 Common Project Management Problems (And How to Solve Them)

Feb 4 2011 by James Clear |24 Comments |StumbleBookmark It doesnt matter how talented you are, if you cant manage your projects, then you will struggle to achieve success. To help you avoid that undesirable outcome, here are seven project management problems that designers and developers often face, as well as how to deal with them when they arise. 1. Your Client Gives You Vague, Ever-changing Requirements Fickle clients can be a huge hassle. If a client doesnt know what they want until a certain stage is complete, then schedule those decision points into the project as milestones. It is important to have a clear path mapped out from start to finish because it forces the client to be specific with their requirements, as well as keeping the project on track. Be clear at the outset about what your task is going to be on the project and how much leeway is available. If you will need to be compensated for big revisions or changes in direction, then set a clear outline about the number of adjustments you can make before you need to charge more. If you can, quantify these adjustments with a number; it makes it much easier to keep track of things. 2. Your Client is Slow with Communication People are busy, but its tough for you to move forward on a project if you can never get answers from the person youre working with. The good news is that you will drastically increase your response rate if you do a little bit of work ahead of time. Instead of waiting for the back-and-forth discourse to finally take place, simply start moving in the direction that you think is best and then seek verification. This strategy makes it easy for your client to quickly say yes (orno). Here is an example: Hi Mark, Last time we spoke, you mentioned that we needed to make a decision on task X. I went ahead and started doing Y since that sounded best based on our previous discussion. If youre happy with that, I can move forward and we can review the progress as scheduled on Friday. Sound good? - John The beauty of this framework is that it shifts the clients mindset from, "What decision am I going to make?" to "Should I say Yes or No?" Saying yes or no is much easier than thinking up a new solution (which, as the hired professional, should be our job). Additionally, you will get a response much faster because there is now a time constraint on the work. If they like what youre doing, then they will give you the go-ahead. If they dont, then

they know that they need to get back to you right away because, otherwise, things will be moving in the wrong direction. However, its very important to use sound judgment. Obviously, you wont be able to work ahead and then ask for approval on all aspects of the project, especially those that will cost a lot of time and resources to update should the client say no. That said, youll be surprised how much quicker things get done by making it easy for your clients to say, "Yes." 3. The Project Doesnt Start On Time Maybe you had a slow go of it last month, but now, youre swamped. You know you need to take on the work when you can get it, but now youre worried that you wont be able to start all of your projects on time as you promised. Or perhaps your client says youre a top priority but tomorrow a different project becomes more important. If the hold up is on your end, then its important that you do something to jump-start the project even if its in a really small way. Give the client a call to discuss their expectations and set a more realistic timeframe for the first milestone. This could take as little as a few minutes, but it makes the client feel like things have started. However, beware of doing this more than once. Thats known as stringing the client along they dont take that too well, and for good reason. If the hold up is on their end, then you need to communicate very clearly how that alters things moving forward. Be sure to let them know exactly how this change affects the completion dates of future milestones and you should check the revised schedule against other commitments with other projects. 4. You Try to Manage Every Project the Same Way There has never been a project that has the same circumstance, requirements, and needs as another project. Situations, people, and goals change over time. Instead of squeezing every project into the same template, spend some time crafting milestones specific to the needs of each project. Every job requires specific milestones that meet the schedules of all parties involved. Resist using the standard "2 weeks until X" type of thinking. To put it simply, your schedule changes all the time, right? That means the way you plan your projects needs to change as well. 5. The Client Doesnt Like What You Created If this happens often, then there is a communication issue that needs to be addressed. Make sure you understand not just the technical requirements of a project, but also the underlying rationale of your clients. Why did they decide to do this in the first place? What are they hoping your work will enable them to do when all is said and done? How do they see your project fitting in with their overall strategic vision? Good project managers create a shared vision between all parties. Its your responsibility to understand the direction of your particular project as well as the overall strategy of your client and then to make sure those two items match up. 6. Your Point of Contact Doesnt Seem to Care About Your Project

Working on a project that isnt high on a clients priority list can be frustrating. In some cases, the person responsible for communicating with you has little to no interest in your project. The completed product will have no direct effect on their job, they are hard to ask questions to, even harder to get answers from, and they provide minimal guidance. This issue is best solved ahead of time. When screening potential clients, do your best to find out if the contact person has a vested interest in the project. Pay attention to their awareness about potential problems or risks you could run into, their level of urgency when scheduling this project in their calendar, and their desire to communicate with you quickly and consistently from the beginning. If they brush these issues to the side, then it is worth your time to talk with someone else and establish a second point of contact before deciding whether to take on the project or to avoid the project all together. 7. Too Much Time is Spent Solving Problems After Projects Are "Live" There are bound to be a few bugs here and there, but this is a classic problem caused by focusing too much on production, and not enough on testing. If this continually becomes an issue, then there are two possible solutions. First, schedule in more time to test your projects from the start. Double your typical testing time if needed. Yes, it will stretch your schedule further, but in the long run, it will save you from the countless little problems that prevent your days from being productive. Second, if your ongoing issues are a result of clients constantly wanting you to tweak something here and there, then you need to be clearer about what you do and dont provide with your services. When you set guidelines with a client at the beginning of a project, you need to state very clearly that your work ends after the final product is created and handed off. This can be avoided by outlining boundaries at the beginning of a project that explicitly state that additional service after delivery will cost extra. Putting It All Together There are literally countless reasons a project can run into issues, but the vast majority of them can be solved with clear and frequent communication. While it is easy to point blame in the direction of your client, it is your responsibility to consistently initiate contact and keep the line of communication open. This is about more than just talking to your client. Consistent communication is only created by active effort on your end. It doesnt just happen naturally. One excellent practice you can implement right away is to send your client a progress report every Friday. This could be a full report or just a short email. You should detail what you accomplished this week and what you plan to do the next week. Do this every week, whether your client asks for it or not. Not only does this practice solve problems before they become too big, it will also make your clients love you.

What goes wrong with projects: most common issues & challenges? Every year organisations spend vast sums on initiatives typically described as 'projects'. Every year, there are numerous examples of poor delivery performance, or disappointment with the outcome. PMIS has delivered project management training to leading companies across the UK for well over a decade. Throughout this period, we have been asking the question 'what goes wrong with projects' at the start of training courses, providing two very interesting results:

the similarity of the responses to the above question whenever it is asked the similarity of the results from across very different industries and environments.

The top results, as defined by the participants themselves, are:

unclear goals and objectives lack of alignment to project goals across stakeholders non-participative sponsors and stakeholders, or users poor communication of objectives and targets across the team unofficial scope creep poor/ lack of measures or information on project performance unclear responsibilities across the project (can be catastrophic on its own) lack of / poor quality planning / resource planning poor supplier integration / management lack of commitment or teamworking lack of ownership (relates to many areas)

What is noteworthy is that despite investment in recent years in improved project management methods' (or methodologies), the above results have remained much the same. This says something powerful - which PMIS believe is:

investing in methods assuming that project teams have the capabilities to use them is at best, optimistic the focus of many current PM methods leaves much to be desired - focusing on the 'easy' stuff too may Corporations and individuals are still light on skills to execute project management methods close enough to best practice' - in addition, many have thin Corporate Project Governance processes and capability.

Projects are challenging, and probably always will be. In business though, we still see lots of examples where organisations sometimes make them much tougher than they need to be. Common examples of this are:

limited alignment/ understanding by key team members to/of the objectives of the project; limited commitment to or awareness of key targets of the project plan; limited understanding of the risks being faced by the project; always being too busy fighting fires rather than doing important tasks such as managing project risks; using very poor methods to present and discuss projects in their early stages; issues or gaps in the project organisation and in particular the way responsibilities are defined across the team.

Top Joint Study by UK Royal Academy of Engineering & British Computer Society: There are numerous surveys and a number of research tasks that have looked at exactly the same question. One of the most commonly quoted is the Standish Chaos study, which also identifies the above as common challenges to projects. There are others as well that match the above results completely, for example a comprehensive report produced by the Royal Academy of Engineering in 2004 in conjunction with the British Computer Society entitled the 'The Management of Complex IT projects', which states: " The evidence received clearly and unanimously identified management factors and human, rather than technical issues as the prime causes of project failure. "

The above image is provided with the kind permission of Viki Sauter All of the issues outlined at the top of this page are the responsibility of the management function of the project, and are almost always the key management challenges on projects of any magnitude. As corporations, we must ask ourselves: 'are we prepared to recognise this (culturally) and able (i.e. skilled) to manage projects far more effectively?' Why is this? Why do we think this happens, and more importantly, why do we think this recurs on a regular basis? PMIS believes a lot has to do with:

many individuals who take on the management of a project for the first time underestimate the task they are taking 'responsibility' for, creating a very steep learning curve - add this to the most important phase on every project (i.e. definition), and the prospects of success are likely to be challenged before the project gets off the ground often people only assume the role of project manager on an occasional basis throughout their whole career - by the time they manage their next project the scars of the last one (and the methods they were encouraged to employ) are long forgotten (this is especially true for internal / business projects) too many 'professional project managers' still do not routinely employ the fundamentals of project management as organisations, still, we are often a long way from recognising the likely impact of the above. Top

One other challenge We often encounter people who have just been give the title 'project manager' in similar circumstances to those described immediately above, often for the first time in their career. One reaction, which is not uncommon, as you describe to them the fullness of the responsibilities of project managers, is to see them visibly sink at the thought of what they have let themselves in for. One has to tie this reaction back to the process of choosing them as project managers within their organisations in the first place and the lack of support and preparation they get for this challenging and key role. Too many organisations today employ no real 'science' in the selection of project managers, and too often they do not make very clear to those selected, what they actually expect from them. PMIS is happy to provide tips for project managers, whether you are new to this role or are an old hand. Email PMIS today if you would like to discuss the above or to get information on how PMIS could help you improve your project delivery capability. Related Pages:

Common Challenges Faced by the Project Manager Posted by Brad Egeland Gary Heerkens wrote A Briefcase Book entitled simply Project Management. In it he uses a fictional character, Brad (good choice!) as his subject who has been thrust into the world of project management. Below is Mr. Heerkens section on the common challenges that he sees project managers being faced with as they lead engagements and work with both their customers and their management structure. Read on. Common Challenges You Can Expect to Face

As the Project Manager, can expect to face a number of challenges as you take on the responsibility of managing projects in your organization. Whatever the specifics of your particular situation, however, many of the challenges youll face are faced by most project managers. Lets review a few of these common challenges. The Responsibility vs. Authority Trap Firmly embedded in project management folklore is this one: the responsibility youve been given is not commensurate with the authority (or formal power) you believe you need to accomplish the mission. The size of the gap between responsibility and authority will partially depend upon the structure of your organization. If youre in a purely functional organization and in many cases, a matrix organization you should not expect to be granted very much formal authority. The gap between responsibility and authority will be quite wide. To compensate for your perceived lack of formal authority, youll have to rely upon expert power (respect you can garner through superior knowledge or capability) or referent power (often accessed by practicing an excellent leadership style). Youll also need to rely heavily upon your ability to influence and persuade. Imposition of Unrealistic Targets Sound project management practice suggests that project goals (cost, schedule, quality, and functionality) should be determined through a systematic process of understanding customer needs, identifying the best solution, and formal planning. Throughout this process, realistic assumptions about resource availability, quality of materials, and work process (just to name a few factors) should be used. This approach yields a credible estimation of what is reasonably achievable. If this estimation does not meet business goals, then a systematic risk-vs.-return process should be pursued until it can be verified whether or not the targets can be met within a given level of elevated risk. Thats the process that should be followed. Unfortunately, we live in a real world. Targets are far too often based on desire or a vague sense of what should be achievable, rather than driven by calculated business needs. In even more unfortunate circumstances, targets are developed before its even known what the project entails! In either case, the result is that impatience rather than a rational process drives the selection of the targets. From that point on, a desperate struggle begins, as the team tries to force the project to fit within the boundaries that have been drawn. This practice puts project managers in a very difficult position, as it often sets them up for certain failure and severely undermines the planning process. Unfortunately, this phenomenon seems to have reached epidemic proportion: its one of the biggest complaints of practicing project managers today. Perpetual Emphasis on Function If youre managing a project in a functionally oriented organization, one of the more difficult challenges that youll face is getting team members to overcome their inherent tendency to think

and act in terms of optimizing their own discipline, technical field, or department. Its important to recognize that this phenomenon is fueled by three powerful influences. First, by definition, projects are temporary, but functions live on. In other words, a person often considers his or her work group to be home; the project is just a passing state of existence. Second, unless contemplating a formal career change to project management, a person considers his or her discipline or area of expertise as the work focus. This means that her or she will likely be committed to ensuring the well-being of that area. This strong loyalty could, for example, give rise to counterproductive situations, such as team members using your project funds to advance their discipline perhaps in excess of what customer requirements dictate. Finally, theres the power of the paycheck. Simply stated, most people tend to pledge allegiance to the source of their paycheck. For most people in most organizations, thats their work group or functional department, not you. The Dual Responsibility Trap Most project managers I encounter are asked to wear two hats. They must perform their job duties while acting as the project manager. This situation may present additional challenges for you. At the center of this dilemma is the issue of allegiance. Imagine for a moment that youre facing a critical decision. Unfortunately, whats best for the project will negatively impact your work group but what benefits your work group will hurt your project. Whats the right decision? What do you do? If you make the decision that benefits your work group, you risk being viewed as a poor project manager. If you choose the course of action that benefits the project, you may incur the wrath of your peers and/or departmental management. Its a tough spot and you can almost bank on being in it, possibly often. A more fundamental problem of the dual responsibility trap is figuring out how to divide your time and attention between the two roles. How much should you allocate to each? How long can you try to satisfy both before you realize youre working most nights and weekends? Finally, a third issue often surfaces in the form of thetwo boss syndrome. The project manager reports to his or her functional supervisor and to the person who manages the project management function in the organization. Again, this is a difficult situation for most project managers. The Fundamental Conflict of Certainty and Uncertainty Many misunderstandings and disconnects between project managers and organizational management can be traced to the fundamental conflict between the certainty that management requires to properly run the business and the inherent uncertainty of project work. Cost and schedule estimating provides us with an excellent example. Suppose youre just beginning a project. Its likely that you have limited information on this project and theres a significant degree of uncertainty. In a situation such as this, project

management practice suggests that you would be well advised to use ranges of values when providing estimates on cost and schedule. The size of your range would reflect a level of accuracy consistent with the extent of your knowledge and the amount of uncertainty. In our example, it would be perfectly appropriate for you to estimate that the cost of your project will be somewhere in the range of $400,000 to $550,000. Unfortunately, many project managers today would receive a very unfavorable response from their organizational management to that type of crude estimate. It doesnt provide the certainty that management requires for approval. Unfortunately, this example is not exceptional. The uncertainty associated with projects exists throughout the life of the project: it simply never goes awaynor does managements craving for certainty.