|
|
Conflict Management
Take a look at the following scenarios:
===============================================================
Project Sponsor: We need to have Version 3 ready to display at a trade show in May.
Project Manager: That is not possible. Our estimates show that the earliest we can release the product is the second week of July.
===============================================================
Team Lead to the member: I see that you are coding your own functions. Let us use only those that are available in the standard library. That will make our code more standard and easier to maintain.
Team Member: But I cannot change my functions now. That will involve a lot of rework. Moreover, didn’t you tell me at the start that I can use my own development methodology?
===============================================================
Project Manager: We cannot ship the product, since the performance testing has not been done yet. That is a critical success factor for this project.
Marketing Manager: I understand, but this customer has most advanced servers in terms of processing abilities, so performance will not be an issue. Moreover, competitors are closing in, so we have to close the deal fast.
===============================================================
Technical Lead: The IT Manager says she will not share any test servers for our team, although we were supposed to get 3 for our project for this week. Now we are stuck.
Project Manager: Why, what happened?
Technical Lead: She is obviously irritated that the request for servers was sent by you. She generally gets them from the Department Head.
===============================================================
Project Manger: You have committed the System Architect to my project. How can you refuse now?
Functional Manager: Yes, I had. But the priorities for the senior management have changed. He will be working on the Web development project we bagged last week.
===============================================================
Sound familiar? These are some of the most common stalemates that occur during most projects. A situation that hinders the progress of a project that everyone believed was progressing smoothly. Until this happened. Each of these scenarios is what we call a conflict.
What is a conflict?
In simplest terms, conflict is a situation where one party blocks or at least delays another party in attaining its objectives. Conflicts are a way of life in a project structure and mostly unavoidable. There are conflicts with positive consequences, where they produce new information that may actually speed up the decision-making process. But mostly, conflicts result in project delays and hence it is imperative that such conflicts are dealt with sound decision-making.
The Project Manager is the pivotal role in the context of a project and generally also has the authority to deal with such conflicts. Hence one of the key competencies of a Project Manager is to have good conflict handling skills.
H. J. Thamhain and D. L. Wilemon conducted a survey of 150 Project Managers and the way they manage conflicts and published the result of the survey in 1975. The focus was on to:
1. Identify the types of conflicts in a project
2. Conflict handling techniques used by Project Managers
3. Recommendations in conflict handling at various stages of a project for various conflict types.
Types of conflicts
The study revealed that there were 7 major types of conflicts that can occur during a project.
• Conflict over project priorities.
• Conflict over administrative procedures.
• Conflict over technical opinions and performance trade-offs.
• Conflict over manpower resources.
• Conflict over cost.
• Conflict over schedules.
• Personality conflict.
While personality conflicts are the most obvious of all, disagreements over schedules result in the most intense conflict over the duration of a project. Scheduling conflicts often occur with other support departments over which the project manager may have little authority. For example, an issue urgent to the project manager may receive a low-priority treatment from support groups because of a different priority structure in the support groups.
The mean intensity experienced for each of the potential conflict sources over the entire life of projects is presented in Figure 1.
Fig 1: The mean intensity of conflicts over the duration of a project
Organization-wide policy changes affect the project priorities, the second-ranking project conflict. One project may have a high priority when it was forecasted, but some other project comes over with a higher priority and may cause an impact on the availability of resources and schedules.
Similarly, there are caused for the rest of the conflicts as well. However, it has been observed that most of the other conflicts (expect cost) are within the domain of the project and hence the project manager has a better control over it.
Conflict-Handling Techniques
A number of research studies indicate that managers approach and resolve conflicts by utilizing various conflict resolution modes. The five most commonly used techniques are:
• Withdrawal. Retreating or withdrawing from an actual or potential disagreement. This actually does little to resolve the conflict and should not be used.
• Smoothing. De-emphasizing or avoiding areas of difference and emphasizing areas of agreement. This also does not help to solve the difference, but only creates a depiction that everything is okay.
• Compromising. Bargaining and searching for solutions that bring some degree of satisfaction to the parties in a dispute. Characterized by a "give-and-take" attitude.
• Forcing. Exerting one's viewpoint at the potential expense of another. Often characterized by competitiveness and a win-lose situation. Managers with some authority can use this as a last resort of break the deadlock.
• Confrontation. Facing the conflict directly, which involves a problem-solving approach whereby affected parties work through their disagreements. While this time and resource consuming, this is often the most recommended technique, as it helps in reaching the root cause of the conflict. A confrontation also offers a long-lasting solution.
It is for the project manager to use his judgement and use the most relevant conflict-handling technique. Every situation is different from the other and no technique is universally and eternally applicable. The same survey ranked the techniques in the order of preference by the project managers as follows:
1. Confrontation: 70%
2. Compromising: 45%
3. Smoothing: 40%
4. Forcing: 30%
5. Withdrawal: 20%
The project managers were also asked to list their recommendations to avoid conflicts during the four phases of a typical project: Initiation, Planning, Execution & Control and Closeout. Figure 2 lists the most common recommendations for the most common types of conflicts that may occur during that respective stage.
Fig 2: Recommendation for Conflict handling during different project stages
A project manager has to realize that the conflicts in a project are inevitable. Instead of running away from them, what is required is that the project manager faces them to the extent and applies the best conflict resolution technique possible for the situation.
References
1. H. J. Thamhain and D. L. Wilemon, ''Conflict Management in Project-Oriented Work Environments”
2. Harold Kerzner, “Project Management: A Systems Approach to Planning, Scheduling and Controlling”; 7th Ed.
The role of a Business Analyst Posted on 2nd July, 2007 All projects are driven by requirements. Whether it is an existing system undergoing an upgrade or a new development, requirements establish the features of the system. Requirements can be of various types (business, functional, user, quality, system, etc) and are intended to meet the needs of all stakeholders.
A careful study of major requirements for any new project would reveal that the stakeholders who influence these requirements represent various areas of business - organization, senior management, customer, end users, project team, etc. Needless to say, all these stakeholders have varying objectives and expectations from the project and could often be conflicting in nature.
The success of a project therefore, depends largely on how well these requirements are analyzed using various techniques and are aligned with the business needs of all the stakeholders. The project manager, though responsible for managing stakeholder expectations, may not be proficient in analyzing these requirements. Therefore, a Business Analyst can be a key project team member, who would use experience, knowledge and various techniques to identify these business needs and determine solutions for them.
According to the Business Analysis Body of Knowledge (v1.6), a business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.
The business analyst is primarily responsible for identifying new business opportunities and organizational needs for new systems and solutions. Also, defining these opportunities and performing an initial feasibility study and risk assessment are the elements that the business analyst has to perform. Once there is an approval for undertaking a project to convert these identified opportunities into solutions, the business analyst also plays a crucial role in the project. Following are the stages of a business analysis cycle for a project:
Planning – Here, the business analyst and the project manager work on developing a strategy for identifying key roles, selecting requirements activities, managing the requirements scope and ongoing communication of the requirements status.
Configuration – This ensures that the requirements are unambiguous, concise, complete and consistent. However at this stage, the requirements are still in an unrefined state, i.e. they do not describe how the feature underlying the requirement will be met.
Analysis – This involves use of knowledge and various techniques to describe the characteristics of the system and the solution. This is similar to writing the specifications for the requirements and specifying the ‘how’ part of them. At the end of this stage, the requirements are communicated to all the stakeholders so that there is a common understanding among all stakeholders and they are in agreement with the specifications.
Validation – As the construction part begins, the project is divided into multiple milestones, with certain deliverables assigned to each milestone. The business analyst reviews all the deliverables, assures the quality of the system that has been built and ensures that the solution developed meets the defined needs.
Thus, it is clear that a business analyst has a clear and responsible role not only within the life-cycle of the project, but also in identifying the business opportunities that improve an organization’s business processes. Thus it is a vital role for the organization and the person filling in this role needs to have very sound knowledge of the business processes and understanding of the business problems and opportunities.
Requirements - Threat or Opportunity?
Posted on 23rd May, 2007 Either it is for an Applications and Services organization or for a Products Development organization, requirements are the drivers to successful completion of the projects that develop these applications, services or products. The significance of the requirements is so significant because requirements provide the basis for all of the follow-on activities in the project. Surprisingly, the requirements management is still one of the areas in software engineering that draws least attention in the entire development cycle. Considering that requirements errors are the largest category of errors in a project justifies spending more time and effort on the requirements management process.
ProgressionThere is a difference in the life-cycles of a typical application development and a product development cycle. In case of an application development, the requirements come from a customer (external to the organization or internal, within). The project manager is identified, the project is chartered, project team is formulated and the solution is developed and shipped to the customer. The product development cycle extends further in the sense that the requirements collection process continues even after the product has been released and these are incorporated in the next version of the product. In either case, the project manager and/or a business analyst goes through the requirements, interpret them and come out with a set of specifications that define how each requirements would be addressed by the development team.
Issues arising due to poor requirements
Therein lies the real problem. Studies have shown that the involvement of the customer at this stage of requirements analysis is less than what it should be; and often leads to most requirements related issues. These are some of the major reasons why requirements can be real project-killers:
• Requirements are not clearly stated or are incorrectly stated
• Missing requirements
• Requirements are not interpreted correctly
• Customers change the requirements too frequently
Also, according to Dr. Ralph Young, the author of The Requirements Engineering Handbook, there is a huge difference between customer’s real needs and the stated needs. The customers all over do not have a history of expressing their needs and requirements in a clear form and unfortunately this is not going to change over time. It is the challenge for the project manager (or a specialist requirements analyst) to extract the requirements in the customer’s mind and convert them into a compatible form, so that they can be developed to meet the business needs of the customer. The fact that there could be too many such stakeholders feeding the requirements makes it even more complex. Real challenge, isn’t it?
Benefits of good requirements
There are obvious benefits of effective management of requirements. Good requirements management leads to:
• reduced time to finish the development process
• no cost overruns
• less rework
• better quality control
For products companies who operate in a competitive environment, these benefits mean a distinct advantage over the competition as the product can be shipped on time and within budgets.
Best practices for requirements management
What would ensure that a good requirements practice is established? According to Dr. Young, following processes would help in creating such a practice:
1. An atmosphere of cooperation and collegial problem solving among the project stakeholders is to be created at the beginning of the project and maintained throughout its performance period.
2. Create a joint team of people possessing knowledge of the customer requirements with the authority to make decisions concerning requirements on behalf of the project.
3. Identify the real customer needs as against the stated needs.
4. Establish a documented requirements process, always use it and continuously improve it
5. Iterate the requirements throughout the life of the project cycle, since they are never finalized and typically, there are extensive refinements and changes to the requirements as development proceeds.
6. Put in place an effective change management process that has been agreed upon by all stakeholders. Verify all requirement changes.
7. Communicate the consequences of a requirements change to all stakeholders.
8. Use best practices of project management proven across the industry, organization and projects.
9. Allocate a certain percent of the total project cost (typically 8 – 14%) to requirements management.
10. Ensure that there is a buy-in from the senior management to the process and allocates the necessary resources to support it.
These steps would ensure that the project follows a proven, efficient process to keep requirements despondency in control and lead to a successful project and meets the triple constraints of the development – cost, time and scope – and maintaining the overall quality as committed by the organization in its policies.
References
1. The Requirements Engineering Handbook by Dr. Ralph R. Young.
2. Requirements – Pandora’s Box for Project Managers By Frank P. Saladis, PMP
Essential Soft-skills for a Project Manager Posted on 22nd May, 2007
During my quest for a new job, I came across many such organizations who expected the Project Managers to have a technical background i.e. they expected the PM to have an experience in the technology that the project is based on. The skills were necessary, according to some of these, so that the PM has a better understanding of the overall status of the project and also so that he can do code reviews. Of course, other ‘essential’ Project Management skills such as experience in estimation techniques, risk management, quality processes and knowledge of tools such as MS Project were also desired.
Surprisingly, very few of these were interested in the soft-skills, also known as the people skills, of the candidate, as profiled by them. Although they stated in their advertisements such attributes, hardly anybody stressed on them as much as they highlighted the technical skills of the candidate.
Is it enough for the Project Manager to have technical skills alone? Can he survive and succeed solely based on these skills? I am sure the answer would be negative. For a Project Manager to succeed, there has to be a blend of technical skills, knowledge of Project Management Methodologies and the soft-skills.
What are soft-skills?
So, what are these soft-skills that a Project Manager must have? Communication skills, Leadership / Team Building, Motivating, Handling Conflicts, are some of these skills that a Project Manager should possess and more importantly, use them throughout the project duration, as required.
It is absolutely necessary that a Project Manager has a people (i.e. Team) perspective to his project and should be capable of viewing the project from other’s standpoint to get a multi-angled view of the project.
Why are they needed?
Often, a project team is formed for the duration of the project – during which the members are reporting to the Project Manager – and then go back to their respective functional managers. This is where their real allegiance is; and as such they are not always in command of the Project Manager. It is possible that their own ideas of the project schedule are not aligned to the schedule of the Project Manager (in fact, it is often seen that the Project Manager’s schedule itself not his own, but driven by management directives, but that is a different story altogether) and hence they tend to resist the schedule and try to push their own.
This is where the real Project Manager’s soft skills come handy – he has to motivate his team in such situations and ensure their cooperation and contribution to the project.
The various stakeholders in a project have their own agendas for the project. Therefore, it is possible that midway through the project, while some stakeholders may feel the project to be in sync with the plan and baseline, some others may have entirely opposite opinion. A Project Manager’s communication skills are tested in such situations, when he has to ensure that the stakeholders would view the project from his perspective and would take his word for the project health.
A cohesive and cooperative atmosphere within the project team is a must for the project to succeed. The reason why this may not always be possible is because the team members of the project may come from different departments and strata within the organization and may not have worked together in the past. Projects often fail due to inter-personal issues, particularly if the people or the departments have a history of antagonism. A Project Manger has to use his Team Building skills to make sure that every member of the team is aware of his or her responsibilities and adhere to them. All communication should flow through the manager and should not bypass him, so that he can sense any such inter-personal issues. He needs to be good in conflict-resolution skills, so that if at all such issues arise, he has a handle on them and can resolve them, without affecting the project schedule and team morale.
How to acquire them?
While these are only a few examples where a Project Manager’s soft-skills would bring the project out of any turbulences, there could be countless such scenes during the life of the project that could de-rail it.
However, a Project Manager is a human being and has his own nature. While some people are introverts and may not mix up with people, there are others who are social animals. This can have a big influence on a Project Manager’s soft skills and hence it is extremely important that he is aware of the soft-skills that he must possess in his capacity in leading a project to success.
For this, he should be able to view the project from other people’s perspective. He should learn to put himself in other people’s shoes and analyze the situation from an angle very different from his own. He can also put in place a mechanism of getting feedback about his own performance from the other stakeholders, though it may not be so overt for them to notice.
Unfortunately, organizations spend very little of their training budgets on developing these soft-skills compared to what they spend in acquiring technical skills. Hence it is paramount for a Project Manager to look at avenues of developing these skills on his own, expecting very little from such trainings. A realization of the significance of these skills itself is enough for him to look at ways of acquiring them.
- Sameer Iyer, PMP
|
|