The dire certainty is that in the world of project management, things will surely not always go as planned. Positive lessons have been learned and shared with others, to help them avoid the common pitfalls of project management. From experience, many project managers have absorbed that if you are unable to manage projects, then you will struggle to attain success. The key is to effectively deal with them when they arise. Project management is not an easy task and requires thinking rapidly through a project, problem, or topic as necessitated (Schiff, 2012). How project managers successfully deal with the quality, cost, and schedule of their projects will be addressed.
Problems In Project Management and the Lessons Learned Thereafter
Common project management mistakes and the laborious methods to fix them are often time-consuming and potentially costly for IT executives. With so many projects to manage, and just as much mismanagement, IT executives face the dilemma of IT projects taking much longer than planned and costing significantly more than budgeted even with the use of project management software. Delving into the conception of why good projects go bad, how to avoid common pitfalls, and the lessons learned which are shared by IT executives and project managers, provide impressive tips for avoiding some of the most common and costly project management mistakes.
Assigning the Wrong Person to Manage the Project
An inexperienced or inadequately trained project manager can doom a project. Too often effort is focused on coddling stakeholders or clients instead of giving them an honest assessment of the task at hand. Additionally, management still sees communication efforts as something that ‘just happens’ instead of enacting careful planning measures that will reduce the risks of a communication breakdown, but like the longevity of a fine-tuned marriage, every action taken to make it work requires productive communication. Monterroso (2013) states “ineffective communications is the primary contributor to project failure one third of the time, and had a negative impact on project success more than half the time.”
My experience with communicating with clients/stakeholders is to put myself in their shoes. If there is a process that I cannot understand, then I do not expect for them to understand it either. Just like Allen (2008), I call anything a “project that is likely not to be finished with one action step, or in one sitting.” For instance, I was the account manager for a major cellular company and one of our top clients threatened to pull all 50,000 lines of service with us because of a billing issue. I was the secondary on the account so I was not the main face or voice that the client dealt with regularly, so when problems arose, it was my duty to come in and fix them. Even though we had several meetings with the clients who expressed some of their concerns, the meetings always ended on a positive note because the primary account manager always assured them that it was an easy fix and she would take care of it. Just to be sure and to stay in the loop, I had her explain the details on how she proposed to do this. She eventually reworked their bill, and allegedly placed them on the correct pricing plans so that they could share minutes and save money. Of course, this was not what happened. I could not figure out why she kept calling in sick from work and always had an appointment when the customer wanted to meet. Eventually, they called and threatened to pull all lines if the problem was not resolved that day. This was the day the primary called in sick and did not communicate anything about the customer’s disappointments with our services.
This was not an easy conference call since all of my managers and the client’s executives were on the call and fuming about their bill. At first glance, I could not figure out what the problem was but I intently listed to the client’s concerns and made no outright assurances on anything that I could not deliver. Once I pulled up a few of their lines of service in the computer, I realized that my coworker had actually placed them on the entirely wrong share plans for business-to-business mobile, and for months had just been issuing credits to their accounts. I carefully explained the situation and went through the charges on the paper bill so that they could first understand the bill and then see the erroneous errors made so that I could offer them a solution that worked.
The client not only remained with our company, but they also stated that was the best conference call they ever had. During each phase of the process, I communicated what the client should expect.
I did not present myself as a charlatan, but offered them the truth and set their expectations accordingly through several more conference calls and email updates.
Lessons Learned. Choose a project manager whose skills or expertise matches the requirements of the project. Also, establish an effective communication plan to avoid any surprises that can occur throughout the project.
Lack of Specificity With the Scope
A project without a particularly clear goal is ill fated. Scope change can be one of the most threatening predicaments that can happen in a project. If it is not handled accurately, it may well lead to cost and time surges. The PMBOK® Guide describes scope creep as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval” (PMI, 2008, p 440). The scope statement should define the foremost activities of the project in such a way that it will be unquestionably clear if extra work is subsequently added (Verzuh, 2012).
Jennifer Rudd, PMP, principal, San Pedro, California, USA explains her worst project occurred while working for a developer (My Worst Project | PMI Career Central, 2010). She was in charge of fixture and appliance procurement and had a verbal agreement with the developer to use painted appliances instead of stainless steel. The painters did the cabinets in a shade that drastically contrasted with the kitchen appliances and unfortunately, could not be returned. The bright spot was that the appliance company could switch out the painted cabinets for stainless steel ones but it increased the cost by eight percent. This was not a fun experience for Jennifer. She neglected to properly document, clarify, distribute, restate, and use visuals that would aid a large team of people with varying deliverables and priorities.
Lessons Learned. Define the scope of the project from the inception and monitor the project consistently to ensure project teams and stakeholders involved are keeping within the scope. Change requests need to be tracked independently from the original project scope, and precise client/stakeholder approval for each change must have prior authorization. In addition, all estimates on how the changes will affect the schedule must be provided.
From my own experience, restating to the client as to what is in the scope of work is imperative. A particular client of mine that I provided services for on a pro bono website tried to maneuver pamphlet designs into the scope. Once the incurrence of fees was reiterated, the client backed down, and the project proceeded as scheduled.
Failure To Engage the Project Team
Projects often fail because there is a lack of support from the departments and people involved or affected by the project. Verzuh (2011) identifies stakeholders as anyone who is connected to a project and has a stake in its results. It should be the first task of a project manager to identify these stakeholders whether they are customers, employees, decision makers, or vendors. Frequently, many key stakeholders are forgotten, which leads to many instances that can result in a project’s failure such as, a lack of accountability, poor project skills, disinterest among stakeholders, reduced communication, scope creep, and impossible deadlines.
Too often, managers fail to generate a sense of urgency about the project misleading the team to think that business as usual is acceptable.
Lessons Learned. To avoid this, a good plan to identify stakeholders must be implemented before the project begins. Enlisting a good communication plan, which documents how the stakeholders should be informed so that no one is neglected during the progression of the project, is good practice. Project managers must be mindful of the different needs of each stakeholder and should abide by their different requirements to obtain information. Once a communication plan is set in place, it is good practice for the project manager to choose a reliable and efficient software solution that can store all communications and resources centrally, as it leads all project contributors through established communication processes. The project manager should also request a meeting with the team, which should include any off-site employees via the best option for technology available. A presentation about the project and its substance should be delivered with zeal, to get the team fired up.
No Metric To Define Success
Success metrics are specific desired outcomes that measure the success of the project. According to Verzuh (2012), when success metrics are imposed in the proposal, it increases the capacity to monitor and intensifies the probability that the project will truly deliver results. Many things will change before the end of the project but the success metric should begin to provide value for the project from Day 1.
Joshua Y., a wood manager from Kalona, Iowa, USA knows how important it is to establish a success metric (My Worst Project | PMI Career Central, 2010). He started a project doing wood millwork for a homeowner. The homeowner’s representative had previously fired several contracting companies before hiring Joshua and his team. Joshua knew very little about the history of the project but quickly learned about the disorder and the unruliness of the owner’s reputation. Joshua and team were scheduled to do ten million dollars worth of work but unfortunately, completed only half. In their dealings with the client, they ran out of time and answers. The failure of this project was substantial. Their team went ahead with the project with lots of gusto, no clear goals and plenty of uncertainty. Many issues arose because team members were not fully aware of the project risks because they did not take the time to properly assess the project. Joshua’s words are a reminder of this “with indecision and terrible communication, there was great frustration for all” (My Worst Project | PMI Career Central, 2010).
Lessons Learned. The project manager should make it a number one priority to ensure that he or she understands what the client will consider as a successful completion to the project. When it is understood what makes a project successful all parties involved will walk away gratified.
Conclusions and Future Lessons Learned
Everyone usually expresses some sort of reflection as to why a project fails and there can be numerous reasons why a project is not a success. A crucial factor is leadership. Since a project manager cannot handle every aspect of the project it would be wise to delegate certain responsibilities to project team members, who are talented individuals working toward common goals. A project’s strength is intertwined with the skills and strengths of the people involved.
In addition to knowing your team, a project manager should also know the customers and objectives at hand. Significant changes should be done when necessary, but consulting the customer should be done first.
As in the case of Joshua, blindly rushing into a project without any type of research or historical background seals the impeding doom of the project. Meticulous consideration needs to be given to the conditions at hand prior to engaging in decision making. This will minimize the need to redo the work.
Lastly, good communication is that which will prevent missteps from becoming failures. Mistakes happen and it is always possible to recover, but failure is a sinking ship.
David Allen: The Project Management Problem. (2008, April 7). Retrieved from http://www.huffingtonpost.com/david-allen/the-project-management-pr_b_95172.html
Monterroso, Y. (2013, June 18). Poor Communication Leads to Project Failure One Third of the Time. Retrieved March 15, 2014, from http://www.coreworx.com/pmi-study-reveals-poor-communication-leads-to-project-failure-one-third-of-the-time/
My Worst Project | PMI Career Central. (2010, November 29). Retrieved from http://www.pmi.org/Professional-Development/Career-Central/My-Worst-Project.aspx
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® guide) (4th ed.). Newtown Square, PA: Project Management Institute.
Schiff, J. (2012, September 26). 12 Common Project Management Mistakes–and How to Avoid Them – CIO.com. Retrieved from http://www.cio.com/article/717321/12_Common_Project_Management_Mistakes_and_How_to_Avoid_Them
Verzuh, E. (2012). The fast forward MBA in project management. Hoboken, N.J: Wiley.