top

Search

The Impact Of The Scrum Master’s Personality On Team Success

The personality of a person is a combination of characteristics of a person including behaviors, habits, thoughts, emotions, feelings perceptions, etc. which helps identify him or her distinctively. These characteristics spring up, develop and evolve from factors within the person as well as factors from the environment or context in which the individual operates. Personality comes from within a person and it will determine how the person thinks, feels and behaves. Personality normally remains similar throughout the lifetime of the individual but can be trained to make certain changes in personality.The Scrum Master plays an important role directly impacting the success of an Agile Scrum project. The Agile Alliance defines a Scrum Master as ‘the team role responsible for ensuring that the Scrum team lives Agile values and principles and follows the processes and practices that the team agreed to use in the project’. The scrum master is the owner of the scrum process where he or she is responsible for defining the process to be adopted by the team. He is expected to protect the team from internal and external influences and dependencies and be able to facilitate negotiation sessions in situations of conflict. The scrum master is not a manager but a ‘servant leader’ of the team working with the team to achieve the goals and objectives of the project. The scrum master is also responsible for facilitating the scrum ceremonies driving the project forward by overcoming impediments encountered on a day-to-day basis.Personality of the Scrum MasterThe scrum master’s personality plays a pivotal role when achieving the responsibilities listed above. The following is an attempt to discuss the impact of scrum master’s personality on team success based on the ‘Big 5 personality traits’. These personality traits are as listed below.Watch the video from the link below to learn more about the 5 personality traits.Having a scrum master who is outgoing and energetic or in other words, an extrovert will be beneficial for the project as opposed to having a reserved, socially aloof scrum master. The scrum master is expected to build positive relationships with both internal and external stakeholders and be able to create a positive vibe when the going gets tough. A scrum master who is an extrovert would walk the extra mile with the team for the betterment of the team by collaborating and communicating with stakeholders.The scrum master must be friendly and compassionate as opposed to being detached from his or her team members. In other words, it is good for a scrum master to have the personality trait of agreeableness. The scrum master must be able to listen to stakeholders with empathy, understand the real context, and be trustworthy and helpful without getting into arguments or preconceptions. This personality trait of a scrum master would also ensure that team members are well protected from external threats and will ensure the interests of team members and other project stakeholders are met.Agile teams are expected to be innovative and think out of the box. It is beneficial for a team to have a scrum master who is curious and open to an experience. Scrum teams learn from mistakes and are often open to try out new things. A good scrum master would be able to facilitate this process by encouraging the team members to try out new things both in the project as well as in the solution being developed.Scrum teams are expected to be self-organised and efficient. A scrum master with these characteristics will be organised in executing the scrum process applicable to the project in an efficient manner. A conscientious scrum master will ensure that scrum meetings are well organised, properly facilitated, outcome-oriented and purposeful. Meeting invites, agendas will be clearly defined with each stakeholder kept true to the agenda. An organised scrum master will also make sure that enough documentation is done in an organised manner may it be with regards to requirements, project management, design, quality assurance etc.Scrum masters must be emotionally stable and capable of controlling sudden anger or stress. A good scrum master must be able to conceptualize and think logically while considering the bigger picture rather than being overwhelmed by emotions. In a team environment, the scrum master will need to deal with people with different personalities that can have a positive or negative impact on the project. A secure and confident scrum master will be confident about his/her own capabilities as well as the capabilities of the team members and be able to motivate the team members to overcome any situation.Finally…Personality plays an important role in a team environment. The personality of the scrum master or the leader of the team is essential to make sure of the resources and to mold the team into a victorious team. What type of a scrum master are you? Do you have the aforementioned personalities within you?
The Impact Of The Scrum Master’s Personality On Team Success
Rumesh
Rated 4.0/5 based on 54 customer reviews
Rumesh

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Rumesh Wijetunge Articles

The Impact Of The Scrum Master’s Personality On Team Success

The personality of a person is a combination of characteristics of a person including behaviors, habits, thoughts, emotions, feelings perceptions, etc. which helps identify him or her distinctively. These characteristics spring up, develop and evolve from factors within the person as well as factors from the environment or context in which the individual operates. Personality comes from within a person and it will determine how the person thinks, feels and behaves. Personality normally remains similar throughout the lifetime of the individual but can be trained to make certain changes in personality.The Scrum Master plays an important role directly impacting the success of an Agile Scrum project. The Agile Alliance defines a Scrum Master as ‘the team role responsible for ensuring that the Scrum team lives Agile values and principles and follows the processes and practices that the team agreed to use in the project’. The scrum master is the owner of the scrum process where he or she is responsible for defining the process to be adopted by the team. He is expected to protect the team from internal and external influences and dependencies and be able to facilitate negotiation sessions in situations of conflict. The scrum master is not a manager but a ‘servant leader’ of the team working with the team to achieve the goals and objectives of the project. The scrum master is also responsible for facilitating the scrum ceremonies driving the project forward by overcoming impediments encountered on a day-to-day basis.Personality of the Scrum MasterThe scrum master’s personality plays a pivotal role when achieving the responsibilities listed above. The following is an attempt to discuss the impact of scrum master’s personality on team success based on the ‘Big 5 personality traits’. These personality traits are as listed below.Watch the video from the link below to learn more about the 5 personality traits.Having a scrum master who is outgoing and energetic or in other words, an extrovert will be beneficial for the project as opposed to having a reserved, socially aloof scrum master. The scrum master is expected to build positive relationships with both internal and external stakeholders and be able to create a positive vibe when the going gets tough. A scrum master who is an extrovert would walk the extra mile with the team for the betterment of the team by collaborating and communicating with stakeholders.The scrum master must be friendly and compassionate as opposed to being detached from his or her team members. In other words, it is good for a scrum master to have the personality trait of agreeableness. The scrum master must be able to listen to stakeholders with empathy, understand the real context, and be trustworthy and helpful without getting into arguments or preconceptions. This personality trait of a scrum master would also ensure that team members are well protected from external threats and will ensure the interests of team members and other project stakeholders are met.Agile teams are expected to be innovative and think out of the box. It is beneficial for a team to have a scrum master who is curious and open to an experience. Scrum teams learn from mistakes and are often open to try out new things. A good scrum master would be able to facilitate this process by encouraging the team members to try out new things both in the project as well as in the solution being developed.Scrum teams are expected to be self-organised and efficient. A scrum master with these characteristics will be organised in executing the scrum process applicable to the project in an efficient manner. A conscientious scrum master will ensure that scrum meetings are well organised, properly facilitated, outcome-oriented and purposeful. Meeting invites, agendas will be clearly defined with each stakeholder kept true to the agenda. An organised scrum master will also make sure that enough documentation is done in an organised manner may it be with regards to requirements, project management, design, quality assurance etc.Scrum masters must be emotionally stable and capable of controlling sudden anger or stress. A good scrum master must be able to conceptualize and think logically while considering the bigger picture rather than being overwhelmed by emotions. In a team environment, the scrum master will need to deal with people with different personalities that can have a positive or negative impact on the project. A secure and confident scrum master will be confident about his/her own capabilities as well as the capabilities of the team members and be able to motivate the team members to overcome any situation.Finally…Personality plays an important role in a team environment. The personality of the scrum master or the leader of the team is essential to make sure of the resources and to mold the team into a victorious team. What type of a scrum master are you? Do you have the aforementioned personalities within you?
The Impact Of The Scrum Master’s Personality On Team Success
Author Image
Rated 4.0/5 based on 54 customer reviews
The Impact Of The Scrum Master’s Personality On ...

The personality of a person is a combination of characteristics of a p... Read More

The Importance Of Following Up On Meetings

An important aspect of any project is the different types of meetings held between internal stakeholders and with external stakeholders. This is especially true for Agile teams. The formality, frequency, timing, and length of meetings vary based on the project management approach, project life-cycle stage, purpose, and importance of meeting among many other criteria.  For example, in plan-driven projects, a more formal progress review meeting may be held among key decision makers once a fortnight whereas team members may sync-up on a daily basis to discuss issues.  One important output or ‘work product’ from meetings is the minutes of meeting. The minutes of meeting must contain details about the meeting, list of participants and apologies, list of points discussed, action items along with assignees and due dates. There may be instances where individuals who were not present at the meeting getting action items allocated to them without their consent simply as a result of their area of expertise though it is not ethically right. Documenting meeting minutes and setting up an action plan alone does not suffice to move things forward. Progress on discussion points and action items depends on what happens after the meeting once the participants go back to their desks. The participants get immersed in their day-to-day tasks resulting in the action items getting deprioritized down on their to-do lists or even slipping out of them. The action owners get busy with personal and professional tasks, the context in which they operate in changes, new tasks come up and priorities change resulting in executing the action items getting delayed.  It is the project manager’s responsibility to make sure that everyone attending the meeting understands the importance of the action items taken and are aligned towards a common objective. It is important to clearly define the expectations of each action item with a clear description of the expected outcome, dates for completion along with the responsibilities. The participant buy-in for the decisions, once these are agreed upon,is imperative. Once the meeting is over, the scribe must send out the meeting minutes summarized in one single page within an hour or two. This will ensure that action items are fresh in the minds of the participants allowing them to clarify doubts, request for changes and plan how they are going to execute the action items. The project manager must ensure the action items get worked on. Constant follow-ups are essential without waiting till the next meeting to discuss progress. The project manager must facilitate further discussions if necessary, organize meetings as necessary and ensure necessary coordination among dependent stakeholders to get the work done. Learn more about the different ways to improve your daily standup. In a plan-driven project, the project manager can create a task list and keep ticking off the progress on a daily basis.  Daily updates to the action item indicating the amount of work completed will help the project manager gauge whether work is on track. Setting a target is imperative, as it will keep the team motivated to achieve it. It does not mean that the task owner must be micro-managed but it is just to ensure that a sense of ownership is given to the individual. It will also make sure that the task owner or the team gets satisfaction even if they complete 70% to 80% of the task even though they are unable to achieve perfection.   My scrum meeting status: What I did yesterday: This meeting What I'm doing today: This meeting Impediments in my way: This meeting — Chet Haase (@chethaase) March 28, 2017 Tracking progress will also allow the project manager deal with non-performance.  The project manager must be compassionate and understanding. The difficulties associated with doing the tasks could be identified early on allowing for productive communication among the relevant parties. Risks of potential non-completion of tasks can be identified early on allowing the project manager to take necessary corrective action and keep the relevant key stakeholders informed. This will thus allow for effective problem solving and decision making to put things back on track. It is also good to have checkpoint meetings involving all team members just to keep everyone involved in the progress. Ideally, such a meeting should be held during the middle of the iteration and will give the team ample space to discuss issues they are facing. It is the responsibility of the project manager to keep track of the progress of action items, facilitate communication among relevant stakeholders and in ensuring everyone is constantly reminded and ‘on-the-ball’ in terms of moving action items forward.  Learn more about how the daily meetings and stand-ups in Agile teams are more than just status meetings here.    The success of a project depends on the small things each team member does to pull the project forward. Work products and action items when executed create the deliverables of the project. One small step taken at a time helps the team achieve project success. An effective follow up of meetings help project managers manage time, cost and scope of the project better thus enabling him or her to deliver the project successfully.  
The Importance Of Following Up On Meetings
Author Image
Rated 3.0/5 based on 0 customer reviews
The Importance Of Following Up On Meetings

An important aspect of any project is the different types of meetings ... Read More

Self-Healing In Scrum – Role Of The Implementation Team

A scrum implementation team is expected to be self-organizing and self-healing. The concept of self-organizing is often discussed whereas self-healing is seldom debated. The scrum implementation team themselves plays a pivotal role in becoming self-healing and this article intends to explore the same. The Scrum Team An Agile Scrum team consists of the Product Owner, Scrum Master, and the Implementation Team. Though there is no prescriptive standard size for a scrum team the latest Scrum Guide suggests that the team should be of size 6 +/- 3. This means that a scrum team may have a team ranging from 3 to 9 members.  As we know the Product Owner though part of the scrum team will most probably be external to the implementation organization. There will be instances where a proxy product owner (typically a business analyst) is assigned in which case that individual may also be part of the internal team. The Scrum Master should be from the implementation organization most often with development and definitely with leadership capabilities. Thus the implementation team may consist of business analysts, UI / UX designers, Software coders and QA engineers at different levels of experience. Today, having a DevOps or SysOps engineer who can ensure Continuous Integration and Continuous Delivery (CI / CD) has almost become the norm and will add muscle to the team to enable quick and quality delivery. What is meant by self-healing? Project teams face problems or issues on a day-to-day basis during the lifetime of the project.  These problems may become blockers hindering project progress if not addressed as soon as they come up. Agile teams focus on solving problems with a really quick turnaround time. Traditional project teams often depend on advise or assistance of an external stakeholder to make decisions when faced with a problem. In projects following predictive approaches, a more formal problem solving and decision-making process may be in place that may further delay timelines.  Issues most commonly seen in projects are to do with resource constraints, requirements or scope related queries, quality related issues to name a few. A lot of these problems can be solved through a bit of discussion and negotiation among the team members.  Agile teams are empowered to find ways of taking the project forward. Since the team is small in size and as team members know each other and their capabilities well it is possible for them to have fruitful discussions to solve problems. The team within them trying to find solutions for the problems faced through dialogue, negotiation, and collaboration is thus known as the self-healing nature of an agile team. Product owner role in Scrum maximizes value out of a feature team, project managers finds best project implementation to deploy that value — Beatric Düring (@bea73) April 6, 2011   How can implementation teams ensure that they are more self-healing? The Scrum Master is different from a Project Manager and is expected to play more of a servant leader, protector and facilitator type of a role within the project. Thus the project manager is not a taskmaster but a problem solver guiding the team in achieving the goals. This article is not about the Scrum Master’s role in ensuring self-healing! Collaboration Team members must ensure that whenever problems are encountered, they quickly raise it with the relevant parties. Agile team members must not sit on problems or dwell on the problem, but quickly move on to the stage of identifying the root cause of the problem and to identifying solutions for the same. This can be done through proper communication and collaboration among team members. The team members must be open to discuss even sensitive problems and be honest in receiving or providing comments. Collaboration will help generate solution options (especially through techniques such as brainstorming and mind mapping) that can be further evaluated to determine a logical course of action. The key advice here is, ‘Don’t keep anything on your to-do list for long if you can’t handle it alone. Share it! Telling the problem to someone is often half the solution solved.’ Cross-Functional Teams Agile teams are cross-functional with team members expected to be capable of or be willing to take up challenges. This characteristic most often ensures that there is always someone within the team with the required capability to tackle the problem.   Inquisitiveness  One important trait of a self-healing team member is the willingness to challenge the status quo and to question at all times. The simple process of asking ‘why’ would enable teams to drill down on problems. The inquisitiveness to compare solution options, try them out without any fear of failure means that Agile teams are always willing to learn and improve. This is a key characteristic of a growing and ever improving team. Document findings and apply lessons learnt A good team never repeats the same mistake twice! For a team to be self-dependent they must have sources to which they could refer back. The only way this could be done is by documenting ‘lessons learnt’ from previous experiences. These would then become guidance for the team whenever they face similar problems in the future.  Hence, it is the responsibility of every agile team member to do proper documentation to a level that is necessary. Conclusion The success of an Agile project depends on the team and on how well they could cope up with problems on their own. A self-healing team would drastically cut down on time depending on information and guidance from others. Every Scrum team must aspire to be such a team.  
Self-Healing In Scrum – Role Of The Implementation Team
Author Image
Rated 3.5/5 based on 2 customer reviews
Self-Healing In Scrum – Role Of The Implementati...

A scrum implementation team is expected to be self-organizing and self... Read More

Identifying, Tracking and Validating Assumptions

The primary role of a business analyst in a project is to elicit, analyze and document requirements related to the solution being developed. Business Analysts thus get immersed in requirements spending a bulk of their time in a project on requirements management related tasks.  Requirements as per the BABOK® are of 4 main types namely, Business Requirements, Stakeholder Requirements, Solution Requirements and Transition Requirements. The business analyst primarily focuses on getting the functional and non-functional requirements of the solution right as those types of requirements create the highest amount of value for the stakeholders. The effect from the context Businesses operate within a certain context. The context consists of the external and internal environment with different interacting entities each with different requirements, interests and impact levels. The context thus creates limitations in various forms and creates problems or opportunities to be addressed through solutions. The problems or opportunities are the actual needs of the business that needs to be satisfied.   The business context is complex with a lot of turmoil and undergoes constant change. This uncertainty results in difficulties with regards to eliciting, analyzing and documenting the exact need. Information required may not be accurate, complete and even not readily available resulting in the BA having to make appropriate ‘assumptions’. What are Assumptions? The BABOK® defines Assumptions as factors that are believed to be true but are not confirmed yet.  The business analyst is responsible for identifying and managing product-related assumptions whereas the project manager is responsible for the project-related assumptions. The Business Analyst must identify all assumptions that may have even a minuscule amount of impact on the product.  Working with the unknown Part of the business analyst’s role is to work with unknowns. It is an intriguing role and at the same time can be a nightmare. The BA must first list down these unknowns as assumptions, track them and manage them when these loose ends become clear. Assumptions when becoming clear might impact even the entire solution. It is the business analyst’s responsibility to manage this progress ensuring that business objectives are being met. Numerous case studies have established that Certified Business Analysis Professionals are capable of handling the end-to-end processes pertaining to managing assumptions and analysing their impacts.  With time when more requirements are elicited, analyzed, modeled and documented and when more stakeholders get involved in clarifying doubts these placeholders called assumptions may become an actual requirement in the solution. The solution evolves as and when assumptions become clearer.  How to better identify and manage assumptions? Identifying assumptions is a challenge. There are no proven methods for identifying assumptions and mostly it is to do with the intuition and experience of the business analyst. The BA must think out-of-the-box to identify all possible scenarios thus working towards identifying as many assumptions as possible. For example, a business analyst with domain expertise will be able to quickly identify assumptions pertaining to a solution being developed for the banking and finance domain. These assumptions even may be with regards to functionality, business or validation rules. Another great way to identify assumptions is through reverse engineering. The business analyst in collaboration with the development and QA teams can study the solution designs, code and test cases to identify great assumptions that may end up being important and cool features of the solution. For example, the latest technology trends of mobility, Robotics, IoT etc provide great opportunities for innovation. These may start off as high-level assumptions but end up becoming a groundbreaking feature in the future. The Business Analyst must document assumptions along with the associated attributes. These attributes include identified date, owner, impact, associated risk and any other information. Assumptions most often will accompany functional or non-functional requirements. It is thus important to clearly document the dependencies so that future impact can be properly managed. The business analyst must closely manage assumptions primarily with regards to the potential risk and the possible impact it poses. Assumptions carrying high risk with high impact must be closely monitored with moderate to low risk and impact items being managed less diligently. The BA must periodically assess each assumption and check whether it is still valid and whether it is still in line with the business context or the need. Assumptions over time may become invalid and thus be not in line with the business objectives. Such assumptions may be removed or deprioritized and be periodically monitored as required.  The BA is responsible for reporting on these assumptions and in keeping relevant stakeholders informed. The project manager and sponsor especially must always be kept informed, as assumptions when true may have a big impact on the triple constraints of the project. The timelines, budget, and scope of the project may get affected as a result of certain assumptions becoming true and these must be closely managed to ensure project success. Conclusion Assumptions are an important component of business analysis effort. If assumptions are identified and managed properly they can have a positive impact on the project. The business analysts role in identifying, documenting and managing assumptions is pivotal to the success of the project. Learn more about assumptions and associated risks by going through the YouTube video accessible from the link below.
Identifying, Tracking and Validating Assumptions
Author Image
Rated 4.0/5 based on 9 customer reviews
Identifying, Tracking and Validating Assumptions

The primary role of a business analyst in a project is to elicit, anal... Read More

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a , I must be able to so that I can .  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Writing Effective User Stories in JIRA
Author Image
Rated 4.0/5 based on 4 customer reviews
Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements... Read More

Project Contracts – A Vital Legal Binding

One of the key knowledge areas discussed in the Project Management Professional (PMP®) certification is Procurements Management. As part of project procurements management a project manager is mainly expected to be able to initiate, execute and manage projects based on the project contracts. This article is an attempt to discuss about project contracts, to discuss the importance of such contracts and to give an introduction to types of contracts as a precursor to subsequent articles. Everything you ever wanted to know about contract digital project management. New blog post #dpm #digital #digitalagency #pmo https://t.co/WO7CAbwbHR pic.twitter.com/bWmeCfGbFr — ProjectManagementOD (@ProjectMOD) 22 December 2017 The PMBOK® defines a contract as follows. “Contract represents a mutually binding agreement that obligates the seller to provide the specified products, services or results, and obligates the buyer to provide the monetary or other valuable consideration in return. A contract can also be called an agreement, understanding, undertaking or a purchase order.” (PMBOK® 5.0) Any project involves two or more parties. One main party that is the buyer and the other the seller. In addition to these there can be other 3rd party elements that are not directly involved in the contract but are interested in or are impacted by the same. The contract between the buyer and the seller happens to protect the interests of the two parties entering into the agreement. The seller provides goods or services to the buyer for which the buyer compensates the seller monetarily or through other financial or non-financial means.   A contract is a formal agreement between the two parties and it is a legal binding amongst the two entities. A formal contract must be in written format and can be used even in court of law in the case of either party failing to honour their commitment or in the case of an appeal against any misdeeds. Dishonouring contracts may actually lead to settlements even in court but should ideally be settled mutually among the disagreeing parties, most probably through a mediator called an ‘arbitrator’. Normally in large organizations contracts are managed by a separate contract manager or a procurements manager. The management of contracts are done in 2 separate ways namely; centralized contracting and decentralized contracting. In centralized contracting, one contract manager manages all the contract related matters for multiple projects. This requires expertise in contracting, standardization of contracting practices across the organization and more focused management of contracts. In decentralized contracting, separate contract managers are allocated to manage the procurements for individual projects. This results in full time management of contracts and the contract manager must report progress to the project manager. This results in more focused management of project contracts and with time creates specialized expertise in contracting. However, this may result in duplication of contracting expertise and less standardization of contracting practices across multiple projects in the company. #Passivehouse builder @AdamJCohen discusses the "gold standard" of Integrated Project Delivery contract typeshttps://t.co/rpk6GXV87W — Passive Buildings (@PassiveBldgsCan) 2 November 2017   There are three main types of contracts. They are Cost Reimbursable OR Cost Plus, Time and Material or Unit Price and Fixed Price or Lump Sum contracts.  The applicability and use of these contract types based on the type of project, complexity and the parties involved may decide on variations based on the charges involved in order to ensure that the contract terms are mutually beneficial for the two parties. Hence, these contracts vary based on the cost, time and price.  A cost plus or cost reimbursement contract is a contract in which the contractor is reimbursed or paid all the actual expenses they incur when carrying out the work. In addition to this they are also allowed to charge an extra fee allowing them to obtain a profit. For example a contractor taking up building a contract may claim resource costs as well as any miscellaneous expenses incurred for travel, food, purchases as well as charge an additional amount from the customer in order to make a profit from the tasks carried out. A fixed price contract on the other hand does not depend on the resources utilized or time expended. A fixed amount is agreed upon between the contractor and the customer where the amount is paid to the contractor even if the resources expended is lower or higher than the agreed upon amount. Time & material contract is where the contracting party is paid only for the amount of time or resources spent. For example if there is a software development firm which assigns 4 resources for a project on a T&M basis the company will be paid an hourly rate for each resource based on the amount of time they spend on tasks in the project.  Each contract type has its own pros and cons for both the contracting and implementation party. For example a fixed price contract is suitable for an organization as they would know the amount due before hand and know that they won’t end up paying extra if the triple project constraints are not met. Similarly, a time and material project may be suitable for both parties, as amount will be charged only based on the amount of work done in the project and for the time spent. Advantages and disadvantages of each contract type depend on the context. Thus, it is important for stakeholders involved in projects to negotiate on contracts wisely.
Project Contracts – A Vital Legal Binding
Author Image
Rated 4.5/5 based on 3 customer reviews
Project Contracts – A Vital Legal Binding

One of the key knowledge areas discussed in the Project Management Pro... Read More