Authority and Responsibility, How They’re Related and How They Affect Project Management

Veteran project managers know that they accept responsibility for the project when they accept the role of project manager. They also know that the lack of authority can seriously impede their ability to deliver the goals and objectives set for the project. Responsibility is directly proportional to consequences. Responsibility for project results doesn’t mean that they get placed on the bench until the next project if the one they’re leading fails, it has a monetary consequence. They will suffer with the project through elimination or reduction of bonus, a re-assignment to a less responsible role (with an attendant reduction in salary), or dismissal in the case of consultants. The connection between responsibility and consequences is entrenched in business. Larger more costly projects will tend to engage more senior project managers and the consequence of failure will be proportional. The connection between project results and consequences will also be heightened.

What is lacking in my experience (20 plus years as a programme and project manager) is a correspondence between authority and responsibility. Project managers can do much of the project planning without having access to authority. Project managers will need some help from subject matter experts for some of the planning work, even if it’s just to validate effort or cost estimates. Larger, more complex projects tend to have more need of subject matter experts to the point that some of the work is planned by these experts. The authority needed to acquire and manage the resources needed for this work will usually come with the territory. It’s when the project reaches the build or implementation phase that the project manager needs authority. They can plan the work, organize the work, and monitor performance but without authority they have a very limited ability to ensure the work is done on time and with the necessary quality.

The largest, most costly, most complex projects are led by project managers who hold senior positions in their organizations and bring that level of authority to their projects. The Manhattan project, which delivered the Atomic bomb during World War II, is a good example of this type of project and project manager. Leslie Groves, who managed the project, was a 3 star (lieutenant) General. The vast majority of projects which don’t fall into the Manhattan project category in terms of size are where the connection between authority and responsibility falls apart.

Most projects nowadays are executed in a “matrix” environment where the organization uses project managers to run projects and functional managers to manage people. The matrix environment is a good fit for most organizations because they have a mix of operational and project work. The problem with the matrix environment is that seldom do they come with a blueprint for the division of authority between the functional and project manager which means that the project manager has none of the authority and the functional manager has it all from the resource’s perspective. Organizations with more mature matrix environments may have taken some steps to resolve the issues that this division causes, but rarely do the definitions of the 2 roles include a precise description of authority. This is probably also due to the fact that the HR group plays a big role in defining authority through their policies and they tend to be behind the curve in accommodating their policies to the management of projects.

Problems start with the acquisition of the project team. Project managers are prone to the same greed and the rest of the human race and would like to have a free reign to acquire the best resources the organization has to offer. Functional managers, on the other hand, have their operational responsibilities to consider. They will be compensated for the resources they relinquish to the project but aren’t usually incented to make sure their best and brightest are made available to the project manager. That’s because their performance is measured based on the success of their operational responsibilities. If they make their best resources available to the project, they may fail to deliver on their operational goals and objectives and that may have a negative impact on their compensation. The best approach I’ve seen to balancing operational and project needs is to have functional managers whose sole responsibility is the “care and feeding” of resources. Since they don’t have any other operational responsibilities, they are free to assess the competing needs of projects and operations and make assignment decisions based on their perception of what’s best for the organization.

Problems encountered with team acquisition will propagate throughout the rest of the project. Presuming effort and duration estimates were based on some level of performance that is greater than some of the acquired team are capable of meeting, project performance will suffer. Pointing out to the project sponsor that performance issues are being caused by under-performing team members may or may not bring relief. The sponsor is likely to view your complaint with scepticism if you didn’t raise the issue before. An inability to perform the work is not the only cause of poor performance. By far the most common cause of inadequate performance is the bleeding of resource time from the project by operational demands. The demands may be quite legitimate and the operational work demanded of the resource may be the best possible use of that resource for the good of the organization. That doesn’t help the project manager when he or she has to explain poor project performance to the stakeholders. This situation is bad enough when the project manager is given notice of the demand but is much worse when they learn of the change after the fact. The level of authority the project manager has been given, or at least the functional manager’s perception of that authority, will often determine whether they find out about the operational work before or after the fact.

The other side of the resources coin is the recognition and rewards that are used to build team morale. A lack of authority in this area usually has to do with the project manager’s ability to spend money to give awards or purchase any other kind of team building activity. Recognition and rewards are usually governed by HR policy which is the reason the project manager is not given authority to bestow these on deserving team members. The lack of any kind of budget to buy awards is the other reason.

Lastly, the project manager may be called upon to deal with team members whose head just isn’t in the game. They have the ability, experience, and training to perform the work at the level of competency envisioned in the project plans but don’t. There may be a variety of reasons for this but they usually stem from the resource’s commitment to the project, or lack thereof. Let’s look at the example of a process improvement project to illustrate what I mean. The benefit of the process improvement is the elimination of effort which will translate into job loss (at least in that department). Some of the team members who work on this project may be the ones whose jobs will be eliminated; after all they’re the subject matter experts in the old process. Is it reasonable to expect these folks to show enthusiasm for the project? Of course not. Unless the project manager can show these team members how the project will benefit them, or at least not harm them they’re going to be less than committed to the objectives of the project.

The lack of enthusiasm may have nothing to do with security; there are any number of reasons for a lack of commitment from team members: jealousy, the perception that their best interests are served if the project fails, a commitment to a project they perceive as competing, dissatisfaction that a friend is not assigned to the team are just some of the “political” reasons that a team member may not give the project their best effort. Resolving any of these issues will require that the project manager have some degree of authority over the resource. This doesn’t necessarily mean they have hiring and firing authority, the ability to influence their compensation may be sufficient.

Now that I’ve made the case for an authority commensurate with the degree of responsibility, let’s look at some ways and means of acquiring that authority. I’ll start by addressing the folks who sponsor projects. You should hold your project managers responsible for project results; that’s their job, but it doesn’t make sense to hold them accountable without giving them the ability to meet the project’s goals and objectives and authority is a key component of that ability. You can help here by coming to an agreement with your project manager over the degree of authority you’re giving them. Working within the policies dictated by your HR group, you should assign them the authority level you both agree they need. Don’t speak in generalities, be specific. The project manager should know what their remedies are in the case where they have performance issues with team members. The process used for determining the composition of the project team should also be clearly articulated. How will disagreements over individual resources be resolved? Of course to do this in a way that makes sense for your organization, you’ll need to prioritize your project against the other projects and operational work of the organization. If the project goals and objectives are high priority, the project can’t be a low priority when it comes to competing for scarce resources.

Their level of authority over the team members, once the team has been defined needs to be clearly articulated as well. How will the project manager deal with a team member whose performance is sub-standard because they don’t have the necessary skills or experience? How will they handle the team member who has the necessary skills and experience but isn’t performing for some other reason? The project manager’s authority needs to be articulated in sufficient detail so that these questions are answered. Delegating authority to the project manager doesn’t have to contravene any HR policy. For example, it may be against policy to allow the project manager to hire or fire resources but where stakeholders, customers and others, contribute to performance reviews make sure the project manager is a contributor and make sure their review is weighted in accordance with the amount of time the resource spends on the project and the project priority. On the other hand sometimes projects are important enough and HR policies behind enough to warrant changing them. Don’t be afraid to gather political allies and make the case for change to HR. You may be successful in effecting the change for the next big project even if you aren’t successful making the change for the current one.

The project area that the project manager will need authority for is recognition and rewards. The project manager should be able to articulate a recognition and rewards programme for the project, or how they will utilize existing recognition and rewards programmes. Ensure they have sufficient authority to administer the programme. This will mean a budget, in most cases. Work out how you’ll make the money available when needed in cases where it’s impossible to give the project manager any signing authority. Lastly, make yourself available to take part in awards ceremonies or team building activities. I haven’t dealt with any sponsors who didn’t enjoy these occasions once they had been exposed to them.

Project managers who have sponsors that have failed to read the above, or who are not comfortable taking the initiative with you, will need to initiate the conversation themselves. Once you’ve defined the level of authority you need in detail make certain it’s documented. If your authority isn’t written down anywhere, you don’t have it. People’s memories being what they are, the perception that you have of the authority you have will differ from your sponsor’s and that gap will only widen as time goes on and memories deteriorate. Remember that the authority you’re given isn’t plucked from thin air, it is authority that your sponsor has (or any other senior stakeholder) that they delegate to you.

Your authority should be captured in the Project Charter. The level of detail need not be any greater than the rest of the charter; you can leave that to specific tasks or purposes. It should be spelled out in generalities such as “the Project Manager has the authority to participate in the selection of the project team”, “the Project Manager will evaluate members of the team and these evaluations will be used in performance reviews”, or “the Project Manager has the authority to address performance issues”. Specifics can be left until the project advances to the stage where authority is needed. For example, you can ask for an e-mail from the sponsor in advance of team acquisition specifying how decisions will be made on individual team members and how disputes will be handled.

Authority is like a muscle: it will atrophy if it isn’t used and won’t be available when it is most needed. Your sponsor has given you authority so that you can use it to achieve your project’s goals and objectives so you should never fail to achieve them because of a lack of authority unless you were specifically denied it. This means that when team members refuse to recognize your authority to direct their work you must use it to impose your will on them. Don’t confuse the imposition of your direction with abuse. You abuse your authority when you use it for purposes other than the accomplishment of the project’s goals and objectives or when you show favouritism imposing consequences or rewards. Avoid abusing your authority at all costs, but not at the cost of failing to exercise it. To ensure you avoid abusing your authority it’s a good idea to have your HR organization’s policies and guidelines handy and ensure you’re familiar with them.

Project managers who initiate the conversation about authority will have the advantage of being able to define the level of authority they believe they need. This can either be done by spelling your authority out in the draft version of the Project Charter or in some other document that precedes it. Don’t be faint-hearted here. It’s better to have authority that you don’t need and don’t use than to fail to have it and need it. Don’t be shy to exercise an authority you don’t have because neither you nor the sponsor foresaw a need for it. Your sponsor is much more likely to forgive you exercising an authority that leads to the accomplishment of a project goal than they are to forgive you for failing to meet the goal.

Most of what I’ve said here will apply to project managers who are permanent employees of the organizations they manage projects for, but what about consultants? These folks perpetually find themselves in “matrix” environments because even in organizations that are projectized or that have a mature, proven matrix arrangement, they don’t apply to the consultant. Consultants need to be especially diligent in outlining their level of authority and in using it. Their authority will never include the ability to fire or to pick and choose resources when acquiring the team. At most they will have the authority to hire contractors and participate in acquisition negotiations for employees so they need to ensure that they have a remedy that will address an insoluble problem with a team member. Don’t forget that when you first arrive on the job you’re an unknown quantity to the stakeholders. They may have had exposure to you when you interviewed for the role but you’re still an unknown quantity. After you’ve been in the role for a while you should have gained a level of trust that will allow you more leeway in exercising authority but until then don’t make assumptions that could embarrass your sponsor.

Finally, if you fail to have your sponsor delegate the authority to you that you need to succeed, make sure you document that fact. How do you do that without insulting your sponsor? Simple, not having the authority needed to achieve project goals and objectives is a risk to those goals and objectives and should be captured in the project’s risk register. Don’t describe these risks in personal terms; describe them in terms of what the risk event looks like and the likely impact on the project if they happen. A conversation about mitigation strategies to address the risk may lead to granting you the authority. At the least they should lead to a mitigation strategy that will reduce the level of risk. If all else fails and there is no granting of authority or identification of acceptable mitigation strategies, the project must accept the risk. You still have the option of reviewing this risk and its acceptance whenever the risk register is reviewed with the stakeholders. A word of caution here: the risk identifies a disagreement between you and your sponsor; don’t use this as an opportunity to embarrass your sponsor in front of their peers or managers.

One final word of advice for all project managers: it’s usually easier to ask for forgiveness than permission. When in doubt assume the authority and exercise it. If you’ve overstepped your bounds but achieved your objective your sponsor may point the mistake out to you, but won’t be as unhappy with the result as they would be if you failed to exercise the authority and failed to achieve the objective.

How to Move From an Engineering Position To Project Management In 10 Easy Steps

Getting pigeonholed is a killer when it comes to career advancement – especially if you’ve spent the last 5 to 10 years progressing through the ranks in a technical position. Moving into a managerial position seems an unattainable dream, particularly when you consider that only about 20% of major organizations actually operate leadership development programs and a mere 5% concentrate on bringing out the managerial talents of their technical staff.

But it doesn’t have to be that way.

If you can learn to:

  • Spot gaps in the market
  • Apply creative strategies
  • Boost your knowledge

… then you can make that move and become a top project manager, irrespective of your particular line of business, background, skill-set or location. Here are the promised Ten Commandments for facilitating the transition.

1. Apply for a Project Management Professional (PMP) certification

PMP certification is the industry standard for aspiring managers as it demonstrates to employers that the holder has attained a high level of relevant education, competency, and experience. During the PMP course, you would be taught how to:

  • Manage a project from inception to completion
  • Conduct internal interviews and extract key information
  • Plan projects in detail and establish the optimum solution
  • Allocate your resources in the most efficient and cost-effective way
  • Understand contractual and managerial terms and apply them in the proper manner
  • Motivate and run your team of staff to achieve their maximum potential

Seeing your PMP certification, potential employers will know that you have been instructed in the correct way to perform managerial tasks and have not picked up the bad habits which are common among self-taught managers. This makes you a much more employable proposition.

Even experienced project managers who want to make their resumes stand out to employers and boost their salaries are also good candidates for a PMP certification. Many project managers have found that the PMP certification not only demonstrates their project management expertise, but also helps correct many of the bad habits they’ve picked up over the years, making them more valuable employees in their present position, and more tempting job candidates in the future.

2. Think EI, not IQ

Your Intelligence Quotient (IQ) has got you where you are today but now you need to acquire something called Emotional Intelligence (EI) as well.

Extroverted social skills are often mislabeled as Emotional Intelligence. However, EI refers to your ability to manage, monitor and regulate your emotions in a balanced and healthy manner in order to achieve your personal and business objectives. EI encompasses the ability to:

  • Understand emotions – discover the interrelationships between emotions and gauge how they develop and mutate with time
  • Perceive emotions – translate the body language of both real people and image representations
  • Use emotions – learn problem-solving techniques and channel your moods and emotions to the needs of your work
  • Manage emotions – take charge of both your positive and negative emotions

You were not expected to become the DaVinci of Intelligence Quotient (IQ) in your technical position, nor would you be expected to become the Obama of Emotional Intelligence (IE) in your new job, but you need to acquire the skills to influence stakeholders in order to achieve your project objectives.

As a project manager you will have to rely 10% on your IQ and 90% on your EI. With an appreciation of EI you will be in harmony with your team and thus able to construct highly successful working relationships with them. According to research, unlike IQ, EI can be gained through conscious efforts in interaction with others, through training and sometimes through peak experiences.

3. Interpersonal skills matter

Nobody fancies a project manager who makes a habit of sitting at his/her desk all day, avoiding any interaction with other humans. No man is an island and it’s no good just knowing the theory of how to be a project manager unless you can put it into practice. That means getting others to take instructions and carry them out for your project to the best of their ability, all without any authority or micro-management. Developing good interpersonal skills will not only aid your relationships with those below you, it will also profit your dealings with senior management and help to convince them that you really do have ‘what it takes’.

4. Grow a thick skin

As a project manager, there will be tough times that will truly test you to the limits of your tolerance. However, you must learn to focus on achieving the goal of your project while, at the same time, not letting others undermine your confidence. Only by keeping the big picture in the forefront of your mind will your project succeed, therefore letting others ‘get to you’ and thereby damaging your self-belief is an absolute no-no.

If you’ve been working in a rather technical position, this is almost certainly a significant departure from your normal routines with their typically finite tasks and their predetermined standards. The role of project manager requires a thick skin and the supreme determination needed to batter through to victory.

5. Improve your negotiation skills

Managers are required to negotiate on a daily basis. These negotiations can relate to anything from agreeing minor personal matters with juniors, to negotiating a major contract or a financial package for the company. Such skills take time and practice to learn, and there are online courses which offer intensive training in this area. Signing up for one, you can expect to acquire knowledge of:

  • Collaborative and competitive strategies
  • Maintaining objectivity by not ‘making it personal’
  • Reviving a stalled deal
  • Finding the Best Alternative To a Negotiated Agreement (BATNA)
  • Coping in a hostile environment
  • Search for alternatives and win-win solutions

Good negotiators possess a talent that is guaranteed to prove an asset when promotion is being considered. They are always in demand.

6. Lead from the front

If you lead, others will follow – as long as you motivate them, that is. The goal of your project may be all that matters to you, but your workforce will probably have other primary considerations and, as a project manager, you will need to encourage them to brush those aside for the moment in order to seize the day. The analogy with the role of a king before a battle is apt, and while a saber-rattling Shakespearean-type speech might be a bit over the top in an office environment, there still needs to be iron in your words if you want to inspire your troops.

The ability to motivate is essential for any manager and is a skill which must be acquired. There are a variety of online courses available to teach you how to:

  • Become an effective leader
  • Run effective meetings
  • Provide stability in times of crisis
  • Work with difficult people

A good leader will always attract followers. As a result, it’s well worth investing the time and effort to become one. Learning to develop a positive attitude that can be maintained even in difficult circumstances is also one of the keys to successful leadership. Failure to do so can raise the level of uncertainty among team members and other stakeholders. The effects of increased uncertainty on people’s performance will always be negative, but keeping an upbeat attitude is the best way to avoid these problems. During difficult times, the most successful project managers are able to offer an extra dose of stability, direction and hope for their project team by projecting a hopeful and positive attitude. This approach will build team morale rather than tear it down. Project managers who embody a positive attitude in the face of adversity set an important example for others to follow.

7. Don’t try to do it all alone – get a mentor

There’s no reason why you should reinvent the wheel. There are people out there – you probably know some already – who possess the skills that you are striving to acquire. Why not approach one of them with a view to tapping in to their acquired knowledge and experience?

While there are recognized qualifications in mentoring, in reality a mentor can be any person whom you trust and who will guide you and challenge you in your personal development.

The choice of a specific mentor is a very personal matter as what works for one person will not work for another. That said, there are some attributes which should be taken into account when seeking one, and these include the mentor’s ability to:

  • Encourage
  • Inspire
  • Teach
  • Interpret body language
  • Maintain high standards
  • Set goals for you

At the beginning, you may even attend some of your mentor’s project team meetings or even project reviews sessions with company executives to learn the kind of presentation skills that are expected of you when it’s your turn to be in the hot seat.

Mentors are usually in the fortunate position of being able to offer their services for free however this is naturally a matter to discuss and negotiate before the first session. Meeting once or twice a week is usually sufficient but, as you progress, you may decide to reduce this frequency to the level of an ad-hoc arrangement.

Since you never know when you’ll need your mentor again, you should continue to update them on your progress, even when you have finished regular sessions.

8. Be willing, ready and able of learning beyond your area of expertise

As a project manager, you must possess an understanding of the work of your organization’s other departments, their functions, and their specific requirements. This ‘all-round’ knowledge is the foundation for making balanced and informed decisions and, without it, no project manager can hope to operate effectively.

Learning this experience and knowledge is a part of the PMP course in which you cover a variety of major disciplines such as:

  • Finance and accounting
  • Information Technology
  • Human resources
  • Quality management
  • Risk analysis
  • Procurement & Logistics

Standing still is never an option and a sincere belief that ‘there’s always something new to learn’ is a very sound one. Times change – you need to move with them.

9. Gain experience of projects at all different stages

Projects are typically split into 5 different phases, each of which presents its own specific challenges. Consequently, if you are looking to progress from technician to manager, you will eventually need to be able to handle all 5 of these stages. This means that you must be able to demonstrate a proven track record of having been involved in each of them.

You should always be pro-active in seeking out new projects at any stage of their existence and keep a daily log of:

  • Process Groups your were involved in (Initiation, Planning, Executing, Monitoring & Controlling, or Closing)
  • What the project was trying to achieve
  • Challenges and risks faced by the team and solutions found
  • Your particular involvement – what you have done, learned, or suggested

This log, which can contain anything you’ve done that has any project management implications, will prove essential when the time comes for you to make the transition. It is an ideal companion for interviews and exactly what your new employers will want to see. It will also allow you to talk with complete confidence about real-life situations and the solutions that you helped implement.

10. Learn how project management tools are used

While your experience and knowledge of your industry will be essential in helping you make the right decisions as a manager, you will also be expected to utilize the many tools that are available to project managers. To give you a better idea, some of the more common ones are:

  • Gantt Charts & Critical Path Analysis
  • Earned Value Analysis
  • Financial Reporting & Bank Transactions

Look out for these tools and make the effort to learn how they are created and the diverse ways in which they are used. Don’t be afraid to ask for explanations and guidance about them from your colleagues, mentor, or other contacts.


Without a doubt, the most secure way of progressing from a technical role to project management is via the PMP certification route. During your training, you will learn the technical skills necessary to get you to the top and keep you there. Possessing the PMP certificate is a clear statement to both employers and your colleagues that you have attained a high standard in management and that you are theoretically capable of putting what you know into practice.

However, a PMP certificate is only theoretical because being a good project manager is not just about knowing what to do, it’s also about being able to communicate, motivate and delegate. Consequently, working hard on raising the bar on your interpersonal skills and your emotional intelligence will give you the practical ability to convey your PMP instructions effectively and instill in you the ability to be a true leader on your project.

Causes of IT Project Management Failure and Probable Solutions

Projects by nature are not systemic. They do not involve repetitive work and processes. Every project is unique and involves widespread team players. They have a fixed start and end schedule. This makes management and systemization all the more challenging. These challenges typically surround projects not being completed within the scheduled date, exceeding the budget and going out of scope. Various issues lead to an IT project failure.

Here we will focus on some of the major causes that lead to an IT project failure and try to provide solutions to them.

Inability to obtain information on time: In a fast paced environment, project managers may not be able to update the schedule as he might get busy with managing other project related problems and resource allocation. Resources are also shared across multiple projects. All of this leads to incomplete updating of the task schedule. Executives do not have visibility of the entire enterprise project. They are also not able to view the schedules real-time or view the project report. This makes the management incapable of re-directing effort or cancellation things go awry. Even the team members are unaware of the daily task or task priority if involved in multiple projects. Inability to obtain the most needed information at the right time by all the stakeholders (manager, management and team member) leads to confusion and poor visibility of project priorities. (1)

Poor resource allocation and team support: If the project manager allocated to handle a project does not have the correct level of competency required to handle the project, it is disaster-prone. Project managers are chosen on the basis of their availability. Lack of adequate support from all departments may also cause project failure. Team support is critical for project completion. Inability of the manager to establish task allocation, personal rewards, evaluation of personal contribution, and goal synchronization (team and project goals) may lead to poor collaboration for project success. (2)

Poor project requirements: Using poor requirement gathering techniques may mess up the project. Requirement gathering techniques include requirement elicitation through use cases, reports, interface, user screen design specification, etc. There are various details to be captured in the process of the requirement analysis stage. Poor requirement analysis can also lead to project creep in the future leading to cost and time overrun. Requirement analysis techniques should be strong enough for project scoping and delay prevention. Not gathering the correct set of details may lead to failure.

Unrealistic delivery schedule may further lead to poor requirement. Aiming to do excessive changes in a short time span, instead of realistic schedules for small and iterative delivery, can mess up a project too. (3)

Hence, instead of missing deadlines by providing an overoptimistic delivery schedule, it is best to make room for buffer and allot some extra time for handling last minute issues.

Improper Communication: Communication is extremely important for a project’s success. Lack of proper meeting and communication between various team members may lead to poor schedule maintenance and may not keep stakeholders on the same page. This may result in goal disorientation. Regular communication ensures the team goals and project goals are in sync with each other. Generally, emails are the norm for maintaining communication between various stakeholders. Many times, all members do not get covered in the information loop or miss out on a piece of information due to the sheer volume of information sharing involved. Precious time also gets lost when team members are sifting through heaps of mail.

Probable Solutions

1. A centralized, visible location of project schedules enables all major stakeholders to view project schedules (either in a network folder or an extranet solution having access permission rights set). Using enterprise project management software can come in handy for this purpose. It enables managing projects in a single database so team members can access database remotely if the project management software is web based. (4)

2. The business analysts should be well trained for being able to do the correct requirement analysis. (5)

It is essential to have clearly defined goals for projects to prevent scope change in the future. Good requirement analysis can lead to a well-defined project scope. Further project monitoring is required to ensure that the team is within scope. If project creep occurs, request changes should be analyzed to provide a fresh estimate of schedule and cost. There should be a system in place supporting and tracking the scope change This also assists in auditing performance before and after project completion.

3. Project manager with the correct competency set should be assigned to a project. From the very beginning, he/she should rope in the entire team to discuss project details and its importance. Discussion should center around project goals, individual contributions, evaluation mechanisms, and personal rewards on project success. Focus of the PM should be to synchronize individual and project goals.

4. A centralized communication channel should be established to facilitate communication between various stakeholders. A web based system or meeting software can be used for this purpose for project related task communication. The software can post all important project related information at one location. Centralized communication is helpful for clients trying to resolve questions and problems concerning projects – goals, scope, important steps achieved etc. (6)

5. It is always good to make use of software to automate project management and handling, but choice of software is also essential. All team members should be comfortable using it. Hence, effective training should be given to ensure proper utilization of project management software.


(3) Project-Skills. “Top 7 Reasons For Project Management Failure.” 2014. Project-Skills Website. 26 February 2015
(2, 5) Schiff, Jennifer L. “12 Common Project Management Mistakes–and How to Avoid Them.” 26 September 212. CIO Website. 26 February 2015
(1,4,6) West, Cynthia, K. “Four Common Reasons Why Projects Fail.” Project Insight Website. 26 February 2015