Project management training. Learn through simulation.

What is the most common mistake that PMs make?

 

Opinion poll of PMs and related professionals on various LinkedIn Groups

May 2012 to Aug 2010

 

Author: Roland Hoffmann
Sponsor: Hoffmann Conseho Group

 

NOTES
Last names and employers of respondents are masked.
Responses are unchanged (including spelling and grammar errors).
Roland Hoffmann’s classified answers in PMBOK® Guide knowledge areas to calculate the RESULTS. Some responses cite more than one mistake, and some were difficult to attribute clearly. Responses citing multiple mistakes received multiple classifications, and difficult cases are classified as accurately as possible by the root-cause.
Roland Hoffmann classified lack of subject matter expertise as attributable to PMBOK® Guide knowledge area Quality.

 

RESULTS

Total responses (08 Aug 2012): 76

PMBOK® Guide Knowledge Area: Communications
Number of responses citing this as a source of biggest PM mistakes: 21
% of times cited as reason: 23%

PMBOK® Guide Knowledge Area: Quality
Number of responses citing this as a source of biggest PM mistakes: 20
% of times cited as reason: 22%

PMBOK® Guide Knowledge Area: Scope
Number of responses citing this as a source of biggest PM mistakes: 15
% of times cited as reason: 18%

PMBOK® Guide Knowledge Area: Integration
Number of responses citing this as a source of biggest PM mistakes: 13
% of times cited as reason: 14%

PMBOK® Guide Knowledge Area: HR
Number of responses citing this as a source of biggest PM mistakes: 11
% of times cited as reason: 12%

PMBOK® Guide Knowledge Area: Risk
Number of responses citing this as a source of biggest PM mistakes: 7
% of times cited as reason: 8%

PMBOK® Guide Knowledge Area: Time
Number of responses citing this as a source of biggest PM mistakes: 5
% of times cited as reason: 5%

PMBOK® Guide Knowledge Area: Cost
Number of responses citing this as a source of biggest PM mistakes: 1
% of times cited as reason: 1%

PMBOK® Guide Knowledge Area: Procurement
Number of responses citing this as a source of biggest PM mistakes: 1
% of times cited as reason: 1%

 

PMBOK® Guide DEFINITIONS OF KNOWLEDGE AREAS

 

(Source: A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fourth Edition, ANSI/PMI 99-001-2008 and IEEE 1490-2011, PMI, Newton Square PA, 2008)

Integration Management (“Integration”) includes the processes and activities needed to identify, define, combine, unify, and coordinate the various processes and project management activities within the PM Process Groups.

Scope Management (“Scope”) includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.

Time Management (“Time”) includes the processes required to manage the timely completion of a project.

Cost Management (“Cost”) includes the processes involved in estimating, budgeting, and controlling costs so that the project can be completed within the approved budget.

Quality Management (“Quality”) includes the processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken.

Human Resource Management (“HR”) includes the processes that organize and manage the project team.

Communications Management (“Communications”) includes the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimately disposition of project information.

Risk Management (“Risk”) includes the processes concerned with conducting risk management planning, identification, analysis, responses, and monitoring and control on a project.

Procurement Management (“Procurement”) includes the processes to purchase or acquire the products, services, or results needed from outside the project team to perform the work.

 

POLL RESPONSES

 

LinkedIn Group: The Association for Project Management (Official group)

Nigel W. PM Plymouth, United Kingdom: I can only speak from domestic housing construction specific knowledge, however, I would say a common mistake of PMs is failing to exercise sufficient management control over the professionals’ inputs during the design/preconstruction stages of a project. (Roland Hoffmann attributed this response to PMBOK knowledge area HR.)

David M. Associate Manchester United Kingdom: An interesting topic. I agree with the lack of planning thread. Surely it must be the ‘cardinal sin’ for PM’s. Isn’t this their specific brief ?? Nigel your point may be about to be addressed with the imposition of BIM on construction projects. Typically the construction industry lags significantly behind IT and engineering on this front. It will be interesting to see how much difference this makes in reality. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Robert S. Programme/PM Oxford, United Kingdom: I would have said that many PM’s forget why they are doing the project and only see what they are doing. They forget who they are doing it for (stakeholders) and the benefits the business intend to achieve through the project outcome. Reducing the specification of the deliverable, overspending, delivering late or not aligning with stakeholder requirements can reduce or wipe out the delivered benefits entirely, in which case the project is of little value. (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Adrian D. Fellow APM, Croydon, United Kingdom: I think you can sum it up as they don’t do the things they know they should. I have analysed lessons learned reports for numerous clients and they often say things like should’ve spent more time with stakeholders; should’ve done a risk register etc. They had all been on the basic courses and knew what they should have done. It was just pressure of time that made them focus on issues as they arose rather than preventing them happen in the first place. It’s a bit like diet and exercise – we all know what we should do but find it difficult to actually do it. (Roland Hoffmann attributed this response to PMBOK knowledge areas Integration and Quality.)

Nigel W. PM Plymouth, United Kingdom: An interesting comment Adrian which suggests that some PMs are not acknowledging that there is a limit to the complexity of project which they are able to manage. An experienced PM operating within his own level of competence should at least be able to advise the client/stakeholder on his own resource requirements to undertake the management of the project. Regardless of the possible reasons for wanting to secure the PM instructions,( e.g. lack of work, politics, high profile project) if the PM seeks to manage with insufficient resources then the PM should not seek to blame lack of time or pressure of issues for poor management.
I’d suggest to Roland that one of the mistakes PMs make is undertaking projects beyond their own ability and competence. (Roland Hoffmann attributed this response to PMBOK knowledge area HR.)

Steward C. Owner, Sydney Australia: Poor project planning – I think this to be the most common PM mistake. In includes no planning at all, only high-level planning or improper planning. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Jyoti M. Senior PM, United Kingdom: Agree with Steward Copper, it is inadequate project planning coupled with inadequate monitoring of the plan followed by remedial actions to get the plan back on track or re-plan with revised targets as appropriate (of course with appropriate stakeholder involvement etc). I think, the most common mistake made by PMs is not planning the project holistically and not keeping the plan ‘live’ as the project progresses (which is to keep the plan up-to-date in response to the current reality of the project). (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

 

LinkedIn Group: Project Zone – Project Management Excellence Network

Darlene S. Project Coordinator Montreal, Canada Area: I find that the most common error would be assuming instead of confirming that Communications are clear to all the project team and/or stakeholders. This should be done within the meeting itself, and then by a meeting minutes notice sent out to all requesting a confirmmation of acknowledgement and understanding. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

 

LinkedIn Group: Project Management Jobs

Lalit Kumar J. MD at United Arab Emirates: Manytimes the requireents (scope) are not defined clearly and that leads to scope creep. At other times the acceptance criteria is not… (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Muhammad Usman B. PM: I have observed that some of the PMs are not transforming the true picture to customer what they got from supplier. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

 

LinkedIn Group: LinkedIn The Society of Systems Integration Professionals

Sean N. Owner Washington D.C. Metro Area: I would have to agree with Matthew, but I would add, that not having progress meetings with the Install supervisor, engineer and other key players only adds to existing problems by not creating a forum to address issues. Just showing up on site and giving lip service to issues does nothing to solve them. (Roland Hoffmann attributed this response to PMBOK knowledge area HR.)

Adhir R. Solutions Developer Cape Town Area, South Africa: Well apart from being able to communicate with all stakeholders, being able to manage requirement changes and control service realisation behind those changes are most important. (Roland Hoffmann attributed this response to PMBOK knowledge areas Communications and Scope.)

Chris C. Head of Media Network Integration Laboratory London, United Kingdom: Completely agree with the thread so far. The key mistakes for me are: 1. Assuming they know what is going on, frequently they don’t usually because of lack of site attendance and stakeholder contact. 2. Assuming that those involved have the resources to recover, as well as understand the broader implications of project slip. Again this is usually as a result of poor Communications. These days it seems that many PM’s take (or are given) too many projects in the same phase of delivery that can push them towards a “”desk only”" management approach with very few site meetings basically because they just do not have the time. (Major project slip can cause this as well) This can be great while they get away with it but I think good project management starts with well managed PMs! The problem with this is that all too often the PM is the “”coin in the stamping press”", but it could be argued that’s the job.” (Roland Hoffmann attributed this response to PMBOK knowledge areas Communications and Risk and HR.)

Mario H., P.E. Consulting Engineer Greater Salt Lake City Area The biggest mistake is not involving all stakeholders. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Martin K. Senior Manager Greater New York City Area: I would agree that the lack of timely site visits and client interaction is a key contributor to project failure. I have also found that because of the highly specific nature of the engineering we work around in the television business that having subject matter expertise is critical. Even if you as the PM do not, then knowing who those key resources are and leveraging them to stay abreast of the technology will help you make the correct decisions. These areas include how and when to load your resources. All too often PMs just “grab” at resources as they see equipment that needs to be installed and commisioned. What they don’t see is the interaction or interoperability that the equipment has with other systems. This can require bringing a resource back to site several times. Coordinating these key resources with 3rd party vendors is also part of the equation. This can only be done correctly with the understanding of how the “system” functions and not just the specific peice of equipment or software operates. Of course this all starts with solid Communications. (Roland Hoffmann attributed this response to PMBOK knowledge areas Communications and Quality.)

Matthew B. Audio Video Technician Greater San Diego Area: You want the truth? As an installer/technician I think the most common mistakes that PMs make is that they never want to go onsite and think they can PM a job from thier desks. The best PMs I ever met were onsite at least once or more a week. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

 

LinkedIn Group: LinkedIn Television Broadcast Technologies

Clive R. Managing Director Southall, United Kingdom: Some interesting thoughts here. Some contributors are describing roles which I would define as a Technical PM, rather than a PM. TPMs are people who have detailed technical knowledge of the technology involved in the project they are managing, and thus become involved in (or wholly responsible for) the technical design, and in the solution of technical issues arising in the project. PMs can be pure process PMs, who manage the project delivery process and liaise closely with all of their team which includes the technical experts whose role it is to do the design and solve the technical problems. There are pros and cons with each. TPMs can become so interested and enthused in solving the technical issues, that they take their eye and focus off of the timescales and budget management, which then slip. Non-technical PMs can be “”fobbed off”" by technical people making invalid excuses on technical grounds, which a TPM would see through.
For me, having managed PMs and TPMs, the key issues for successful project management are: 1) Be very clear what the deliverables are, and, as importantly, what they are not, thus avoiding scope creep. 2) Be fanatical about management of the timescales and budgets – slip is not an option. 3) Manage risks and issues with the same fanatical attention to detail. 4) Communicate, communicate, communicate. Make sure everyone knows where they stand, what is being delivered and what is not, by whom, and when, and keep reminding everyone until you feel like a nag, or a worn record. 5) Manage change control with an iron fist. Changes cost time and money. Ensure that any deviation is documented, communicated, and the new timescale and cost is agreed by the customer before you allow any work to commence on a change in scope. 6) Tackle every problem head on straight away – no hoping that by ignoring it it will go away, or someone else will sort it out. The sooner you tackle it, the less impact it will have. 7) At the end of a project there will be a hand-over into an ongoing operation. Make sure that people are properly trained, documentation is accurate and complete, and hand-holding is provided during the handover, and that this has been budgeted for before the project commences. 8) Have a governance structure in place, whereby regular reviews of project progress, budgets, timescales, risks and issues are held by someone far enough removed from the project that their only interest is delivery of the agreed deliverables on time and budget, and they have no other vested interests in the project. In my experience, any one of these 8 things can be mishandled, ignored, etc. causing project failure, overrun and/or overspend, and I wouldn’t want to try to say definitively which is the most common, but if you’d like me to take a stab at it, I would say it is a difference in expectation of the outcome (deliverables) between the customer and the supplier, leading to scope creep, overrun and overspend, and a customer who thinks that they have paid more than they had budgeted for, and still not got what they wanted. Given that most customers’ expectations far exceed their budgets, being very clear at the outset on what will be and what will not be delivered – in detail, not just at high level – is probably the most critical single factor in ensuring a project’s success.
I think that very often, in order to close a sale, people will take the approach of “”We’ll sort that detail out later,”" and in order to try to keep the customer happy, they’ll say “”We’ll include that change free of charge.”" In both cases, the avoidance of confrontation, or negotiation, up front comes back to bite both parties further down the line. (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Paul J. Director of Engineering Modesto, California Area: The clients long term goal needs to be met .It also needs to also has to have incorporated into it any changes in specifications that may be in the near or distant future. Really inquire about the projects goals and do your diligence if you want the pronect to really serve the clients needs today and tommorrow.When they are succesful so will you be. (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Peter W. Managing Director / Broadcast Engineer London, United Kingdom: I agree with everything that Clive says …… There is a lot where setting expectation and checking what the client and end users are wanting from the project…. (these may not be the same!!!) Most of my career I have been involved in sorting out scoping of projects/and the budget in time money and resources – as well as doing a fire brigade job on projects going wrong …as well as running my own workstrands I can remember one “”pure”" PM who to reduce the cost and bring the project in on time persuaded the Client (an leading News organization) that their ON line graphics area should not be cabled to the studio (or anywhere)…. and tried to hand it over !!! Often there is a time lag between the quote and the client saying go ahead – VERY FEW people do any due diligence to see if anything has changed …. or even to validate the prices from suppliers … and there can be some very interesting changes ….. Projects always have a bit of scope creep – it is knowing to allow something in the quotation and managing it – as Clive says- with an Iron hand..and chasing out the likely creep at quotation… I advocate the use of a TPM to lead -they must have accreditation/track record as a PM – with a pure PM on bigger jobs or across a portfolio to keep a check on the process…reports minutes etc that the lead TPM is generating. Getting a (T)PM on board as early in the process and or having good timely and documented handover betto any new PMs..” (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

David M. Manager, Broadcast Operations Greater Los Angeles Area: “They don’t know the product like the operators know the product! I know this isn’t directly answering your question but think this should be an interesting discussion string. Roland, what is the title of your article? When will you publish it and where can we see it? Neil is right when saying many PMs aren’t technically qualified to provide good options and solid solutions to their client(s). And, as Paul mentioned engineering is a service business. Engineers are very good at understanding workflow on their specific products. They are generally assigned just one piece of the workflow and they are good at it. More often than not the person hired as PM is either the expert on the product or the charismatic sales person that gets the customer excited about the concept of the product. You often find them working in teams which really are best if the company can afford it and if the team works well together. The responsibility ultimately lies in the hands of the PMs Boss. He/she needs to identify the strengths and weaknesses and expectations of the PM – He needs to continually re-evaluate the process and outcome. Whoever the PM is they need to, in my opinion, have a complete understanding of the company concept and the entire workflow to be successful. [Not broad strokes of each area of the workflow…every aspect of each area] I’ve seen it over and over again when I’m in a product demo when the PM says, “Let me reach out to my engineering team and I’ll get back to you”". When on the inside I’m thinking, “He should know this”. It’s hard to find a PM that has the charisma of a salesman and the analytical skill set of an engineer.” (Roland Hoffmann attributed this response to PMBOK knowledge areas Quality and HR.)

Neil H. Windows Guru London, United Kingdom: In my experience many PM’s are not technically qualified in Project planning or soloution specification, I think there should always be an experienced engineer as part of the consultation process (PM’s only occasionally have this experience\qualification themselves) . (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Neil H. Windows Guru London, United Kingdom: Totally Agree with you David, Im a fairly cynical person according to a lot of people when it comes to this kind of thing (id say more of a realist and experienced than a cynic, but whatever’). I think the unfortunate thing is that the role of a PM is a collision of several very differing disciplines, and quite often a PM is hired (by less than technical leaders/managers etc who have no ability to judge whether they are suitable or not) for their administrative abilities way over their technical knowhow or understanding of the workflow of users, quite often projects are under such pressure to be delivered on time the actual detail and planning is irrelevant as long as the money is spent and goods are delivered before the deadline, and the integration is slapped together as almost an after thought often left to somebody else, support engineers, operators etc, to pick up the pieces and make into some kind of workable setup. I think i’ll stop there ;0). (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Paul J. Director of Engineering Modesto, California Area I agree. I am answering the question from an engineers perspective. Keeping in mind an engineering service is just that, a service providing the tools a company or individual needs to complete a specific task. We are a support organization providing a service for clients to perform a process with an end result of the best quality and the least overhead in the most efficient possible manner .After all quality and profit should always be the engineering firms and clients motivation. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Robert L. V.P. Sales & Product Development Sacramento, California Area It’s evident that a lot of thought and experience has gone into the previous comments. But from my more narrow perspective as a manufacturer of a control product, I find that the number one failure of the PM is that they spend too much time on designing a workflow, and not enough time verifying the feasability of it with the manufacturers of the individual products. That is, it looks good on paper, but that’s where it ends. I am currently working with a TPM on a very large project that incorporates six major components from six different companies. This particular TPM has confrenced, one by one, a technical rep from each company with us to assure that the control required between each of the products and the controller will meet the requirement of the final product. This is not the usual case with a PM. I usually get one call at the end of the design phase asking flatly, “do you control this item”? The eventual fallout of this is not a pretty sight. If it were my project, money, time and job at stake, as the end user I would want better assurances from my PM than, “they say they control it”. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Seamus O. Director Ireland They don’t spend enough time to get customer buy in to the project. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Seamus O. Director Ireland “I normally am involved in the sales process but the answer is the same even if I inherited a project from the sales team. In order to drive a good project it is important to spend the time early on with the stakeholders to get their buy in – whether it is with the end users ot even just other suppliers to the project. In relation to project management and engineering expertise – some organisations now favour the use of generic PM’s rather than those with technical skills related to the project. I don’t like this trend as it carries inherent “”risk”" and overly relies on the good will of others to avoid technical and financial mistakes being made due to the ignorance of the PM. The client side engineers will often have no respect initially for the PM and may allow errors to be made just to score a point with senior management. The PM must spend time with these stakeholders to gain some trust and support – again we are back to project “”buy in”"”. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

 

LinkedIn Group: LinkedIn Sony Alimni

Michael A Technical Lead Greater Seattle Area: Not understanding the business deeply enough. A knowledgeable PM can be a dev teams and test teams best asset if they understand the big picture and the details. Claiming “I’m here just to be a facilitator” is a sure sign that a PM exhibits the wrong behavior and is just a glorified time keeper. Other common mistake is thinking that software development is like civil engineering. We aren’t building bridges or buildings. Software is never finished because the business environment never ceases to change. A great PM can explain the areas (business rules) likely to change from those not likely to change. Engineering can then focus on proper encapsulation where appropriate. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

 

LinkedIn Group: LinkedIn Project Management Jobs

Debby S. Greater Memphis Area: I would say failing in their relationships with team members – which, in turn, would break down communications for another fail. PMs need to cultivate their relationships, keep communication channels open and not do everything themselves but rely on the team. A PM has to have a 3,000 foot view and a detailed view at the same time – they cannot do this without having those relationships. (Roland Hoffmann attributed this response to PMBOK knowledge area HR and Communications.)

Tim P. PM Greater Los Angeles Area: I think one of the biggest mistakes is trying to force a project into a methodology. I see a great deal of people from CEO’s to Engineers to PMs getting caught up on methodology rather than looking at a project as a unique undertaking that requires a unique plan and process . Having a clearly defined plan is of course vital, but they should be customized to every project, what is good for one project doesn’t mean it is good for all projects. Sometimes breaking the rules works. Being flexible is key to success, not running the perfect methodology. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Monty S. Director Phoenix AZ Area: Letting a sponsored dictated date stand without negotiating the scope, budget, resources, to be able to meet deadline. (Roland Hoffmann attributed this response to PMBOK knowledge areas Time and Integration.)

Megan G. Sr. PM Chicago Area: Creating schedules and not getting buy-in from the stakeholders doing the work before communicating to clients and leadership. I have seen this so often that it is pretty scary. Until you have confirmed the accuracy of the effort to complete the work and delivery dates, you do not have full commitment from the team. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Theo S. PM Brussels Area, Belgium: losing focus on the goal of the project. Thinking that “”as long we are moving, everything is ok”". Well, wrong. It is better to stand still than to move in a wrong direction. (Roland Hoffmann attributed this response to PMBOK knowledge areas Scope and Integration.)

Jürgen S. Senior PM Munich Germany: No transparency of assumptions or not verifying them. (Roland Hoffmann attributed this response to PMBOK knowledge area Risk.)

 

LinkedIn Group: LinkedIn PMJobs

Brian L Senior Program Engineering Manager Greater New York City Area: As I read the replies, a common theme is very apparent….the planning stage is extremely critical and the period at which errors and mistakes have the largest impact. The plannimg stage is the critical stage for any program. Make a mistake there and it ripples through the entire life cycle of the program. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Declan K. I.T. PM Ireland: Not adhering to the PMBOK methodology. Each step is there for a reason, ignore at your peril. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Michael W. Sr. Program Manager & Export Compliance Officer Greater Philadelphia Area: From my experience one of the most common mistakes is underestimating effort on an agreed upon scope. If the defined scope is underestimated you not only threaten delivery right from the start, but you also don’t have any wiggle room for unforeseen issues which always occur on any program. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Les G. Technical Project Coordinator Greater New York City Area: Scope-creep is one of the stealthiest mistakes PM’s make. Stakeholders want to keep adding on extra tasks that were not in the original definition of the project. This can throw off your projected time-line for completing the project (not to mention additional costs). Need to mitigate the risks by letting them know immediately of the consequences -and get them to sign off on the changes! (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Neil D. Executive Program Manager Mumbai Area, India: Focusing on the “now” only instead of 2 steps ahead which I believe a good PM should do. (Roland Hoffmann attributed this response to PMBOK knowledge area Time.)

Robin L. PM China: So at the project beginning, PMs should setup a clear and achieveable target and assignment. (Roland Hoffmann attributed this response to PMBOK knowledge area Time.)

Susan P. PM United Kingdom: Thinking they know the answer before they understand the problem… (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Anand V. Program Manager San Francisco Bay Area: Need to secure all resources upfront – allows realistic project planning. (Roland Hoffmann attributed this response to PMBOK knowledge area HR.)

CaSandra M. IT – PM Greater Atlanta Area: Forgetting to build and maintain morale. (Roland Hoffmann attributed this response to PMBOK knowledge area HR.)

Shashidhar G. Senior PM Bengaluru Area, India: Assuming (or believing) that everyone will honour their commitment! (Roland Hoffmann attributed this response to PMBOK knowledge area HR.)

Dhruv K. Director, Program Advisory and Business Transformation (PMP, ITIL & Six Sigma-Black Belt) Canada: Now my time to provide answer…. The common mistakes or opportunities I see with various PM’s I work with are as follows: ▪ Poor Communication ▪ Poor Change Management ▪ Poor Planning ▪ Undefined/undocumented Scope ▪ Poor Stakeholder Management ▪ Poor testing ▪ Poor Requirements gathering. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications and Scope and Quality.)

eva O. Product Manager / User Experience Designer China: Recently I got a problem that the Q’ty of daily active users are being decreasing after I published newer version into the market. Before that, our market member asked a request to disable the service of data automatic synchronize that results most users will consume data connection, particularly they fail to put their notes to cloud (my product is about on-line notebook). In China market, there’s a critical concern with the data connection consuming. But take truly, it’s not good decision if I apply to the product strategy (because the auto sync service will result higher ADU, if disable, it will be effected). But fewer users had encountered with the data consuming problem and got a little mad to make rumor on-line. In order to cool down this matter, I decided to take temporary strategy to deal with the data connection problem after there’s unsuccessful notes sync. If so, I disabled the service temporarily. But nobody knows the data decreasing if it was being resulted from the strategy I made . So I tried to pick out the data and more than comparing between older version and newer version. I found that most users who using older version were being upgrading to newer version that means the decreasing could be not blamed to the bad product experience. It could be other reasons (maybe channels deployment). Maybe from the surface, it seems to my wrong decision. OK! Once it was my fault, it should be taken temporary and proactive solution to dealt with. In particularly, make your mistake to be given a “REASONABLE” explanation for your team. Keep going and be flexible to adjust is our duty, isn’t it? (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Glenda S. Project Management Consultant Greater Seattle Area: Failing to identify all stakeholders and where they fall in the support and power matrix. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

JB S. NPI Program Manager China: I think it is misunderstanding each other with the team member or stakeholders. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Les G. Technical Project Coordinator Greater New York City Area: Forgetting to CYA! (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Gregg D. Sr. Program Manager Washington D.C. Metro Area: Failing to proactively identify, manage and mitigate (if possible) risk factors such as scope and technical development risk. (Roland Hoffmann attributed this response to PMBOK knowledge area Risk.)

Hugh J. PM / Design & Technical Author United Kingdom: These areas of risk are called Critical Paths, which should be set as a template early on in any project or introduced as a hazop; either way they are a necessary part of Management discussions. One of the most critical areas in this is the ordering of materials or plant, which depends largely on the promises of wholesalers who are eager for business but can introduce a large set back in any programme – how do we mitigate bad promises ? (Roland Hoffmann attributed this response to PMBOK knowledge area Risk.)

Marco A. PM Campinas Area, Brazil: Assumptions (either known or unknown) sometimes lead to errors, once they tend to blind project team to potential risks. Besides being mandatory to document assumptions, keeping an eye on how true the assumptions are would be a risk mitigation plan for potential risks. (Roland Hoffmann attributed this response to PMBOK knowledge area Risk.)

Shashidhar G. Senior PM Bengaluru Area, India: Failing to spot the potential risks at their very early stage and working on mitigating them. (Roland Hoffmann attributed this response to PMBOK knowledge area Risk.)

Robin L. PM China: For long term project, just use credit cards for your partners, this can be set as a system which can assure most of cases under control. For short term projects, this mostly depend on so called “managing talent”. (Roland Hoffmann attributed this response to PMBOK knowledge areas Procurement and HR.)

 

LinkedIn Group: LinkedIn Freelance Audio Visual Technicians

Richard E. Electrical & Audio Visual Services South Africa: Having worked as an AV tech and pm for the last 24 years I think you are generalising saying that PM’s do not no the technical side of the business, If a PM has no technical knowledge he/she has no business in the AV industry. A good PM should know all aspects of the Industry. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Vasant R. Independent Contractor Toronto, Canada Area: Thinking they actually know the business and technical side of things when in reality they know nothing. They need to stick to their role of providing the right image in front of the client and keeping out of it. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Vasant R. Independent Contractor Toronto, Canada Area: The larger and more complex the project , especially if it is a technology related field, the more they struggle. Not only that, they put everyone else into untenable situations as well. The only thing they are best at is internal office politics, pointing fingers assigning blame etc, hiding their incompetence behind rules and regulations. Everywhere else…….. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Jennifer L. M. Admin Assistant and Small Business Owner Washington D.C. Metro Area: Not managing PEOPLE well, and this applies in ANY industry! (Roland Hoffmann attributed this response to PMBOK knowledge area HR.)

 

LinkedIn Group: LinkedIn Broadcast Projects & Contracting Network

Adrian S. cott Owner Consultancy Bath, United Kingdom: There is lots of seriously good advice in this thread. The most important points that I would add are these: – Be prepared for the scope to change during the life of the project. In today’s broadcast and electronic media industry, both technology and the business models around content are changing so rapidly that what an enterprise thinks it wants to do, and the technology options available, will almost certainly change during the course of an average sized project. Either the business requirement will change, or the client will demand that a new piece of whizzy technology must be included. Exactly how you prepare for Scope Creep will vary, but something to avoid is being boxed into delivering a totally new set of requirements on the budget which was agreed for the old ones. – Every broadcast project these days is a multivendor lash up, and a mistake that many people have made is to believe broadcast manufacturers when they say they will integrate with each other’s systems to build your ideal solution. Even if they really mean it, it is not at all sure that they will be able to achieve it, and even if they achieve it, it is questionable whether the integration will survive the first major software upgrade on the part of one of the manufacturers. There is an awful lot more, but I will not risk boring everybody rigid!” (Roland Hoffmann attributed this response to PMBOK knowledge areas Scope and Quality.)

David S. Broadcast and Channel Management System Consultant Israel: I, like Frederic, say that misunderstanding the client’s requirements is one major and common mistake. But I would take that one step further and say that the mistake begins in believing that your client actually knows what his requirements are..!!! In my experience, projects have gone way beyond budget and way off schedule because of too many CR’s late in the game. If the client had the right people working for him, or if the vendor would have invested more time in not just listening to what the customer has to say but also dig deeper to find those hidden requirements, then the project would have a better chance of having a happy end…. (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Frederic P. Sales & Technical Director Hong Kong: misunderstand the client project requirement and wrongly estimate the project completion time and resources. (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Keith E. Managing Director Hong Kong: Not defining the Project fully in the first place and communicating it to all. Once you have defined the project and all its component parts then – You can get a proper timeline/resource needs – Senior management know what they are getting and have to sign off on – You know what scope creep is as it is not in the definition Usually skipped because it takes time and effort to do it properly. (Roland Hoffmann attributed this response to PMBOK knowledge area Scope.)

Bruce L Owner Architects Washington D.C. Metro Area: John, As Architects, we all love to do ground up buildings, but in reality, 90-95% of broadcast work is renovation. This adds to the degree of difficulty which requires sequencing the work, and not bumping the power, which will drive the engineer to pull his hair out. (Roland Hoffmann attributed this response to PMBOK knowledge areas Time and Quality.)

Bruce L Owner Architects Washington D.C. Metro Area: Building complex technical projects require a team that includes a PM that understands all the pieces of the project. The best PM’s understand MEP systems and the component requirements. They don’t need to understand Sets or Newsrooms, but with 60% of the construction cost centered around the basic infrastructure, not being very familiar with the components and how they fit together is a significant drawback. (Roland Hoffmann attributed this response to PMBOK knowledge area Cost.)

Jim M. Senior Broadcast Engineer Glasgow, United Kingdom: Believing anything other than what you have verified for yourself! (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

John L. Media Technology Consultant Greater Pittsburgh Area: Bruce, I think you have a very good point. New construction requires different skills than broadcast infrastructure. Conversely, someone managing a complex broadcast project must have a fundamental understanding of modern workflow, IT and baseband infrastructures, good installation practice for copper and fiber infrastructure, and managing both engineering and installation of systems which are outside the experience of most professional PMs. Only if the PM understands the issues can they successfully guide a team of professionals to a focused business goal. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

John L. Media Technology Consultant Greater Pittsburgh Area: Again, I agree. Managing the trades (and professional services) involved in a building construction or renovation project is quite different. It would be foolish to hire a broadcast integration firm to manage the physical renovation, though they may have significant input into the design and construction details where they impact the completed systems. Conversely, there are not many construction PMs who are competent to set goals and manage the build out of modern technology infrastructures. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

David Hall Broadcast Engineer Orlando, Florida Area: Believing that your boss has given you adequate information. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Geoff S. Programme Manager Business Change Hempstead, UK: Operating in “Manager” mode when what is actually required is Leadership ! Business change impacts upon people that are instinctively resistant to change – the fear of the unknown if you will. In all circumstances a well-led project will carry stakeholders to successful outcome, this in contrast with a well-managed project which may well have been perfectly administered yet failed in its objectives. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Hayden M. Broadcast Design and PM Sydney Area, Australia: Communication. The lack of a comms plan and clear accountable direction from PMs. Communicating the scope, schedule, W.B.S., quality and deliverables. This is the fundamental justification of having a PMs position within the broadcast technology group. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

John L. Media Technology Consultant Greater Pittsburgh Area: Reporting results in lieu of managing in advance, and failing to define what success will look like at the end of the project. The first prevents managing behavior instead of simply accounting, and the second makes the goal vague and therefore unobtainable. (Roland Hoffmann attributed this response to PMBOK knowledge areas Risk and Scope.)

 

LinkedIn Group: LinkedIn Broadcast Professionals

Paul J. Director of Engineering Modesto, California Area: Not looking to the future to accomodate upgrades,changes in technology and expansion of a systems capability based on the long term goal of a company. (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

 

LinkedIn Group: LinkedIn Broadcast Engineering and Technical Professionals

John Demshock Engineering Manager TV Orlando, Florida Area: Not beginning with the end in mind. Clearly defining the end objective and major goals before the budgeting and timeline decisions are made is critically important to a successful project, and a very hard thing to do especially from the standpoint of an outside PM coming into a complicated operation. Not only do you have to ask the right questions, you have to know who to ask, and the political landscape of the facility, as well as the technical landscape. Been beat with that stick, as they say. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Ruben C. New Technology Research Mexico City Area, Mexico: Underestimate the needs. (Roland Hoffmann attributed this response to PMBOK knowledge area Integration.)

Silvio B. Video Engineering Milan Area, Italy: Hi Roland, sometimes I think some PM lacks or underestimate the knowledge of everyday work. This is true when it comes to a project like an upgrade of an existing solution, these things to have a life of their own and you can’t always apply theory in full. Involving the staff in the project is a good way IMHO to know the critical points that can lead to late delivery or busget overruns, even more if custom software have to be developed (which is more an art than a science, as well as engineering). (Roland Hoffmann attributed this response to PMBOK knowledge area Quality.)

Gerard D. Digital Media Architect Sydney Area, Australia: Most Projects revolve around Change and most change effects People. PMs tend to forget that their project is as much about managing people as it is about budgets and deliverables. The mechanics of Project Management aside, many PMs forget that the success of their project lies in the hands of the people who accept the change, embrace it and move ahead with it in their grasp. Some of the very best PMs (technically) can be thwarted by clients who just will not accept change. It is a difficult and rough road for the PM who does not recognise the significance of cultural change in the workplace. A skilled PM will make it their priority to let their Client think that the change was the Client’s idea to begin with. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Robert C Cheif Engineer TV Guam: Unfortunately, Most PMs are not part of the sales/design phases and to actually make things work for FAT test, have to endure a lot of change orders,red-lining of drawings, and other decisions that make the project deliverable. So the connection between PM and project failure would be mostly communication fallout between the DE and the PM. (Roland Hoffmann attributed this response to PMBOK knowledge area Communications.)

Roland Hoffmann did not attribute the following responses to any PMBOK Knowledge Area:

Robin L. PM China: Of course, ownership is the top key, I think.
Sunil S. Sr.PM Bengaluru Area, India: PMs assume that they are just “managers”.. :)