When it comes to Project Management, usually there are multiple stakeholders expecting different outputs from the project life-cycle. Therefore, it’s necessary to implement proper group-decision making techniques and methods. Especially this is important when different opinions clash and make conflicts with each other. In addition, these techniques / method may align with group creativity techniques when it’s required. (prior to the execution of group decision-making techniques)
According to PMBOK (5th Edition), there are 4 different group decision-making techniques that can be applied throughout the entire project life-cycle. They are as follows;
This decision making is defined when everyone participating in the decision-making process agrees on a single course of action. There are few methods that can be followed to achieve this. (E.g.: Delphi technique where group of experts respond to the questionnaire anonymously) Apart from that, this method is known to provide the least hassles on project management team in terms of implementing decision making techniques.
Majority relies on most number of votes towards a particular decision. (more than 50%) In order to make this technique more efficient, it’s recommended to have an uneven number of people in the decision making panel to avoid resulting in a tied decision.
This is a bit of complicated decision making technique and more challenging to understand. According to PMBOK (5th Edition), it is a decision reached by the largest block in a decision making panel though it’s not achieved the majority concept. This method is used when the nominated options are greater than 2, hence the option voted by the largest block of the decision making panel is agreed and confirmed.
This is known to be the least agreed method to be used among a decision making panel. When the project leader acts as a dictator, he / she is not willing to listen to others and coming up with their own decisions which will have a higher probability to drive the project towards failure. A dictator doesn’t allow to develop group creativity techniques. In addition, due to the dictatorship, the project lead should be accountable for any future conflicts arising within the project community and tasks.
There are several techniques been defined to follow when it comes to requirement gathering phase. (Source: PMBOK 5th Edition) Group Creativity Techniques are few of them. Under this concept, there are few methods mentioned for effective requirement gathering sessions. Few of them are as follows;
This is same as interviewing, but recommended to use when there are multiple stakeholders sharing multiple ideas with regards to project / product requirements. This is sometimes referred to as a conference techniques due to the participation of multiple stakeholders.
Nominal Group Technique
This method works with brainstorming as a joint process. Once the ideas are generated through a brainstorming session, the brought up ideas / requirements will be analyzed and prioritized based on their value using the nominal group technique.
This is known to be a method of reaching the consensus of subject matter experts (SME). The facilitator has to prepare a list of questions that need to be answered by SMEs and shared among them. Once the SMEs receive the questionnaire, they will answer based on their knowledge and experience and share their opinions with the facilitator. Through this technique, it reduces the bias in the information shared since this technique is mostly following the anonymous techniques where only the facilitator will receive the SME opinions.
Idea / Mind Mapping
Mind mapping is a technique which consolidates several opinions collected via brainstorming sessions from individuals and form a central opinion. This mapping view visualizes the different ideas and opinions carried by different stakeholders which follows different deviations from the centralized opinion.
This is another technique that goes toe-to-toe with brainstorming and nominal group techniques. It takes ideas from different individuals and group them under different categories for reviewing and analysis purposes.
Multi-criteria Decision Analysis
Multi-Criteria Decision Analysis technique assigns different criteria for requirement evaluation purpose and rank them with a weighted value. Once the requirements are gathered, they will be rated based on the weighted values assigned to each criteria. This technique is mostly used to evaluate risk levels, uncertainties, valuation and other ideas that can be ranked with regards to the weighted criterion value.
Interviews are Questions and Answers sessions that can be used for information elicitation purpose from stakeholders in when it comes to different project management activities. (E.g.: Requirement collection) An interview can either be formal or informal and it can be defined as one of the strongest and most efficient requirement gathering techniques in project management.
In order to follow a successful requirement gathering session via interviews, the project management team has to have a prepared set of questions and the response from the client needs to be noted down then and there. Most of the time, an interview is conducted between an interviewer and an interviewee, but there are certain situations where requirements will have to be grabbed from multiple stakeholders at once. In such scenarios, it’s recommended to conduct a brain storming session
When conducting interviews, it’s important to understand who to interview and what sort of questions to ask in order to gather / elicit requirements effectively. Especially, interviewing subject matter experts, experienced project participants and sponsors will help to identify the desired deliverables that need to be produced via the project life-cycle.
Enterprise Environmental Factors are used as inputs to project activities same as Organizational Process Assets. These factors are not under the control of the project team, in spite of being influential towards project direction. This influential factor may negatively or positively impact towards the project success, hence it’s project team’s responsibility to use them under all the project processes to ensure that project is guided and followed under the respective factors accordingly.
PMBOK 5th edition has stated different factors that are used in project activities. Few of them are as follows;
Culture, structure and the governing rules of the performing organization
External factors such as political and marketing conditions
Geographical situation, resources and available facilities
Industry / government standards and policies
Available human resources (skills, knowledge level, etc…)
Company working structure (authorization structure)
Stakeholder engagement (risk tolerance, culture and other behavioral patterns)
Available communication channels and management methodologies
Information databases (commercial, risk related, baselines, etc…)
Personnel authority and administration (staffing plans, employee retention methods, performance appraisals and reviews)
Project Management Information System (an automated tool to collect and share information related to projects)
According to PMBOK (5th Edition), Organizational Process Assets (OPA) are plans, processes, procedures and knowledge bases specific to a particular organization. Any artifact (formal or informal plans), practice (processes, policies, procedures), any knowledge base (lessons learned, historical information) from any stakeholder group can be included as an organizational process asset to govern or drive projects. Among the project knowledge areas, these process assets are considered as inputs to project activities and they are updated throughout the project life cycle whenever needed and necessary.
The organizational process assets are separated under 2 categories.
Processes and Procedures
Corporate Knowledge Base
Under processes and procedures, the organizational process assets are categorized as follows.
Initiation and Planning
Executing, Monitoring and Controlling
1. Guidelines and specific criteria for a given project
2. Standards and Policies (HR
Policies, health and safety,
quality policies, etc…)
3. Procedures (Process audits,
checklists, KPIs, etc…)
4. Templates (WBS, Risk register, contract templates, etc…)
1. Change control procedures
2. Financial documents
3. Quality, issues and defects related
4. Communication related documents
Corporate Knowledge Base consists of organizational process assets which includes various types of information related to projects that can be used for any project activity. Few of them are as follows; (Source: PMBOK 5th Edition)
Configuration management related info: (baselines, policies, procedures, standards, etc…)
Lessons learned and historical knowledge base (previous project records, project documents, contract documents, project performance related information, other knowledge areas related documents such as risk management, stakeholder management, communication management, etc…)
Expert Judgement is one of the best and very useful techniques used during most of the project management activities. It’s a common technique used throughout the project management processes (among the project management process groups) such as charter development, project management plan development, project execution, monitoring, controlling, closing, etc… It is applied to all the management and technical details whenever needed. When it comes to Project Management, experts are known to be internal or external assets an organization keeps to provide inputs for planning and estimating during planning processes. The experts are mostly needed when the project management team feels that their opinions are very crucial for the success of the project.
The method ‘Expert Judgement’ has a lot of positive outcomes when used properly at the planning phases in Project Management. Not only it saves time for planning and estimating projects, but also it highlights risks that can have an impact towards the project outcomes, hence coming up with a risk response plan will become much easier for the project management team. In addition, the quality and accuracy of the estimations and planning phases become much greater. Most of the projects fail due to inaccurate estimations and less efficient risk management planning, hence it’s always recommended to go for expert judgement when developing the estimates and risk identification process.
Experts do have their own specialized knowledge, training and skills which can be used for different areas. These experts can either be a group or an individual and it’s project management team’s responsibility to identify and select the correct expert for necessary activities.
Experts can be available from many different sources. Few of them are as follows; (Source: PMBOK 5th Edition)
Within the same organization, but from different business units
Internal / External Consultants
Internal / External project stakeholder (it can be customer or sponsor as well)
Subject Matter Experts (SMEs)
Professional and Technical Associations
Other Industry Groups
Project Management Office (Even among the project managers, there can be subject matter experts who can act as Experts for projects)
Project Status – High level Summary (Project High level View) can be used to obtain a quick snapshot of the list of projects a particular Project Manager is handling. Mostly, this template is better to be used for your own reference in order to do a quick check-list view to see which project working on which module, who is responsible and the current status of that particular project. (Not recommended to present at the top management / director board meetings). The template can be downloaded using the below URL.
When it comes to agile methodology, both the vendor and the customer have to come for an agreed agile contract type prior to the execution of the project. Since agile is defined to be embracing changes, it’s difficult to establish a contract. Both parties are supposed to cooperate with each other in order to deliver value adding features throughout the entire project life-cycle. (The relationship between the customer and the vendor in agile methodology has been defined and stated under ‘Agile Manifesto Principles‘ and ‘Agile Manifesto Values‘) There are few agile contract types defined to be used based on few factors such as the relationship strength between the customer and vendor, etc…
Even though embracing changes has made it difficult for both parties to sign an agreement, there are few contract types that still both parties can agree upon prior to the project execution.
Fixed price, Fixed scope (Fixed time is also preferred)
Under this contract, an agreed budget with a fixed scope is provided (Just like in waterfall). By using agile techniques, project efficiency can be enhanced in order to gain maximum benefits out of the agreed price. This contract is good to use when requirements are stable and the relationship between the customer and the vendor is not stable (Not trusting each other).
Fixed price, Fixed scope (Fixed time is also preferred, but scope can be altered by collaborating with the customer)
The project team works closely with the customer from the beginning to identify the project requirements and priorities. Once the project is started, the project management team has to work on a prioritized list and at the end of a delivery, both parties can discuss whether to change the project direction based on the user needs.
Time and Material
According to this contract, customer has to pay for the work being done. This method / type works better when requirements are not stable / volatile. This is the simplest contract to be signed off if both parties trust each other.
Not To Exceed with Fixed Fee (NTE/FF)
Here, the vendor team is promised with a guaranteed profit margin. Both parties protect each other with the speed of project work being executed (Faster or Slower) and work on unexpected events to drive the project towards success.
Fixed price per function / story point
Initially both parties must agree on the unit of delivery (story points / functions / function points). A fixed price per unit is agreed and a certified functional point auditor is selected and advised to observe the number of units delivered at the end of the project. The customer has the freedom to change the requirement throughout the project and the vendor is encouraged to work efficiently.