347 647 9001+1 714 797 8196Request a Call
Call Me

Traps to Avoid in Project Management

May 22, 2015
, , ,

A project manager is responsible for ensuring that all project resources and activities sync with one another to meet the project objectives. In the course of the project, there are many traps and if the project manager is not alert, any of them can derail the project. Let us see some of these and how a project manager can watch out for them and not fall prey to them-

1. Being too ambitious – Youwant to achieve the moon and more. But while managing a software project, as a project manager you have to have your feet on the ground. It is important to understand the requirements of the project and ensure that they are doable within the constraints of time, cost, quality and risk . It is easy to promise everything to the client and you might want to deliver more than asked for to impress the client. But this is a classic trap that many project managers fall into. When you start detailing out the plan, you realise the effort, cost, dependencies, risks etc. So it is important to set realistic project objectives. There is no reward in over-promising and then failing to deliver.

2. Not updating project plan – The project plan is created at the beginning of the project and all the project information is mentioned there. But once the project activities have kickstarted and the project manager gets busy with tracking, monitoring and controlling tasks, sometimes the project plan update takes a backseat. This is dangerous, as an outdated project plan will not have the current information. Changes in milestones, resources or communication plans should be updated else the project execution will be different from the project plan and there will be no document to verify what is correct and this can lead to conflicts with the team and stakeholders and the project manager might have to face unpleasant questions from senior management.

3. No re-evaluation of project parameters – The project cost and timeline are based on estimates made before the project started. At that point of time, the requirements may not have been detailed. There is not much know-how on team composition, skill levels of team members and client representatives in the initial phase. As the project kickstarts and a detailed requirement analysis is done, there should be a re-evaluation of estimates. Once the project manager knows the team and its strengths and weaknesses, he should re-evaluate the project parameters and bring in changes accordingly. If he foresees any issues, he should raise a flag for the same. Some might keep everything status quo and hope for the best. This is equivalent to setting up a trap for oneself and falling in it. When issues do crop up, it will be too late to rectify them and the project manager will have to handle unpleasant situations.

4. Bringing in too much change for the end users – Have you noticed how you need to make an extra effort to use your new Android mobile phone when you were earlier using a Windows phone? You tend to give commands that you used to give in your older phone and then realise that it is different in the new one. It takes you a while to get used to the new phone. Similarly, a new software application means the end users have to be trained to use it. There will be some resistance to learning and using new technology and getting used to the change in the application. There will be a learning curve as well. When deliverables are given to users, there is training involved. But a few training modules will not make them experts in it. There will be process changes and technical changes. Initially they will be confused and maybe even frustrated using the new application. They may not be able to produce their deliverablesleading the business manager to complain about the product. The project manager should ensure that there are not too many overwhelming changes and give time and help to the users to get used to the process and technology and eventually master it. He should also build a professional rapport with the key end users so that there is mutual trust and unpleasant situations can be avoided.

5. Implementing small changes without change management – Like it or not, there are going to be changes in the project and you cannot escape from it. But as a project manager you should be in full control of the changes. The client always wants more and more for the price that he has paid. Some changes requested by the client can be implemented with just two lines of code and the project manager might be tempted to incorporate the change without following the change control process thinking that this is a small change and there is too much effort involved in following the change management process. But it may happen that the small change may lead to more changes ahead in the development cycle. Accommodating changes will give the impression of you being a flexible project manager and the client will be pleased. But it is imperative that the documentation for change is prepared and signed off by the client and the change is implemented as per process defined. Accommodating many small changes can lead to usage of more effort and can affect the project schedule. If the changes are not documented, the developed product will be different from the requirements document and this can lead to conflicts. Change is the universal truth in software projects.

Project management is a challenging. Delivering the application as per expectations and seeing clients use the application is quite exciting and rewarding. If you avoid the traps mentioned above, you have a higher chance of delivering a successful project.


About the Author

Vidya Kumar is a management graduate with 14 years of experience in the IT industry managing complex Software Projects across various industry verticals. She has around 6 years experience in content development. She has co-authored two eBooks and writes regularly on personal finance, IT, travel and other business topics.


Global Association of Risk Professionals, Inc. (GARP®) does not endorse, promote, review or warrant the accuracy of the products or services offered by EduPristine for FRM® related information, nor does it endorse any pass rates claimed by the provider. Further, GARP® is not responsible for any fees or costs paid by the user to EduPristine nor is GARP® responsible for any fees or costs of any person or entity providing any services to EduPristine Study Program. FRM®, GARP® and Global Association of Risk Professionals®, are trademarks owned by the Global Association of Risk Professionals, Inc

CFA Institute does not endorse, promote, or warrant the accuracy or quality of the products or services offered by EduPristine. CFA Institute, CFA®, Claritas® and Chartered Financial Analyst® are trademarks owned by CFA Institute.

Utmost care has been taken to ensure that there is no copyright violation or infringement in any of our content. Still, in case you feel that there is any copyright violation of any kind please send a mail to and we will rectify it.

Popular Blogs: Whatsapp Revenue Model | CFA vs CPA | CMA vs CPA | ACCA vs CPA | CFA vs FRM

Post ID = 76014