How can Electronic Commerce be a business pressure and an organizational response?

Introduction

How can eCommerce (EC) be a business pressure and an organizational response? Has EC somehow lost the human interaction or touch? Why do businesses change their business models in the digital age? How has EC affected dynamic and fixed pricing of products or services? What are the risks of using Web 2.0 tools? These questions are the gist of this paper and they will be discussed briefly herein.

Business Pressure and Organizational Response

With ever-changing business climates, globalization, technical advancements, changing governmental rules, and societal factors are creating a highly competitive business environment. Many of these factors can change quickly and unpredictably (Turban, 2012). Business must be nimble and agile in order to respond to the circumstances. Electronic Commerce (EC) can be the means in which a company responds effectively to an ever-changing business environment.

These business pressures are divided into a market (economical), societal, and technological categories. The market or economic, pressures include stronger competition, much from a global economy; includes regional trade agreements, such as NAFTA, and low wages in many third world nations. Societal pressure includes the changing workforce, government regulation/deregulation, shrinking governmental subsidies or increasing subsidies, and rapid political changes including terrorism. Technical pressures are due to the rapid change in technology almost  on a daily basis including product obsolescence and rapid advancement.

The question of how EC can be a business pressure and an organizational pressure can be seen in having to respond to the various changes that occur in the marketplace, in society, or in government changes that occur. An example would be when Sarbanes-Oxley Act of 2002 (SOX) was passed by the Federal Government in response to gross accounting irregularities of companies like Enron and WorldCom. The law imposed stringent requirements on accounting reporting and management’s responsibility for the information contained therein. The business pressure was the SOX requirements and how could EC provide the answer to meeting those requirements. Today there are many accounting applications businesses can use that are readily accessible from the cloud such as Intuits QuickBooks.

Elimination of Human Touch

Some claim that digital business eliminates the “human touch”. The loss of human contact with the digital age is likely a tad overblown. While there have been significant changes in manufacturing due to automation, there has also been a significant increase in the number of ways in which we are able to reach out and touch someone. When you get down to it, EC has really created much more ways for humans to interact with the world around us (NSF, 2015)

The coming of digital technology has certainly changed the way people interact and do business. For example, people used to talk with each other face-to-face. We had to go to the local store in order to buy a loaf of bread. Of course, that type of communication took place in a very limited manner and it was with people who lived within your local community. Today millions of people across the world are interacting via Facebook. One can call a friend living in Holland from the US at little to no costs and talk for hours using Skype. Our local community has become worldwide. Just because we use Facebook for better than three hours a day on average doesn’t relinquish the requirement to build trust and lasting friendships (Fuller, 2014). We still need that human contact as a species.

Changing Business Models

Why do companies frequently change their business model?  What are the advantages and disadvantages? Companies frequently change their business models when it becomes either advantageous or necessary to do so. Advantageous because the business stands to gain financially from making an EC change that would make them more competitive. Necessary because if the business doesn’t change they will be less competitive and perhaps out of business as a result.

An example would be when many companies like Sears and JC Penney decided to quit producing their old line print catalogs in favor of producing an online catalog of the goods they sell. By producing the catalog online they were able to see huge cost savings and an increase in sales. Plus, each company was able to reach out to many more potential customers by using social media, email, and online advertising to draw people to their online catalogs (Turban, 2012).

Effects on Dynamic and Fixed Pricing

Discuss the advantages of dynamic pricing over fixed pricing? What are the potential disadvantages of dynamic pricing? Dynamic pricing is based on supply and demand of a given product. The pricing is considered dynamic as it fluctuates depending on the circumstances of supply and demand. The process could include a company posting a bid to buy or sell a product, a forward/reverse auction; buyers/sellers see the offers/bids online and they interact in real time competing with the other buyers/bidders but they may not whom they are competing with. Many variables have to come into play in order for the transaction to be completed such as price, time, location and other variables before the transaction is completed (Turban, 2012). The advantages are numerous for these types of interactions. It is easier to conduct an auction online than it is at a physical location; one has to actually secure a location, hire people to help run the auction, bring the product to the location. EBay, for instance, conducts auctions on hundreds of thousands of products daily without a physical structure in which to show all of these products. Everything is shown in the customer’s living room on their computers. These customers can view the products at their leisure when they want to. They can watch the bidding in real time, they know what they’re buying, and thus eBay is not losing customers due to the fast nature of live auctions.

Fixed pricing means the price is set, the only negotiating may be quantity price breaks or sales deals of the moment. Many companies offer the opportunity for the consumer, mostly on the retail side, to do comparison shopping so they can see if they’re getting a good deal at a good price.

Web 2.0 Risks

Web 2.0 tools include social media, wikis, blogs, Business Intelligence Analytics, dashboards, chat rooms and much more than can be listed here. The ability of Web 2.0 to change our lives has been tremendous and exciting. One of the main risks with Web 2.0 is that it has opened us up to the possibility of fraud. Craigslist is an example of where the possibility of fraud exists as there have been numerous complaints of illegal ads and other practices (Wikipedia, 2016). Security issues abound, especially with credit card usage. Hackers have the ability to access transactions as they occur, especially at ATM’s. The government realizes the benefits of using Web 2.0 technology, but they also understand the risks (Uthayasankar, Zahir, & Vishanth, 2015). Today we see the proliferation of anti-virus software like Norton, or the growth of cybersecurity companies like Palo Alto, Inc. Many companies, when considering using Web 2.0, have to weigh the benefits with the risks. They have teams of developers that concentrate on areas that help to secure the benefits being delivered.

Conclusion

Has EC had a profound affect on our lives. Yes, it has, even for those who claim it hasn’t. Everywhere we go we see the effect of Web 2.0 technology being used even if we don’t realize it. Business are constantly changing the way they do business. People are communicating more and sharing more than at any time in human history. Just look at Facebook for proof of sharing. Does it all have its downside? Of course, it does. Jobs have been eliminated due to changes in technology. Just look at the coal industry as an example; in 1920, almost 785,00 people were working in the coal industry. Today around 80,000 are employed in the production or use of coal. The cause of the decline is due to modernization (SourceWatch, 2015). Is it risky to use Web 2.0 technology, yes it is. But the benefits outweigh the risks. Just looking at the effect on dynamic pricing activities shows how much more efficient the whole system works is proof of the positive effect on society Web 2.0 has had.

References:

Coal and jobs in the United States – SourceWatch. (2015, June 26). Retrieved from

http://www.sourcewatch.org/index.php/Coal_and_jobs_in_the_United_States

Craigslist – Wikipedia, the free encyclopedia. (n.d.). Retrieved February 5, 2016, from

https://en.wikipedia.org/wiki/Craigslist

Fuller, E. (2014, March 20). Are we losing touch in this age of digital communications? Retrieved from

http://www.forbes.com/sites/edfuller/2014/03/20/are-we-losing-touch-in-this-age-of-digital-

communications/#13c6589963e7

NSF (2015).  The Internet, Changing the way we communicate. (n.d.). Retrieved from https://www.nsf.gov

/about/history/nsf0050/pdf/internet.pdf

Turban, E. (2012). Electronic commerce 2012: A managerial and social networks perspective. Upper Saddle

River, NJ: Pearson Prentice Hall..

Uthayasankar, S., Zahir, I., & Vishanth, W. (2015, October 4). Evaluating the use and impact of Web 2.0

technologies in local government. Retrieved from http://www.sciencedirect.com/science/article

/pii/S0740624X1500076

Cross Functional Integration in Project Management

Introduction:

Bill Swanston and Gary Biggar work, respectively, as an Operations Manager and Senior Business Analyst for Robbins-Gioia, Inc. delivered a presentation to the Project Management Institutes (PMI) annual Seminars & Symposium on September 7–16, 2000 in Houston, TX. I will be summarizing their article “Developing a framework for establishing cross-functional integration within a product development project” (Swanston & Bigger, 2000), published on the PMI website, and showing how what they do to run projects relates to the concepts we will be studying in our course this semester.

In order to understand Project Management Integration one has to first understand what makes up a project. All projects have a start and a finish; they’re not an ongoing endeavor. The parts between the beginning and the end are what concerns Project managers the most. And it’s how these parts are brought together to perform the required tasks, at the right time, bringing the project to a successful conclusion that is known as project integration. This integration management comprises the processes and activities that identify, describe, join, and synchronize the various processes and activities within the process groups (PMBOK, 2013). What Swanston and Biggar have developed is a process they use to manage the various projects they work on within the auto industry, but these processes are applicable to any industry.

Project Templates

Swanston points out that the creation of project templates in which to organize integration of projects is essential. The first of these templates Swanston calls the “Overall Project Template”. It contains the major milestones and key events for a typical product development project within the organization. The Overall Project Template is used to set the margins or parameters for the project. These parameters are commonly referred to as the scope of the project. All team members, once this is complete, will use the Overall Project Template as a reference to plan their exact detailed work.

The Project Integration template is second of the templates and it is the integration/management template that incorporates the details for the milestones and the key events used to effectively manage the project.  The Project Integration Template includes the detailed tasks needed to complete all of the high-level tasks. It basically fills in the blanks for the Overall Project Template. But this template should not be too detailed; it should not go deeper than 3 or 4 levels down. The smaller details will be handled at the functional level by developers or programmers.

One thing to note, as in any Work Breakdown Structure (WBS), which is basically what the integration template is; the project integration template is best when it’s structured by function. By this Swanston and Bigger mean that all functions need to be included in the template and each task identified needs to be linked to an appropriate deliverable. They do this linking using the “Text” and “Flag” fields in Microsoft Project in which to filter out the essential tasks from the summary tasks. Swanston points out that developing these templates requires participation from all involved in the project. Their buy-in is extremely important to the successful conclusion of the project (Swanston & Bigger, 2000). They advocate holding weekly strategy meetings in which at least one member from each impacted team is required to attend. Swanston and Biggars use these templates to help define the high-level requirements of the project and to bring together all the different impacted teams in order to properly integrate the management of the overall project.

How the Overall Project Template and the Project Integration Template Relate to Course Goals

A key in any project; the earlier the Project manager can get a high-level plan to the impacted teams, the better. Part of the process, in the beginning, is to get all of the impacted teams thinking of what this project is about and to get them started on discussing project strategy, to identify tasks, and what resources will be required in order to complete those tasks. Swanston’s overall project template is much like putting together the project charter which includes the project scope, project work statement, and business case on a high level.

The Project Integration template begins to put the teams on the planning path bringing together expert judgment to review the charter and scope requirements and creating the WBS from which the project plan/schedule/budget will be created. The WBS, like Swanston’s Project Integration Template, allows the team to tie together the different tasks to a specific deliverable which is tied to a specific business requirement. It also allows the team to ensure that all tasks are completed in order and on time.

Getting team members to work together is also an essential part of integration management. Part of the challenge with many projects is that the teams involved come from a variety of departments. Getting them to work together has its own issues. Each department can have its own set of rules and requirements. One department could require a special work request form to be submitted. Another could require that it needs authorization from another department before it can begin work. And each of those departments didn’t bother to mention these requirements until shortly before their work was to begin. There is a certain amount of skill and experience required on the part of the Project Manager in order to stay ahead of these types of obstacles. Integration plays a huge role in defining the skills a Project Manager will need.

Conclusion:

Implementation of the project management process presented is essential to the successful integration of any project. True cross-functional integration involves bringing together multiple vertical and horizontal functional tasks in developing the project charter and scope, creating the project plan so that the work and tasks can be identified so that execution is properly scheduled. Swanston and Biggars use a tool they created that aligns quite well with the PMI PMBOK requirements and it shows to be quite adaptable to other industries as a result.

References:

Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square, PA: Project Management Institute.
Gido, J., & Clements, J. P. (2012). Successful project management. Australia [etc.: South-Western Cengage Learning.
Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Swanston, W. J., & Biggar, G. T. (2000). Developing a framework for establishing cross-functional integration within a product development project.  PMI publication. http://www.pmi.org/learning/cross-functional-integration-product-development-8906

Building Project Team

Introduction
Starting a new project can be a very interesting experience, and yet it can also be a terrifying experience. Interesting or horrifying depends greatly on your level of experience. The most interesting and challenging part is actually putting the team together. There are many aspects to consider such as: What tasks need to be completed; what level of expertise will be needed; what amount of time will be required to complete each task; and if the task requires only a certain expertise for a short time, is that expertise available when you need them?

Other questions that need to be considered involve governing the project. The processes that will need to be established will need to be considered by both the team and by management. Processes that involve communicating, conflict management, risk management; all need to be considered and planned.

This paper will discuss the processes and elements needed to manage a team in a project. It will discuss the various attributes of good team process, the key elements required to running a successful team, the core processes of a high performing team, and how to manage the inevitable conflict that arise in any project team.

What Is Process

Processes are the tools and procedures used to complete projects successfully. In team space, the project team usually defines processes that fit the needs of the specific project. These can be temporary or for the life of the project.

Some processes are determined by the company. These types of processes are considered to be permanent processes and all projects have to abide by them. An example could be financial reporting procedures, timekeeping, status reports, or procurement policies as processes the company decides, not the project.

The Five Key Attributes of Good Team Process

Processes are what help to keep a project running smoothly. Without processes, projects will go off in several different directions at once and control is lost. To effectively develop and manage processes the team needs to follow five key attributes; depersonalize issues or topics; increase team transparency; make discussions objective, not emotional; make the environment participatory and inclusive by giving each team member equal weight and power in decision making(Wong, 2007).

Using these five key attributes ensures effective smooth running of the project. Rewarding contribution from team members shows them that it is safe to speak up. When the team speaks up ideas begin to flow and the team discovers a better way in which to solve an issue. Shutting team members down only contributes to an unsuccessful project. Our society has a tendency to shut members of the society down; minorities or women are told by men that their thoughts are not important. We could very well be telling a potential discoverer of the cure to cancer to shut up. The same thing can happen when the process of the project allows for some members to dominate the conversation leaving others out of the decision making process. Allowing for inclusiveness encourages participation giving each team member power to help make decisions.

The key is the team decides on the processes it will use to manage itself. And these processes need to be decided early in the project (Wong, 2007). Some teams try to develop processes on the fly which means the team will be constantly trying to determine how issues or problems will be handled as they occur. Having a predetermined process in place that determines how a process not anticipated needs to be handled is just smart thinking on the part of the team. It allows for the transparency in decision making to grow in strength.

Core Processes of High Performing Teams

There are six core main areas in which the team requires effective processes. These areas really involve the main day-to-day activities of running a successful project. They include team meetings, roles and responsibilities, communications, decision making, measuring performance, and feedback (Wong, 2007).

The team needs to set regularly scheduled status meetings with the team as a whole, with upper management and with the sponsors of the project. The team, depending on the project schedule should meet at least weekly to review the status of the project, discuss what was done and what is planned, and to determine a course of action for any issues or blockers (PMBOK, 2013).

Roles and responsibilities, such as team leaders and facilitators, need to be defined and assigned early on in the project as they will help facilitate decision making and feedback. This is important because it will help to facilitate assigning leads on issues when they crop up. It also helps the team and management determine who they should go to if the situation arises as a crisis and decisions need to be made quickly making the luxury of meeting to discuss impossible.

A communication plan needs to be established right from the start of any project. The communication plan determines how and what gets communicated and to whom. It determines who is responsible for what gets communicated and how that communication gets delivered (PMBOK, 2013).

An example is the status report. There are many different levels in any given project that require a status report. These levels include the project team, upper management, or the sponsors of the project. Each require different information and want it presented in different ways. The overall team needs to determine what information is needed for these status reports, such as performance measurements and feedback, how it will be gathered, how it will be delivered, and how feedback will be returned. These reports need to provide the information needed to manage the project and not everyone needs the same information or all of the information. Most importantly, the team should decide who will be responsible for managing these reports.

Content

Content tells the team what it is that is being asked of them. It explains why this project is being put together, what the objective is, what assumptions are being made, and how it affects the strategy of the company.

Vision is a major part of content as it tells the team what it is we’re all aiming for. Vision shows what is possible by completing this project. Vision can be inspiring and shared by everyone on the team. Vision can be a motivator that provides direction moving the team forward because it understands the opportunities and the strategies presented.

To accomplish the goals of the project the team needs to understand the content in order to create the processes that will help deliver that vision. Without the content the team has no idea what is expected or being asked of them.

Conflict

Conflict in project management is very much like conflict in a friendship: it’s going to happen. The key is in the processes used to resolve the conflict. The likelihood that conflict occurs, especially in information systems development projects, is extremely high because the individuals involved are from different backgrounds and cultures working together in the project. Conflicts can arise due to differences in values, needs, perceptions, and personalities. Appropriate skills in dealing with conflict can help project managers to handle conflicts effectively and lead to a successful conclusion of the project (Ohlendorf, 2001).

Hidden Agendas

Hidden agendas are generally caused when members of the team do not share information. It may be information a team member feels they cannot entrust to the rest of the team, or they’re new to the team and they don’t feel comfortable sharing it with others just yet. The solution to hidden agendas is open and honest communications. As a team, together you decide how the team will communicate in an open and honest way. Building open and honest communications builds a trusting environment for the team and leads to successful projects (Herzog, 2001).

Project Hierarchical Flowchart

Figure 1.1, the Project Hierarchical Flowchart, shows the interaction between the different groups so that the members of the project team can tell who reports to whom in the hierarchy. The object of the project flowchart is to provide a pictorial representation of the project authority. It should show the team members who have the final authority of approval for many of the project requirements while also showing who has responsibility for each of the project sections.

Figure 1.1. Project Hierarchical  Flowchart

Conclusion

The secret to handling conflict and building a successful team is open and honest communication. By setting up the processes that allows for open and honest communication you develop a more cohesive team that works together to resolve issues and problems when they arise. Conflict can be a good thing when it is used to arrive at solutions (Wong, 2007). Conflict in project management is inevitable but when properly managed it can lead to favorable conditions. However, conflict can be very damaging to a project when not well managed. For Project Managers the challenge is to try to find what the right amount of conflict in a project is. Project Managers can establish an atmosphere in which team work is encouraged and the project goals are reached by understanding the intricacies of conflict, and learning the distinctions of the different approaches to conflict resolution.

References:

Herzog, V. (2001). Trust building on corporate collaborative project teams. Project Management Journal, 32(1).
Ohlendorf, A. (2001). Conflict resolution in project management. Information Systems Analysis.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Conflict Resolution in Project Management

Introduction:

Conflict in project management is very much like conflict in a marriage: it’s going to happen. The key is in the process used to resolve the conflict. The likelihood that conflict occurs in information systems development projects is extremely high because the individuals involved are from different backgrounds and cultures working together in the project. Conflicts can arise due to differences in values, needs, perceptions, and personalities. Appropriate skills in dealing with conflict can help project managers to handle conflicts effectively and lead to a successful conclusion of the project.
Amy Ohlendorf discusses in her article that conflict is a state in which different parties are aware of the incompatibility of their positions with each other and that these parties choose to hold those positions even though they know them to be incompatible (Ohlendorf, 2001). In her article she discusses how to understand the pros and cons of conflict; how it can be both beneficial and detrimental to the project.

Conflict Causes:

We have to realize that the environment the Project Manager works in can be characterized by large cultural diversity (PMBOK, 2013). Teams are made up of people with many different experiences, come from many different countries; each with their own unique culture and language. Their values will be very different from the Project Manager and other members of the team. These differences will cause them to look and perceive the expectations of the project completely different from other team members. What the Project Manager should do is use these differences to the advantage of the project and the team (PMBOK, 2013). Ms. Ohlendorf points out that these differences can aid in strengthening the project outcome as well as the organization overall if one takes a positive proactive approach (Ohlendorf, 2001).

Storming Stage and Conflict Resolution Approaches

The Project Manager has to realize that not all conflict is bad (Wong, 2007) in fact, some conflict can actually aid in pushing the project through complex problems. A good debate amongst peers can actually help to bring them closer together into a tighter working relationship. These types of debates generally will occur, as described in the Tuckman Ladder (cited in PMBOK, 2013), during the storming stage in a project. Many times conflicts can arise during this stage.

The Project Manager can use a number of approaches to resolving conflicts (Kerzner, 2001):

•    Confronting –The conflicting parties meet face-to-face to collaborate and come to an agreement to resolve the issue. This style involves open and direct communication which should lead the way to solving the problem. It should be used when it is early in the project so you have time, conflicting parties need a win-win, and it helps to foster good working relations.

•    Compromising – Also known as give and take. In this case both parties need to win but you don’t have the luxury of time. A decision needs to be made and coming to the middle ground can help move things along. The thing with compromising is that all involved may get a little of something, but they don’t everything. Some might consider that better than nothing at all while others will feel they got too little. The Project Manager has to be prepared to use a little smoothing when using this approach.

•    Smoothing – Some refer to this as an accommodating or agreeable way to come to resolution in an argument. I would use this if the stakes are low and I want to pocket some good will for down the road.

•    Forcing – Used when a decision has to be made due to time or cost and the conflicting parties are not being agreeable. I’ve used this when the project simply had no more wiggle room or the sponsors basically said do it. I have used this in conjunction with smoothing so as not to have too many ruffled feathers.

•    Avoiding – This approach is used when there is time to avoid so that you can better prepare yourself for a future discussion. You can use avoidance when the cost or the risk is low. But avoidance is not something that can be used very often. Ignoring the problem doesn’t make it go away. Smoothing might be in order here due to the need to placate until better prepared.

The impact on the project when using the above approaches has been shown to either lesson the amount of conflict or increase it. I have found that using the above approaches, while applicable in all stages (forming, norming, performing, and adjourning) I have found them used to a greater amount during the storming stage. A more confronting style has shown to limit the amount of conflict later in the project due to resolving issues early on rather using compromising, smoothing, or avoidance. Forcing can be one of the worst when it comes to lessening conflict as it usually leaves team members with hard feelings making them less likely to want to work on the project since their needs aren’t being met (Wong, 2007). The manner in which the Project Manager approaches conflict creates the manner in which the team responds to conflict in the future. Starting out by avoiding conflict will only increase the chances of it occurring as, or if, the project progresses (Ohlendorf, 2001).

Cognitive Analysis Approach:

I have found that the Project Manager needs to take what is referred to as a cognitive analysis approach to conflict resolution. The cognitive approach says that conflict is mainly due to perceptive differences between conflicting individuals. Using the confronting approach with cognitive analysis allows for feedback to be presented allowing for each side to gain insight into what the other is thinking. This insight gives conflicting teammates an opening to reach a satisfactory resolution to the conflicting issue. By identifying the real issue in the conflict resolution it allowed each side to concentrate on the real issue, not side issues which tend to be emotional. Each teammate comes to a greater understanding and appreciation of the other thus creating a cohesive working relationship (Ohlendorf, 2001).

Listening:

One of the top skills that the Project Manager needs throughout these approaches is their ability to listen. And keep in mind that listening works both with the Project Manager and with the team member. Many times team members are busy trying to figure out how to win the argument rather than listening to what the other team member is saying. This behavior is particularly prevalent when the project has been doing a lot of avoidance or when the issue has been forced due to an uncompromising party to the conflict. Recently a conflict arose in my current project due to a decision forced on one team by another team impacted by the needs of the project. The team that had forced the original decision was now finding itself in the position to have to defend that decision to the sponsors of the project. They were trying to wiggle their way out of it and just kept digging that hole deeper and deeper. They weren’t listening, even when the team they had forced the original decision on was offering a face saving compromise. Listening would have led them to resolving the issue. Not listening almost caused irreparable damage the project as well as to relationships and reputations.

Conclusion:

Conflict in project management is inevitable but when properly managed it can lead to favorable conditions. However, conflict can be very detrimental to a project if it is not well managed. For Project Managers the challenge is to try to find what the right amount of conflict in project management is. By understanding the subtleties of conflict, and learning the nuances of the different approaches to conflict resolution, Project Managers can establish an atmosphere in which comradery is encouraged and the project goals are reached.

References:

Kerzner, H. (2001). Project management: A systems approach to planning, scheduling, and controlling. New York: John Wiley.
Ohlendorf, A. (2001). Conflict resolution in project management. Information Systems Analysis.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Team Building – A Critique

Trust has been shown to be of utmost importance to delivering projects successfully. Without even the best planned projects can fail. Without trust the project is doomed to continually fighting battles that threaten the team’s ability to deliver a quality product/service on time and within budget.

Introduction:
Dictionary.com (2015) defines trust as a reliance on the integrity, strength, ability, surety, etc., of a person or thing; confidence. It is a confident expectation, a hope that someone or something is going to deliver as promised On a project team the members of the team fully expect and trust that the project leadership to manage the project efficiently. But it’s a trust that has to be earned, and not just by the projects management team; it has to be earned by everyone in order for the project to be successful.
Valerie Lynn Herzog conducted a study: Trust Building on Corporate Collaborative Project Teams (Herzog, 2001) in which she determined that trust is a huge factor in the successful completion of a project. But, there is a process the group needs to go through in order to build trust amongst the team members. Ms. Herzog’s paper concentrates on the team collaborative trust building because many times teams are chosen and the team only has the opportunity to work together, many times without really knowing one another.

Team Building:
Herzog’s study centers around building trust through collaborative efforts; such as shared processes, honest communications and just getting along (Herzog, 2001). She had found that while upper management many times have the choice of whom they will work with, team members are usually assigned to a project with little choice but to accept the assignment (Herzog, 2007).

I know this to be true in my assignments. Even as Project Manager, I’m generally not given the choice of which projects I will be managing. In fact, I’m rarely given the choice of which resources are assigned to my projects.

Research has found that levels of trust are based on the collaborative team member’s perception of themselves, of other team members, and of other stakeholders in the project (Herzog, 2007). These trust levels really embody the key behaviors that are needed for project or team success: Mutual trust; Interdependency; Accountability; valuing individual differences; Transparency, and learning and recognition (Wong, 2007). Without these, even a well-planned project could be doomed to fail because no one trusts each other. Without these key behaviors; particularly mutual trust, a project is usually doomed to failure, or worse, a long agonizing path to success.

Perceptions of Team:
In the study Herzog interviewed 20 participants from 4 different IT projects. The participants had positions on the teams ranging from Senior Manager to Junior Technical Designers. The participants included Project Managers, Business Analysts, Programmers, Senior Managers, and Program Managers.
Perceptions of different issue or deliverables in the project appear to be universal. For example, the charter was seen as a lot of nice to haves but not to be taken seriously since no one really looks at once its produced (Herzog, 2007) The reality is that the Charter is the most important document in a project. It contains the project purpose, high level requirements, the project scope (PMBOK, 2013). Part of the trust has to be delivered through the charter. Team members like to feel that what they’re doing has meaning. Without any meaning then the team wonders why they’re doing what is being asked of them.

Collaborative Sharing:
Using collaborative sharing helps to bring the team together, especially in the beginning of the project. Each individual team member comes into the project with their own perception of what is involved. And, most likely, with how to solve the problem or to create the solution that brings the project to a successful conclusion. Imagine that you have a team of 20 in a room and each one has the solution. The question is: how are you going to bring each of these individual solutions together as one solution?

Herzog found that creating that trusts requires formal processes and that these processes should occur frequently (Herzog, 2001). I have found that one collaborative process with the team is to specifically review the Project Charter so that they understand what is being asked and they see there is high-level support for the project. I also have found it to be a great way for the team to build trust in each other by sharing the process of review together. The team begins to get to know one another as they share their thoughts on what the Charter means to them. As they get to know one another they begin to trust and to form bonds that help to create a working relationship. Collaborative sharing helps to build a solid foundation in which to drive projects to a successful conclusion.

The solution to the above question was to begin with open and honest communications. As a team, together you decide how the team will communicate in an open and honest way. Building open and honest communications builds a trusting environment for the team and leads to successful projects (Herzog, 2001).

By defining the communications processes we can begin to realize other team member’s motives for the solutions they bring to the table. By understanding a team members motives we can better understand their responses to questions or their ideas when the present them. By encouraging team members to openly respond to inquiries or questions we could also be opening the flood gates to better solutions to the projects goals. Trust has to happen between two people first and then grow from that point. As that trust grows, people feel free to speak up, other team members begin to open up and trust other team members. The goal, hopefully, is that trust becomes contagious, as trust makes for a better work environment.

But trust needs to be maintained on a continuous basis. It’s not a one shot and done deal (Herzog, 2001). Trust can be lost at any given time for a lot of different reasons. A team member could show an indifference to the team, not care if their held accountable or not. A team member could decide that their solution is better than what the team agreed and they start to act independent of the team. Here the team needs to bring everyone together to reassert the ground rules and clearly define the authority level the team abides by (Wong, 2007). Clearly, the process of building and maintaining trust is an ongoing process.

Conclusion:
Trust has been shown to be of utmost importance to delivering projects successfully. Without even the best planned projects can fail. Without trust the project is doomed to continually fighting battles that threaten the team’s ability to deliver a quality product/service on time and within budget. By sharing collaborative processes and conditions amongst the whole team on a continuous basis the team and the project will benefit. Collaborative sharing will help to build the trust necessary to bringing a successful conclusion to the project.

References:
Dictionary.com. (2015). Trust | Define Trust at Dictionary.com. In Dictionary.com. Retrieved from http://dictionary.reference.com/browse/trust?s=t
Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.
Herzog, V. (2001). Trust building on corporate collaborative project teams. Project Management Journal, 32(1).
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Project Leadership

Successful projects are usually the result of strong leadership. The question arises as to what is considered, or what does it take, to be a strong project leader. Especially in today’s world of project teams made up of people from cultures around the world. This paper will examine the many different aspects, interpersonal skills and qualities of what it takes to be the leader of a successful project in the IT world.

Abstract

Successful projects are usually the result of strong leadership. The question arises as to what is considered, or what does it take, to be a strong project leader. Especially in today’s world of project teams made up of people from cultures around the world. This paper will examine the many different aspects, interpersonal skills and qualities of what it takes to be the leader of a successful project in the IT world.

Introduction

Project Managers (PM) are very unique people. The expectation is that they bring their projects to a successful conclusion with hopefully just enough resources, money, and time. The expectation levels are pretty high and the pressure can be extreme. They’re asked to take a huge unknown and make it all work together to produce a known. They are the boss of no one; yet are expected to get people to do what needs to be done and are held responsible if they don’t succeed. They have to bring together a group of people who have likely never worked together before and make it so they are a finely tuned engine with all cylinders firing in unison. Depending on the size and nature of the project, that could be a lot to ask of any one individual. It would take a special kind of leader.

Leadership is no longer limited to one or two executives at the top of an organization. There are many different levels of leadership in any company, especially in today’s global economy where resources specialize in a given area of business. Everyone in the company must be a leader if the organization is to survive and thrive (Tichy & Cohen, 1997). Without good leadership, nothing works. Projects have been known to get totally out of control because there was no one leading the group. And even if there is a leader, if they’re weak, the project team will run all over that person.

Leaders are not born leaders; leadership is a discernible set of skills and abilities. Granted, some people are better at managing than others, thus seeming to so many to have been born a leader. But like everyone else, they learned and practiced to become skillful at leading.

Leadership is a relationship between those who aspire to lead and those who choose to follow. Not all of us can or want to be leaders. Sometimes the relation

ship is one-to-one; sometimes it is one-to-many. Regardless of the number, leadership is a relationship between leaders and followers.

But amongst all of the traits a leader needs there is one that has to be earned and it is the one most admired; personal credibility. Without personal credibility there is no foundation of leadership. Personal credibility brings with it trust; we want to believe in our leaders, have faith and confidence that they believe in the direction we are all going. The team has to believe that the PM has the end goal in mind.

PM’s need to have a combination of the above mentioned skills and abilities in order to be good leaders. First amongst these skills are people skills. Next is, depending on the project, technical skills. Technical skills really depend on the project. If it is IT or other highly complex project then technical skills helps in bridging the trust factors of the team (Verzuh, 2012). If the team doesn’t have faith in your technical skills, or at least your ability to understand what they’re doing, they begin to believe you cannot lead them to the end goal of the project.

Other interpersonal skills include leadership, team building, motivation, communication, influencing, decision making, political and cultural awareness, negotiation, trust building, conflict management, and coaching (PMBOK, 2013).

PM’s have to be able to think quickly on their feet when making decisions, sometimes by themselves, but more often with the project team as a whole. They get much of this ability to think quickly from the knowledge and experience they have gained from many years of practicing their trade. Without the education that experience brings us we would not be able to be leaders in this new world.

There are five success factors every project has to meet in order to be successful: Agreement amongst the team as to the goals of the project; a plan with a clear path to completion along with clearly defined responsibilities that can be used to determine progress in the project; continuous effective communications understood by all involved; controlling scope; and management support (Verzuh, 2012).

Getting everyone involved in the project to come together on all five factors is the PM’s job. This paper will discuss the various interpersonal skills needed to successfully bring these factors together and how they apply to the art of Project Management.

Interpersonal Skills

There is no doubt that the best PM’s are also exceptional leaders. They inspire, they bring people together by giving them the vision of what’s down the road, people trust them, and they achieve countless things. To successfully lead a project to completion requires a strong leader with people skills in leadership, teamwork and team behaviors, decision making, problem solving, and conflict resolution. Without these interpersonal skills the project will lack strong leadership and direction which could cost the organization tremendously.

There are three skills, broadly speaking, that good leaders should have:

1.    Technical skills because the team will trust and believe in you if you can participate one-on-one with them in finding a solution; or at least can talk the talk and walk the walk. In the IT world it’s knowing programming, it’s knowing how the pieces of the system fit together in order to make it work. The team wants to know that if need be, you can make it work on your own.
2.    Human skill knows how to work with people. It’s very different from technical skill which has to do with working with things. These skills allow a leader to work with people to help them achieve their goals which helps the project achieve its goals. People skills allows a leader to work with groups of people, especially useful in project management since the object is to get a group of people to work as one towards a common goal.
3.    Conceptual skills involves possessing the intelligence trait as it deals with the ability to work with ideas and concepts. It is central to creating the vision and plans for the project and conveying those thoughts effectively to the team and stakeholders.

Good leaders need to possess a certain traits like intelligence; basically the ability to express ones-self verbally, perceptually and with sound reasoning brings people to trust in your ability to lead. They need to be self-confident. Self-confidence is the ability to be certain about ones skills and competencies. This includes self-esteem. But a good leader is not arrogant. Influencing others is part of being leader and having the self-confidence to influence allows the leader to feel that their attempts to influence are correct and good for the project. Integrity is highly important because it is the quality trait of honesty and trustworthiness. Leaders who adhere to a strong set of principles taking responsibility for their actions exhibit integrity. Sociability is the trait of seeking positive pleasant social encounters. Good leaders like to talk with people, especially in intelligent stimulating conversations. They are polite, sensitive to others needs, outgoing, tactful and diplomatic (Northouse, 2004).

Leadership

Leadership involves concentrating the efforts of a group of individuals and moving them toward a collective goal, empowering them to work as a team. Leadership is the talent to get things done through others. It’s very much like herding a bunch of cats. Respect and trust are keys of actual leadership. Fear and compliance only lock the door to future cooperation. Although important in every project phase, good leadership is critically important during the initiation and planning phases of a project. This is the time to bring the team on board by telling them the importance of the goal, using that vision to motivate and inspire a group of individuals to come together formulating a team to achieve success. Good leaders always have the end in mind.

All through a project, the PM has to establish and reinforce the vision and strategy by continuously communicating the message. This communicating helps to build trust; build team; influence, mentor, and monitor project and team performance. After all, it is people, not plans that complete projects. The PM, by inspiring others to find their voice, keeps the goals and objectives front and center. A successful project is a result of everyone agreeing on what needs to be done and then doing it. From initiation to closing, the project depends on the willingness of all involved to come to agreement, to synchronize action, to solve problems, and to react to changes. Communication amongst everyone is all that is required (Verzuh, 2012).

Team Building

Team building is the process of helping a group of individuals to work together as a cohesive unit, to work with their leader, to work with external stakeholders, and the organization. In the end, good leadership with good team building makes teamwork. PM’s have to remember that running a project is not a one-person effort; it takes a team to complete a project.

Team building really does require all the interpersonal skills a PM can muster, as well as the five success factors for a project. To know and like a PM is to trust them. It’s not likely the team will trust their leader if they don’t really like him, they can’t really like him if they don’t know him, and in the end they won’t trust him if they don’t like or know him.

A project team is a group of people with complementary but diverse skills and experiences who are asked to work together to accomplish the goals and objectives of the project. The purpose of the team is to develop and execute a work plan that will meet the goals and objectives of the project. Everyone on the team needs to be committed and dedicated to the same thing: meeting the goals of the project. Although the goals may be same, how the team elects to execute the work plan is variable.

Team-building activities consist of a series of tasks that establish the goals of the project, clearly define the roles and responsibilities of each team member, and establish the procedures and processes the team will work under.

Some of these processes include how the team will communicate, how it will interact with each other in meetings; the PM needs to lead the team to agreement on establishing the rules for conflict management. Establishing these rules allows the developing of an environment in which the team can work. Part of developing a team environment involves handling project team problems and determining how these issues will be discussed. The PM puts these processes together with their team because the PM knows that the team needs to take ownership and have buy-in for it to work.

Team building helps build commitment from your team. They have to choose to become a member of the team. The PM cannot make them commit, the individual has to decide. The PM, as a leader, has to figure out what is the best way to get that true commitment from you. He has to figure out how to empower you to decide to commit to the project, its goals and its objectives. Some people prefer committing to a team rather than as an individual; it makes it easier for individuals to join. Some people just have trouble committing to a decision except when in a group. Some call this group think where one individual does all the talking and everyone else just follows along. The talker is given a false sense of empowerment believing they have control. The wise leader will learn what it takes to motivate this individual and what it will take to bring the best out in the rest of the team.

Team building involves bringing out the best in each member. Some members can be timid allowing other members to make the decision and they’re along for the ride. The problem here is that there are a select few who are actually running the team rather than having involvement from all. If all are not participating it makes it tough to get strong commitment for all because decisions are being made that some might find objectionable. But because the team leader didn’t allow the opportunity for them to speak up, they go along half-heartedly accepting the direction the project is taking even though they might know a better course of action.

Changes are inevitable in a project, and the PM has to manage them effectively with a continual team-building efforts. The PM should continually monitor team functionality and performance to determine if any actions are needed to prevent or correct various team problems. With team building, as the PM develops the team, team performance should increase.

One model of team building involves five distinctly different stages of maturation in the team (Tuckman, 1965):

1.    Forming: This is when the team is getting to know each other. They’re interested in who each member of the team is and what they bring to the table. Questions like what do they know and will they be able to help me if I have a problem. Teammates also want to know that the other teammates will carry their weight.
2.    Storming is where the team begins to dig into the project goals and objectives. They begin to define and divide the tasks needed to be done and who will be responsible for completing those tasks as well as when. Technical decisions are made during this period. Gaining an understanding of the project processes also occurs. Cooperation can become counterproductive if the team does not collaborate well.
3.    Norming is the beginning of cooperation amongst the members of the team. They begin to trust one another, especially each others abilities.
4.    Performing is when the team begins to work as a well-oiled machine. Trust is attained and production increases. Conflict is minimal but productive as they work through issues easily.
5.    Adjourning brings the project to a close. The final product is approved for production and the team moves on to the next project.

Team building can be additionally enriched by gaining top management support; encouraging team member commitment to the goals and objectives of the project; introducing appropriate rewards, recognition, and ethics; creating a team identity; managing conflicts effectively; promoting trust and open communication among team members; and providing leadership. While team building is essential during the front end of a project, it is an ongoing process. Changes in a project environment are inevitable. Maintaining ownership and buy-in form the team will be difficult. To manage these changes effectively, a continued or renewed team-building effort is required. Outcomes of team building include mutual trust, high quality of information exchange, better decision making, and effective project management.

Three Spaces of Projects

As discussed above, part of team building involves creating the right environment in which to work. The dynamics of a project have been said to operate at three different spaces of project management. Space refers to an abstract boundary of human relationships.

First, people interact within the systems occurring in an expansive organizational space. This is the space that is defined by the organization that all members of the organization have to abide by. These include where in the building a team member’s desk is located; dress codes; hours of operation; company vision and goals.

Next, people interact with each other within a smaller space known as a team space. Because each project is different, organizations allow them to set up their own rules and processes so long as they fit within the organization space. The team space is defined by the team. This is where the team defines how members will interact with each other. Rules are defined as to how communications will be handles, how members will conduct themselves in meetings, how status reports will be delivered.

The last space is made up of each team member’s personal space where the individual team member’s interactive thinking occurs and human factors are formed. This is the individual team member’s space to do with as they choose. They make up the rules and decide the direction they will go. From this space team members choose how they will interact with others on a day-to-day basis; even from one issue to another. Much of how we react is determined by how and where we were raised, what cultural beliefs values are, and our individual personalities. This is the space that the PM must learn as much as they can about the individual team member in order to effectively manage them. From this space the PM can learn what it takes to motivate the team member thus allowing the manager to better direct them so that it meets that motivational factor (Wong, 2007)

Motivation

Project team members come from diverse backgrounds. Each has their own expectations, and individual objectives that they want to meet. The overall success of the project depends upon the project team’s commitment.  This commitment is directly related to their level of motivation. Motivating your team in a project involves creating an environment to enable your team to meet project objectives while also enabling them to meet their objectives and what they value most. These values will likely include job satisfaction, challenging work, a sense of accomplishment, achievement and growth, perhaps even money.
The PM has to determine how best to meet the need of each team member by learning what does motivate each of them. One way to do this is by listening every day to how they respond to different interactions. Meeting with each team member individually will be time consuming in the beginning, but will prove to beneficial later in the project when you get to crunch time. By learning early on what it takes to motivate that team member the leader will be able to know how to ask them to step up to the plate when it becomes necessary (Spreitzer & Quinn, 2001).

One motivation tool to use is letting your team do their own communicating with stakeholders, so long as they can do so reliably. What this does is to build confidence in the team member that you as the leader believe in their ability to do their job. If the PM is constantly hovering over the team member, especially in meetings with business Subject Matter Experts (SME), interrupting and over explaining, it brings a level of distrust in to the relationship. The PM has to allow for the team member to rise or fall on their own. Setting the expectation that the team member has to work with the SME’s raising the level of confidence in the team member. More importantly; it takes a load of work off of the PM by letting the team do their jobs.

Communication

Today, business is changing faster than ever, and most of those changes are being implemented through projects that require even stronger project management. However, just using sound project management methods does not ensure success, as many a PM has learned. Many PM’s have learned that while their project is a technical success; everything works as the business requirements document, the functional requirements documents, and the technical drawings stated; but the project is deemed a failure because it didn’t meet the business objectives of the company (Campbell, 2009).

The biggest reason a project fails was because communication, identified as one of the single biggest reasons for project success or failure, failed. Real communication is essential not only within the project team, but between the PM, team members, and all external stakeholders. Open communication is the opening to building team, creating teamwork and getting high performance from team members as well as your stakeholders. Communications helps build relationships among project team members which helps to create mutual trust. Building trustful relationships helps to move the project along enabling it to meet the goals and objectives all have agreed to. The PM needs to be aware of the communication styles of all involved in the project; He needs to know the cultural nuances/ norms, relationships, personalities, and the overall context of the situation in order to communicate effectively. Awareness of these factors leads to mutual understanding and thus to effective communication. Identifying various channels of communications helps the PM to better understand what information they need to provide, what information they need to receive, and the interpersonal skills that will help them communicate successfully with various project stakeholders.

Stakeholder satisfaction can be met through a clearly defined project scope. In the scope the object and the goals of the project need to be clearly defined to meet the expectations of the business and the stakeholders. Ultimately they are the ones who approve the scope of the project. The PM needs to ensure that the scope defines how the object of the project will be met. He needs to ask and get answered the question of what is the purpose of the project: What need or problem is the project supposed to fulfil or solve? What business outcome is the end result?

The definition of the scope is the first means by which the team begins to make the connection between the stated business goal and the means by which to achieve that goal. One of the tools that incorporate the scope is the project plan, including the Work Breakdown Structure (WBS). In the WBS the project team defines the work needed to achieve the business goal. It breaks the work down into manageable work packages, sometimes referred to as activities. The duration of time it takes to perform these work packages is estimated which ultimately helps to formulate our budget. The stakeholders will have to review and approve the WBS, the budget, and the schedule that gets produced. All this activity brings a greater understanding of the strategic business goal of the project.

With the Communication plan the project determines what types of communication would be required including status reports, Business Requirements documents, Functional Requirement documents, Project Plan, Project Schedule, Financial Communications, and as you can see, the forms and types of communication are many (Westland, 2006).

Many of these types of communication were determined by utilizing other documents such as the Stakeholder Register, the Charter and Scope, as well as the project management plan.

Projects can develop what is commonly known as a Project Management Plan (PMP). The PMP helps put all the relevant structure under one document; it helps us to define how we were going to communicate; manage certain events in the project such as change management, and risks: Verzuh points out that the Change Management Plan should be tailored to fit your specific function (Verzuh, 2009). And he’s right because it is not one size fits all in Project Management.

PM’s should carry out team building activities to help determine and understand team member styles of communication such as by email, phone, types of reports, texting; this allows managers to plan their communications with understanding towards relationships and cultural differences. Listening is always an important part of communication. Both active and passive listening techniques give the user awareness of problem areas, management strategies for conflict and negotiations, decision making, and problem resolution.

What happens if you ignore project communications? You do so at your own risk. As stated earlier, many projects fail due to poor communications. Poor communications could be the result of weak leadership. Not wanting to be the bearer of bad news you will hope the issue goes away. Of course it never does go away. The issue just becomes worse until when you finally decide you need to tell upper management, it’s too late to solve the issue except at tremendous cost of time and money. You, as the PM, look bad because it’s your job to raise these issues so that can be solved; obviously the earlier the better. Part of your job is to solve these problems. Being the bearer of bad news comes with the job. The PM cannot be afraid to raise the red flag when a management decision is the only way to resolve the issue.

One area of communication the PM should consider is with the key roles of members of the project. Would your Business Systems Analyst be able to connect with business stakeholders? Can the Tech Lead deal with outside vendors in communicating technical requirements? Good salespeople learn early on that they can land a sale if they bring in a Subject Matter Expert (SME) to talk with the customer. It’s not like the sales person, or PM, doesn’t have the technical know-how; it’s that the business stakeholder, or customer, will have a tendency to believe the SME over the PM or sales person. The PM has to realize that if what it takes is the SME talking with the stakeholder to get the issue resolved, so be it. True leadership never lets their ego get in the way.

Political and cultural awareness

Politics are inevitable in projects due to the variety of backgrounds, and expectations of the people involved with a project. Skillful use of politics and power helps the PM to bring the project to a successful end. Ignoring or avoiding project politics and incorrect use of power can mean trouble in managing projects. Because PM’s operate globally in many projects, and many projects operate with a mix of cultures they are expected to be to handle a multitude of different situations. By being appreciative and make the most of cultural differences, the PM is more likely to create an atmosphere of mutual trust and a highly performing atmosphere. Cultural differences are not just individual; they can be corporate in nature and may involve internal and external stakeholders. One way to manage cultural variety is getting to know the various team members and developing good communication plan goes a long way towards reaching that goal. Culture behavioral includes those behaviors and expectations that occur outside of geography, ethnicity, or language differences. Culture can either slow or increase the speed of working, decision-making process, and the urge to act without appropriate planning or permission. Conflict and stress can occur in some organizations as a result of these differences unless addressed appropriately (Kerzner, 2001).

Politics, handled effectively, can help smooth the road in a project. Depending on the level in the hierarchy your sponsor has can be the difference between moving forward with the tools and the authority needed or finding brick walls in front of you. Having a sponsor of equal footing within the hierarchy of the organization with other department managers makes bringing in the big gun easier if needed. Having upper management support certainly helps to remove a lot of political obstacles as it gives greater authority to the PM. If the CEO of the company is supporting your project everyone in the company knows it and will usually bend over backwards to ensure you get what you need to reach the project goal.

Negotiation

Negotiation is a strategy of consulting with various parties of shared interests with a view toward reaching an agreement. Negotiation is an important part of project management and if done well, increases the chances of project success. The following skills and behaviors are useful in negotiating successfully: Analyzing the situation, and differentiating wants and needs. By focusing on the interests and issues rather than on positions you stand a chance of concluding successful negotiations. Be realistic when negotiating: ask high and offer low. When conceding, make it sound like a really valuable concession, don’t just hand it to them. The negotiations should always be a win-win proposition (Katz, 2009).

Influencing

Influencing is a method of distributing power by relying on your interpersonal skills to get others to move towards common goals. The PM should always lead by example, and follow through with commitments. Do what you promise to do, always. Clarify how decisions will be made in the project or when considering an issue or conflict. Use a flexible interpersonal style and adjust the style to the audience. Apply your power skillfully and cautiously. Think of long-term collaboration or effects on the project.

Decision Making Styles

There are four basic decision styles normally used by PM’s: command, consultation, consensus, and coin flip (random). There are four major factors that affect the decision style: time constraints, trust, quality, and acceptance. PM’s may make decisions individually, or they may involve the project team in the decision-making process. PM’s and project teams use a decision-making model or process such as the six-phase decision model (PMBOK, 2013):

•    Problem Definition; Fully explore, clarify, and define the problem.
•    Problem Solution Generation: Prolong the new idea-generating process by brainstorming multiple solutions and discouraging premature decisions.
•    Ideas to Action: Define evaluation criteria, rate pros and cons of alternatives, select best solution.
•    Solution Action Planning: Involve key participants to gain acceptance and commitment to making the solution work.
•    Solution Evaluation Planning: Perform post-implementation analysis, evaluation, and lessons learned.
•    Evaluation of the Outcome and Process: Evaluate how well the problem was solved or project goals were achieved (extension of previous phase).

Trust

The ability to build trust across the project team and other key stakeholders is a critical component in team leadership. Trust is connected to cooperation, information sharing, and problem resolution. Without trust it is near impossible to establish the positive relationships necessary between the various stakeholders engaged in the project. When trust is compromised, relationships deteriorate, people disengage, and collaboration becomes near impossible. Some actions PM’s can take to help build trust (Verzuh, 2012):

1.    Engage in open and direct communications to resolve problems.
2.    Keep all stakeholders informed, especially when fulfilling commitments is at risk.
3.    Spend time directly engaged with the team asking non-assumptive questions to gain a better understanding of the situations affecting the team.
4.    Be direct and explicit about what you need or expect.
5.    Do not withhold information out of a fear of being wrong, be willing to share information admitting you may be wrong.
6.    Be open to innovation and address any issues or concerns in an upfront manner.
7.    Look beyond your own interests.
8.    Demonstrate a true concern for others and avoid engaging in non-productive pursuits detrimental to the project or others.

Conflict

Conflict is inevitable in a project environment. Incongruent requirements, competition for resources, breakdowns in communications, and many other factors could become sources of conflict. Within a project’s environment, conflict may yield dysfunctional outcomes. However, if actively managed, conflicts can actually help the team arrive at a better solution. The PM must be able to identify the causes for conflict and then actively manage the conflict thus minimizing potential negative impacts. The project team is then able to deliver better solutions and increase the probability of project success. PM’s have to develop the skills and experience necessary to effectively manage to the situation. Managing conflict in a projects involves building trust with all involved parties early in the project; being open and honest, and to seek a positive resolution to the situation causing the conflict. PM’s make every effort to establish a collaborative approach among the team members to achieve full resolution of the problems. When the collaborative approach isn’t working, the PM must then use other methods for handling the conflict; forcefulness, accommodation, avoidance, or compromise. Managing conflict is one of the biggest challenges a PM must deal with on a regular basis. It requires use of all the other interpersonal skills of a PM in order to bring the conflict to a successful conclusion (Kerzner, 2001).

Coaching

Coaching helps propel the project team to higher levels of adeptness and performance. Coaching is about helping people realize their abilities through enablement and growth. It aids team members in enhancing their skills that could lead to project success. Coaching can take many forms and styles. In many instances, informal training is used to increase technical skills. Most companies expect that a minimal amount of coaching should be used since they think they’re buying the expertise already. Most coaching happens in one-on-one situations of the moment and the PM needs to know when to apply it.

Conclusion

The PM must reach deep into their experiences and training in order to effectively lead. PM’s are very unique people, but they’re not born leaders; they have to learn and experience it in order to practice it effectively. They’re expected to bring the project to a successful conclusion while meeting the needs of the business. They’re expected to bring the project to a successful conclusion on time and within budget. As stated earlier, the expectation levels are pretty high and the pressure can be extreme. It takes a special kind of leader to bring together an idea and make it all work together. PM’s are the boss of no one; yet are expected to get people to do what needs to be done and are held responsible if they don’t succeed. They have to bring together a group of people who have likely never worked together before and make it so they are a well-oiled machine working together. Depending on the size and nature of the project, that could be a lot to ask of any one individual. But by putting the right person with the right project one can expect that it will end successfully. That person needs to have experience in many different facets of people and technical know-how as well as a healthy amount of business acumen. Without these the PM as a leader will likely fail. With them, they can go far.

References:

Campbell, G. M. (2009). Communications skills for project managers. New York: AMACOM.
Covey, S. R. (2004). The 7 Habits of highly effective people: The 8th habit. Chagrin Falls, OH: Findaway World.
Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.
Hesselbein, F., & Johnston, R. (2002). On leading change: A leader to leader guide. San Francisco: Jossey-Bass.
Katz, R. L. (2009). Skills of an effective administrator. Boston, MA: Harvard Business Press.
Kerzner, H. (2001). Conflict Project Management: A systems approach to planning, scheduling and controlling. Hoboken, NJ: John Wiley & Sons, Inc.
Kerzner, H. (2001). Project management: A systems approach to planning, scheduling, and controlling. New York: John Wiley.
Kouzes, J. M., & Posner, B. Z. (1987). The leadership challenge: How to get extraordinary things done in organizations. San Francisco: Jossey-Bass.
Northouse, P. G. (2004). Leadership: Theory and practice. Thousand Oaks, CA: Sage
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Tichy, N. M., & Cohen, E. B. (1997). The leadership engine: How winning companies build leaders at every level. New York, NY: Harper Business.
Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin. doi:10.1037/h0022100
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.
Westland, J. (2006). The project management life cycle: A complete step-by-step methodology for initiating, planning, executing and closing the project successfully. London: Kogan Page.
Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Risk Management: A Discussion

Having spent over 20 years in project management I have had the opportunity to determine risk in my projects many times over. In some companies I have worked for risk would be identified, analyzed, and a mitigation plan would be created. The risks would be carefully watched and acted upon should it become an issue. Other companies would allude to risks, even list them, but stop there with no further attention. They figured they had covered their bases and need not do any more. As Verzuh points out, risk management needs to be systematically approached (Verzuh, 2012). If a lackadaisical approach is taken it will show when a risk becomes an issue and there is no plan in place to handle that risk.

Risk Management is Beneficial
Risk management is used to diminish possible threats to your project. One project contract I worked was for Uline, Inc. out of Pleasant Prairie, WI. Uline is a distributor of shipping products. They supply everything from bubble wrap to boxes. They create a huge catalog that is mailed to over 30 million customers in North America twice a year. Their eCommerce website looks just like the catalog. It looks that way because the owner, Liz Uihlein insists on it. In fact, I was told it was near impossible to get her to change that look. Uline does over $3 billion in revenue per year, 54% comes from online sales.

I was tasked with developing a project plan for redesigning the UX for their eCommerce site. Upper management had gotten permission from Mrs. Uihlein to remove a left side column that had been used for advertising. This meant a major restructuring of the site. The management team also knew they needed to develop a detailed plan to manage this project successfully.

One of the first tasks I worked on in creating this project plan was discussing the importance of defining risk. What I try to point out to my team is that risk is not as painful a process as they believed. Verzuh points out that the easy risks are the ones we know. He called these known unknowns because we know they’re potential problems, we just don’t know if or when they will occur (Verzuh, 2012). With Uline we had plenty of known unknowns. Verzuh also points out the unknown unknowns, those problems that happen unexpectedly (Verzuh, 2012). In Uline’s case there were no unknown unknowns, but I wanted to plan for them so we would be prepared in case something happened, which inevitably it does.

Creating a List
Planning is a great source for determining potential risk in your project. As requirements are gathered you begin to create a Functional Requirements Document (FRD) based on the Business Requirements Document (BRD) (Westland, 2006). Creating these documents involves many resources such as technical leads, systems architects, UX designers, Business Systems Analyst (BSA) and Business Analyst (BA) as well as subject matter experts from the business.

You can do all the brainstorming sessions you want, but from my experience nothing brings out potential risks more than determining what functionality is needed to create the business requirement. Verzuh even points out that detailed planning is an opportunity to discover risks (Verzuh, 2011). In these documents we describe what the system is supposed to do, how it is supposed to work. We begin to identify what capabilities are needed to meet those requirements.  We start to create the work breakdown structure (WBS) that defines each of the tasks required to accomplish the requirement. We create the WBS dictionary that describes the work, the assumptions and constraints in great detail (PMBOK, 2013).

Other documents we used to gather input from included the Scope document, the Charter, the project schedule, the stakeholder register, the quality management plan as well as activity cost and duration estimates (PMBOK, 2013).

As the requirements, scope definition documents, WBS, and other project data started to take shape, we began to develop a list of specific issues, concerns, and risks related to the scope and deliverables of the project. It was here that we started to identify and catalog those risks using a risk register. We developed a series of questions that helped us to further identify risks called a Risk Profile:
•    How many teams work on a given task from start to finish?
•    How much time do they devote to each task?
•    How does the task get passed over to the next team?
•    Is there a method for tracking each web page?
•    How does each web page get approved?

These were just some of the questions we asked, but from these questions we could identify potential risks; bottlenecks in the system for instance, that could cause the progress of the project to slow down.
A good risk profile is industry and organization specific, and according to Verzuh, it should address both product and management risks (Verzuh, 2012). One major specific concern to the organization of Uline was the time it took to complete tasks due to its cumbersome work/approval process. We determined that a web page from start to finish was touched by no less the 34 hands plus 10 approvers. The company had never put into place any mechanism for tracking where in the process a given page was at any given moment. A common complaint was trying to locate who had a page, who was supposed to get it next, and if it had been approved.

Ranking the Risks
As we developed the WBS we identified many risks, and while developing the WBS we would analyze each of those risks. The team would assign a probability to each risk, asking how likely it was that this risk would occur?  We entered this information into a Risk and Impact Matrix which helped us to categorize the risks from highest potential to lowest potential. By ranking the risks we were able to determine which risks we needed to concentrate on first and which ones could wait till we learned more from requirements definition. This helped to save time and we could concentrate on the crucial risks for developing our response in the event that risk turned into an issue. Mitigation plans were developed for those risks with the highest probability of occuring. PMBOK (2013) describes this process of prioritizing risks for further analysis as quantitative analysis.  We didn’t get real fancy about it. We used a simple numbering system with a range from 1-10 with 10 being the highest rank, to rank the risk. By definition the difference between a risk and issue is that a risk is an issue that hasn’t occurred.

Describing the Risk
So, documenting risks is crucial. But getting the team to take the time to document is the challenge. Many of the risks were initially written simply as “There is a risk that a document won’t be approved”. And the mitigation plan was: “We will monitor it”. The actual risk was that at any given moment a web page could sit on an approver’s desk for more than the planned for duration which was one day. The question was how do you hasten the process along should this event occur? Just as important: How do identify its occurrence?
In the risk register we had a column for stating/describing the risk. In this column we succinctly described the potential risk so that anyone could clearly understand what the risk was. We described the impact this could have on the project if it occurred. We identified the teams impacted by this risk. We categorized each risk by what department and the type of impact; scope, schedule, budget. Each risk was given an id number so we could easily track it.

An Example
We had identified a risk as the bottle neck that could occur in the work/approval process. We had ranked this risk as highly likely to occur. Our first risk: The approval process could be held up due to an approver not completing their task within the planned for duration. A second risk: The project not knowing the location of a web page at any given moment in the process. Our mitigation plan addressed the need for a method to identify the location of a web page at a given moment in the entire process that was available to the team and was in real time. We needed to map out the entire process from end to end. We proposed building an application that would allow handlers of the web pages to indicate that they had just passed a web page along to the next handler. The thought here is that everyone likes to get tasks off their desk but are not so willing to indicate right away that they just received the assigned document. So, the responsibility of indicating in the system was given to the passer rather than the receiver. Now it was incumbent upon the receiver to want to become a passer. That application would show where the document was, when it was received, thus how long the receiver had it in their possession. It would also allow for the page to be approved in order of approver to show all the completed approved documents had been done according to company hierarchy. Thus our mitigation plan for identifying a bottleneck minimized the chances of the risk occurring was to build an application that helped us to administer the process.

Contingency Plan
Once we had properly identified, analyzed, prioritized, created a set of preventative actions to reduce the likelihood of a risk occurring, developed a response to mitigate should a risk occur, we had to determine what the costs of our preventive actions and/or responses was going to be. In the case of creating the application for tracking a web page, it was how many hours it would take to create the application? Thus more iteration as we had to plan the applications functionality and design, we had to identify/define/mitigate the risks associated with this side project as it would be handled by a different team. Verzuh(2012) and Kendrick (2009) both point out that risk management happens repeatedly throughout the project, that risk management is truly an iterative process. Our contingency plan included money in the budget that could only be expended if the event occurred. We had to keep in mind that this was money that would be tied up for the life of the project or until the threat of the risk passed. The contingency plan also identified ways in which to adjust the schedule so as to minimize any affects to it if the risk occurs.
Contingency plans are like insurance; they’re nice to have in case something happens. Just remember they don’t come cheap. You will be tying up that money in the contingency fund for the life of the project or until the risk becomes a moot issue.

Managing the Risk
We realized early on in the planning of this project that we would need to continuously plan for risk. We knew that we needed to create a plan that not only would have a process for identifying future risk, but would also include how we would analyze it, prioritize it, categorize it, deal with it; in other words, how we manage future risks. By documenting this process you are working towards minimizing any potential unknown unknowns that could have an impact on the project. Even though we had not identified any unknown unknowns, that didn’t mean they didn’t exist. A portion of our contingency funds were just for those unknown unknowns.  We realized that if it could go wrong, it would. And in this project there was much that could go wrong.

Risk Register
As discussed earlier, we had created a risk register. This tool would be used to track our risks as the project progressed. We used the information gathered during our planning to fill out the form. Such information as the risk identifier, risk description, status, risk cause, the probability of occurring, the impact on the project should the risk become an issue, the risk score, and our response (mitigation). It included spaces for revised probabilities, impacts and scores should conditions change. The register also showed who was responsible for tracking a risk. The communication plan called for making the risk register an agenda item for each team status meeting. Making the risk register an agenda item meant the risks would be monitored closely. The object was to make sure the team was doing the planned work to minimize the effect or responded quickly to minimize any effect on the project should a risk occur.  What the responsible member of the team will be looking for is the trigger event signifying the occurrence of the risk. Once this trigger is pulled we can begin to enact the mitigation plan we have in place.

Conclusion
A number of stakeholders would rather avoid risk analysis altogether. I think a major part of a Project Managers job is to ensure the proper planning for the eventuality of a risk occurring. This is a far better reaction to a risk then avoidance. The problem here is that avoidance may mean changing the scope of the project opting instead for a less than satisfactory solution. As in investing, there is a reason why low/risk securities have a low return. Remember that the harder the risk is to detect, and the larger its impact, the greater cost required in higher contingency dollars and time. One need only imagine the cost incurred for failing to plan for risk when that risk occurs.

In Uline’s case, the biggest risk was a bottle neck being created due to the approving process. We put into place a mitigation plan to minimize the impact which would be implemented thus minimizing the impact greatly.

Risks need to be planned for. If they’re not planned for, if they’re not well thought out, and they’re not communicated to all stakeholders, then your project is doomed to failure.

References:
Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project. New York: AMACON.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.
Westland, J. (2006). The project management life cycle: A complete step-by-step methodology for initiating, planning, executing and closing the project successfully. London: Kogan Page.