Tag: Project Management

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.

Earned Value Project Management

Abstract
Earned Value Project Management (EVPM) can be used very effectively in a typical software development project. This paper, by examining the process briefly step-by-step, will show how easy and effective the earned value process can be to a project. I am currently applying EVPM to my projects at work so I will be including real-life examples to show how effective EVPM is at managing progress in a project and showing its true status at any given time in the project.

Introduction

Earned Value Project Management (EVPM) has been bemoaned as being too much work with limited value. I get many resources that push back at me saying that there is too much documentation for little return. They have trouble seeing the value that EVPM brings to a project. Earned Value Project Management (EVPM) is a project management technique for measuring project performance and progress in an objective manner. It is a disciplined approach to ensuring that the project stays on course, on time, within scope and that it actually is getting its dollars’ worth. EVPM is a systematic process that uses earned value as the primary tool for integrating cost, schedule, technical performance management, and risk management (Kerzner, 2009). EVPM can determine the true status of a project at any given point in the project, but only if the rules for organizing the project are followed. This requires a disciplined approach.

What I will show in this discussion is how effectively EVPM can be on any size project, from $50,000.00 and up and how I have used EVPM on projects with resources both on-shore and off-shore. I will show you step-by-step from the initiation to the closing phase how effectively EVPM can help a Project Manager keep their project on track.

A Brief Look Back

EVPM got its start back in the late 1800’s when industrial engineers on the factory floors in the U.S. wanted to measure their production performance. These engineers created a three dimensional way to measure the performance of work done on the factory floor. They created a baseline called planned standards, and then they measured earned standards at a given point against the actual expenses to measure the performance of the factory. Today, their formula is the most basic form of earned value management today (Fleming & Koppelman, 2010).

Approximately forty years later the U.S. Navy introduced PERT (Program Evaluation Review Technique) to industry as a scheduling and risk management tool. The idea was to promote the use of logic flow diagrams in project planning and to measure the statistical success of using these flow diagrams. It didn’t last very long because it was cumbersome to apply.

Critical Path Method (CPM) was created by DuPont engineer Morgan R. Walker when he looked into developing a method that would improve the scheduling, rescheduling and progress reporting of the companies engineering programs. In 1957 Walker, with Remington computer expert James E. Kelley, Jr., developed a system using an arrow-diagram or network method which came to be known as the Critical Path Method (Archibald & Villoria, 1966). Pert/Cost would be introduced as a means in which to add into the network and manage both time and costs. Problem at the time was that computers had not become sophisticated enough to be able to support the concept.

But out of the Pert/Cost concept came the idea that you could measure earned value. The implementation of Pert/Cost in industry required eleven reporting formats, one of which was “Cost of Work Report” and within it there was a format called “value of work performed”. Pert/Cost standard lasted about three years, mostly due to its cumbersome use and industry not particularly liking being told what to do.

In 1965 the U.S. Air Force created a set of standards allowing it to oversee industry performance without it really telling industry what to do. What the Air Force did was to develop a series of broad base criteria and asked that industry satisfy these broad based criteria using their existing management systems. This developed into the C/SCSC (Cost/Schedule Control Systems Criteria) that every company wishing to do business with the government was required to meet.

And the results of these new criteria were impressive. But problems also arose. The original 35 criteria grew, at one point reaching 174, some being very rigid and dogmatic, mostly inflexible taking away from the original intent of being unobtrusive. In 1995 the National Defense Industrial Association rewrote the Department of Defense (DoD) formal earned value criteria and called the new list of 32 criteria the “Earned Value Management System” (EVMS) (Fleming & Koppelman, 2010). Eventually these new criteria would become part of the American National Standard Institute/Electronic Industries Alliance guidelines, what we normally call ANSI guidelines. And from this came a broad acceptance of the new criteria by industry.

Why Earned Value Project Management (EVPM)?

There are many reasons why EVPM should be used in every project. One reason is that EVPM provides a single management system that all projects should employ. The relationship of the work scheduled to the work completed provides a true gauge of whether one is meeting the goals of the project. The most critical association of what work was completed to how much money was spent to accomplish the work provides an accurate picture of the true performance cost.

EVPM requires the integration of the triple constraint: Scope, Cost, Time, allowing for the accurate measurement of integrated performance throughout the life of the project. Integration is a big issue in managing a project. Many times the project management team defines the project one way, the development teams another way, and further still QA will look at another way. Everyone is reading the same sheet of music, but they’re singing a different song. The requirement of the Work Breakdown Structure (WBS) has helped to bring alignment among the various teams impacted by the project. Its hierarchical structure helps to define the scope of the project in easily understood terminology to both the project team and the business sponsors.

Study after study conducted by the Department of Defense (DoD) shows that those projects using EVPM have demonstrated a pattern of consistent and predictable performance history (Fleming & Koppelman, 2010). The studies have shown that end results of projects using EVPM can be predicted as early as at the 15% -20% completion points. The ability to show at that early stage the direction your project is going allows the Project Manager to adjust course making corrections long before it is too late.

The development of a key metric called the “Cost Performance Index” (CPI), showing that acute relationship between the work actually completed and its matching budget, set against the actual costs spent to complete such work, allows management to constantly monitor the true cost performance of any project. In fact, the studies concluded the cumulative CPI didn’t change by more than 10% from the value at the 20% completion point (Christensen & Heise, 1993). I have used this metric successfully in many of my projects over the years. The Project Manager can deliver a forecast of the total funds required, or the Budget at Completion (BAC), by simply dividing the total project BAC by the cumulative CPI. This assumes that the actual cost performance results to date will likely continue to the end of the project. This is considered to be the best case forecast for a project within a statistical range of final cost estimates.

Another metric, “To Complete Performance Index”, concentrates on the remaining project tasks. It is the opposite of the cumulative CPI in that it reflects what it will take in future performance to recover from a negative actual cost position. The TCPI takes the work remaining, basically the total budget minus the work completed, and divides that by the funds remaining (the latest management financial goal less funds spent) to determine what it will take to complete the project.

One of the important benefits of using a performance measurement system is being able to determine how much of the scheduled work has actually been completed at any given point in the project. The basic issue is whether the project is on schedule, ahead of schedule, or behind schedule? And if you are behind schedule, by how far and what is the cost? Schedule performance knowledge like this is especially powerful when compared against the critical path of the project. Both the earned value Schedule Performance Index (SPI) and Critical Path Method (CPM) are metrics that, when used together, will correctly calculate the true schedule position of any project. Falling behind in getting the work scheduled completed is one of the first indicators of likely future problems. Project Managers do not like to fall behind schedule, even though a more important gauge is perhaps the performance against the project’s critical path. When one falls behind the planned work the tendency to add unplanned resources in an attempt to catch up can be quite strong. In essence, you’re doing the same work as was planned, but now you’ll be spending more money for the same amount of effort. Arbitrary decisions to catch up on the planned work can cause irreversible and non-recoverable damage to the project’s cost performance.

The employment of Management by Exception allows the portfolio or program managers to concentrate their efforts on those projects that are in trouble. Typically it means that those projects in the red get read, those in the green are of no concern. It allows managers to concentrate on the key metrics of CPI, SPI, TCPI, and EAC to determine if a project needs their help.

Must Have Documents in EVPM

There are three documents that every project must have, as a minimum, in order to employ EVPM:

The Scope

The most important document that can assure success in a project is the project scope document. EVPM cannot be effectively employed unless the Project Manager has defined the job to be done. It really is impossible to measure done if you don’t know what done means. The reason for EVPM is to be able to measure the work of the project as you are progressing. But you cannot know what to measure against unless you have defined the total scope of the project.

The scope, as defined by PMI, is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the product, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope (Project Management Institute, 2013).

The WBS

The WBS, as defined in PMI PMBOK, is a decomposition of the work deliverables into manageable work packages, it organizes and defines the total scope of the project (Project Management Institute, 2013). The WBS shows, in hierarchical form, each activity required to complete the project. These activities are organized into work packages of various duration’s, usually one day to one week. These packages are then aligned by precedent to determine a project schedule. The WBS will also include the resources that will be used to do the work on a particular package.

Project Schedule

The second requirement deals with the placement of the defined scope into a fixed time frame so that time performance can be measured throughout the life of the project. Some would suggest that these two rules are not unique to earned value project management, and that they are fundamental to all good project management, period. The project schedule is likely the best tool available for managing the day to day communications on any project. And further, one of the best ways to control a project plan is to monitor performance regularly with the use of a formal scheduling routine. Schedule the authorized work in a manner which describes the sequence of work and identifies the significant task dependencies required to meet the requirements of the program. Identify physical products, milestones, technical performance goals, or other indicators that will be used to measure progress. Identify, at least monthly, the significant differences between both planned and actual schedule performance and planned and actual cost performance, and provide the reasons for the variances in the detail needed by program management.

The Budget

Ultimately, you have to have a budget. Without knowing the costs of the different tasks that make up the project the Project Manager has nothing to use in which to measure against. These steps are particularly critical to an earned value project, because once the baseline has been put into place; the actual performance against the baseline will need to be measured regularly for the duration of the project. Regularly, on a periodic basis likely monthly, sometimes weekly, the Project Manager will want to measure how well the project is performing against the baseline. Project performance will be precisely measured employing earned value metrics, normally expressed as a cost or schedule performance variance from the baseline. Such variances will give an early warning of impending problems and are used to determine whether or not corrective action needs be taken in order for the project to stay within the defined parameters.

Baseline

Establishing a Performance Measurement Baseline (PMB), a baseline against which performance may be measured, is an essential requirement of earned value project management. The PMB is the reference point against which a project will measure its actual accomplished work. It will tell whether the project team is keeping up with the planned schedule, and how much work is being accomplished in relation to the monies being spent.

In Practice

Initiation and Project Estimations

I have discussed in a previous paper how the Software Development Lifecycle (SDLC) is implemented at Walgreens (Garling, 2015).  Each project starts out as an idea in which an idea form is submitted to the Intake Management Group. The idea form contains the proposed name of the project, the sponsoring department, the Single Point of Contact (SPOC), and the target date. A business case document, Business Requirements Document (BRD), and the Charter are spelled are also included. These documents provide a detailed description of the proposed project and are submitted with the idea form. These documents provide a very high level view of the proposed project.

The idea form is logged and an announcement goes out to the intake committee members with the intake documentation attached to the meeting invite. The object of this meeting is for the committee to discuss with the requestor what it is the business is asking to be done and why. The committee will go over the specifics of the request, in particular the scope and the BRD of the project. They try to determine which teams in the company will be impacted by the project proposal. The makeup of the committee includes representatives from the Point of Sale (POS) Retail Execution teams:  Development; Quality Assurance; eCommerce; Photo; Inventory Control; Payment Systems; Project Management Office (PMO); Key Performance Indicators (KPI); Electronic Data Warehouse (EDW), amongst others. The point here is that each group is represented to review the idea and to determine which of these various groups may be impacted by the proposed idea.

Phased Approach to Determine Project Costs – Phase Zero

Keep in mind that the Intake Committee is the first step to becoming an official project. If the idea is accepted by the Intake Committee, it is assigned to a Project Manager to help guide the proposed project along to determine the high level affect in time and dollars leading to an E0 estimation document. The E0 Estimation documents what the different teams impacted by the proposed project think, at a very high level, will the cost in dollars and time to do their portion of the project. This estimation is always at a +/-50% range. Much of the estimation is based on past experience of doing similar projects. If it’s a go, then the project is approved by the business sponsors.

At this point the Project Manager has used two methods in developing a project that can utilize EVPM methods: The scope of the project and Bottom-Up-Estimating. Each department impacted by the project delivers its estimation and the Project Manager adds them up. From the time the proposed project is assigned to the Project Manager, his main responsibility is to bring the identified impacted teams together to create a high level estimation of the time and cost of the work required to implement the proposed idea. This requires a well-defined and written scope. This estimation is based on a range of +/- 50%. So, if the QA team estimates it would take 2350 hours to go through the quality assurance process required by Walgreens, it would be quoted as a range from 1175 hours to 3525 hours. Walgreens usually uses a blended hourly rate to determine monetary costs.

The scope of the project is of utmost importance to EVPM. As stated early, you cannot properly plan a project unless you know the scope of the project. After all, how are you going to know when you’re done if you don’t know what you’re doing? Since EVPM is heavily dependent on time and cost, if you don’t define the scope you can never get to how long it will take and thus arrive at a measurable cost.

At Walgreens we keep in mind that at this point in the process we do not know the requirements in great detail. We use phased planning to define the scope and plan out the projects. Each phase serves as a gateway to the next phase causing the business and the PMO to determine if the project should move forward. In between each phase the project team is forming where members from each impacted team is assigned to the project. Their time is tracked in a software application known as PlanWell. PlanWell is an application that tries to mimic MS Project.

As I said earlier, Phase Zero determines go or no go with an estimation of +/- 50%.  Phase Zero includes the Business Case document, the BRD, the Project Charter, a high level scope document and the E0 Estimation document. By approving the Phase Zero estimation the business sponsor has to set aside monies up to the upper limit of the estimation range.

At this point the project team has to prepare to present the project to an executive group called the IT Hub group. The IT Hub group will use the same documentation as the E0 estimation to determine if the project fits into the overall strategic goals of the company. This group is comprised of the management teams from each of the divisions within Walgreens. The IT Hub is a newcomer to the decision process. Walgreens has begun to recognize the importance of making sure these projects actually fit into the overall strategy of the company, especially with the recent merger with Boots. At this point in the IT Hubs development this will be the only time it reviews the project. If the IT Hub disapproves of the project, the project will be canceled.

Phase One

Phase One begins to determine detailed requirements. It produces the initial Functional Requirements Documents (FRD); provides more detailed information on the scope of the project; the project plan is developed; a Work Breakdown Structure (WBS) begins to be detailed out with the tasks and activities needed to complete the project; a more detailed BRD; creation of the project in PlanWell; the Project Management Plan (PMP) details the Communication Plan, the Risk Management Plan, the Change Request plan, the Document Management plan; all of these documents help to bring the team to the point of submitting what’s called an E1 Estimation. The E1 Estimation document tells the business that the team feels confident enough to estimate the cost of the project to within +/- 25%.

At this point a gateway meeting is held with the business sponsors, the PMO office, and representatives from each of the identified impacted teams. Their sole job in Phase One is to review the documentation put together by the project team and give a go/no go signal.

As the project team progressed with the analysis of the requirements of the project they were creating several important documents and information pertinent to using EVPM: The scope of the project; the WBS; and Functional Requirements Documents (FRD’s). Each of these documents would help to create the information needed to use key metrics in EVPM.

The team needed to determine the scope so that they could define the tasks needed to fulfill the scope requirements. From these tasks the team could determine the order in which each needed to be completed. They were especially interested in determining dependencies. Once they had determined the order of the tasks they could then determine the duration for each task and how many resources were needed for each task. Keep in mind that the number of resources could change if we determined that adding or subtracting helped with meeting our target date or our target cost.

From the completed WBS we would be able to create a schedule. The duration of each task can be converted into costs by taking the estimated duration and multiply by the blended hourly costs. Now we are able to determine Planned Value (PV) and eventually our Budget-at-Completion (BAC).

Phase Two

Phase Two brings the project team to the point of submitting an E2 Estimation, which is the final cost and time estimation delivered to the business. The project team is telling the business that it feels confident enough that it can bring this project together to a successful conclusion to within +/- 10%. By this time all project documentation has been created and approved. The scope document has been frozen with any changes requiring implementation of the Change Request process. All final FRD’s and TDD’s have been submitted, and the teams are ready to start the final phase: development.

Status Reporting

Each month the accounting department delivers to the PMO the monthly financial report through PlanWell. This report details the costs by project, by phase in the project, and by department. The Project Manager has to take this information and create what is called the monthly financial reports to each department and to the sponsoring business.

The financial report explains to the departments the financial status of their portion of the project, and explains to the sponsoring business unit the overall financial status of the project. The financial report shows the approved budget (PV), the actual spent for the project (AC), the remaining budget needed (ETC) and the Total Estimated Cost (EAC).

The project will also begin producing a weekly status report and possibly a monthly executive report. These reports contain a short summary of the project status, financial updates, what the project completed during the reporting period, and what it has planned to accomplish during the next reporting period. The length and detail of the information depends on the audience.

Project Performance Metrics

Once development begins, the Project Manager starts to use Project Performance Metrics (PPM) used in EVPM. The PPM measures project management performance compared to the approved budget and committed delivery date. The goal for Project Manager is to deliver projects within 10% of their budgeted work effort and within 10 calendar days of the agreed upon delivery date. The metrics are rolled up to the various management levels to measure project management performance at each level.

The key requirements for this metric are that projects are baselined at the appropriate time, and finding the true reason for any baseline change. The performance baseline work effort and go-live date are captured by the PMO, and the actual hours are captured using time sheets in the PlanWell project management system.

These PPM metrics are communicated to managers and above in the weekly status reports and the monthly executive status report. Two very important documents in the project are the project plan schedule and the WBS.

Included with the WBS is a document that further defines each work package activity of the WBS known as a WBS Dictionary. The WBS Dictionary includes a detailed description of the work to be done, what activity precedes and succeeds the activity. It also lists dependencies within and outside of the project, such as corporate servers that may be needed to house the result of the work package. It also lists the resource(s) responsible for developing the work package and the duration level of effort, usually in hourly units, to accomplish the work. The WBS Dictionary, at Walgreens, includes the blended hourly rate for the resource ($57/hour). Contractors at Walgreens are not allowed to know the exact rate of resources.

From the WBS and the project schedule we can use the following metrics that make up the PPM used in EVPM:

Planned Value (PV)

The Planned Value (PV): The PV, sometimes referred to as the Budgeted Cost of Work Scheduled (BCWS), is the authorized budgeted cost for a given work package. It is sometimes referred to as the performance measurement baseline (PMB) and the total PV project is known as Budget-at-Completion (BAC). It is made up of the planned duration and cost for the activity.

For example, let’s say that a given activity or work package is determined to take two resources five days to accomplish. Each resource cost is $57.00 per hour. Each work day is regularly scheduled for eight hours Monday through Friday. With two resources performing the work, that would come to a total of sixteen hours per day. Since it will take five days to complete the work, our costs would come to a total of $4560.00 (80 hours x $57.00).

Earned Value (EV)

The Earned Value (EV), sometimes referred to as the Budgeted Cost of Work Performed (BCWP), is the value of the authorized budgeted amount at a given point in the project. Using our above example, where each resource cost is $57.00 per hour, and each work day is eight hours per day Monday through Friday, by day three in the schedule for this activity the Project Manager  would have the expectation that EV would equal $2736.00 worth of work had been completed according to the plan.

Actual Cost (AC)

The Actual Cost (AC), sometimes referred to as the Actual Cost of Work Performed (ACWP), is determined by the number of hours multiplied by the blended rate of $57.00 per hour. As each resource completes the day’s work they’re required to clock their time into PlanWell against whatever project they were working that day. The time entered is in hourly units.

For example, let’s take our aforementioned work activity or work package that we determined would take two resources five days to accomplish. With each resource costing $57.00 per hour, and each work day is eight hours Monday through Friday, we know our PV should come to a total of $4560.00 (80 hours x $57.00). By day three in the schedule for this activity the Project Manager would have the expectation that $2736.00 PV of work has been completed according to the plan. But our AC came in at $3648.00, and they only accomplished two days of planned work.

According to the above scenario the project is overspending and behind schedule. In fact it was expected, by day three, to have cost the project a total of $2736.00 for 48 hours of work. The two resources have accomplished only two days of work at a cost of $3648.00. Using the Cost Variance (CV) formula we can determine where we stand at this point:

CV = EV – AC

Cost Variance (CV) is a way to determine cost performance on a project. It is equal to the Earned Value (EV) minus the Actual Costs (AC). This measurement is critical as it indicates the relationship of physical performance to actual costs.

In our examples case the formula would look like:

CV = $2736.00 – $3648.00 = -$912.00

Another way to look at the same relationship is through the Cost Performance Index (CPI). It is considered the more critical of the Earned Value Metrics. A value of less than 1.0 would mean you’re spending more then you’re getting, while a value greater than one means you’re spending less and getting more.

In our example the formula would look like:

CPI = EV/AC

CPI = $2736.00/$3648.00 = .75

As you can see, the project CPI is less than 1.0. Basically, the project is spending more than is getting done. The project is getting $.75 worth of work for every $1.00 spent.

Part of the monthly financial report is to show the department and the business what is needed to complete the project as far as cost is concerned. We use the Estimate-to-Complete (ETC) and the Estimate-at-Completion to indicate what is needed to complete the project.

We use the following formula to determine ETC:

ETC = BAC – EV

ETC = $4560.00 – $2736.00 = $1824.00

The above formula is used if we expect everything to be on time and on budget.

If we expect, as in the case of our example, that we’re neither on time nor within budget and we expect this track to continue then we would use the following formula to determine ETC:

ETC = (BAC – EV)/CPI

ETC = ($4560.00 – $2736.00)/.75 = $2432.00

Estimate-to-Complete is the amount of funds that will be needed to complete the project (Subramanian, V., & Ramachandran, R., 2010). The method used to calculate the amount depends on the circumstances. In our example it was expected that the variance we experienced would continue for the remainder of the project.

We will use the same logic for determining our Estimated-at-Completion costs in that the variances we have experienced will continue. Our formula we will use is as follows:

EAC = AC + [(BAC – EV) ÷ CPI]

EAC = $3648.00 + [($4560.00 – $2736.00))/.75)] = $6080.00

My EAC is equal to $6080.00 and my Variance-at-Completion (VAC) would be equal to:

VAC = BAC – EAC

VAC = $4560.00 – $6080.00 = -$1520.00

The report I would have to deliver to the business would like this:

Approved Budget (PV)    Total Budget    Actual Spent FY15 (AC)    Remaining Budget Needed (ETC)    Total Estimated Cost (EAC)    Est. Variance (VAC)
$4680.00                           $4680.00         $3648.00                             $2432.00                                               $6080.00                                   ($1520.00)

Conclusion:

As I’ve shown, the use of these metrics in EVPM gives us a fairly accurate picture of the status of the project on a monthly basis. Part of the problem we have at Walgreens is that the Project Manager is not given the previous month’s financial status of their project until the second week of the current month. What this means is that we’re basically a month behind when we learn of the bad news given in our example above. It can be very tough to fix the problem in our example when we don’t learn about it until six weeks later.

The object of EVPM is to give the Project Manager an accurate picture of the status of their project at any given moment so they can make corrections before matters get worse. By depriving them of basic information the company risks a successful conclusion to many of their projects. As you can see from our example, the numbers give us a pretty accurate picture of the status of the project. Using these metrics, in a timely fashion, gives the Project Manager the ability to control events quickly so that they can keep the project moving forward.

References:

Archibald, R. D., & Villoria, R. L. (1966). Network-based management systems (PERT/CPM). New York: Wiley.
Christensen, D. S., & Heise, S. R. (1993). Cost performance index stability. National Contract Management Association Journal.
Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square, PA: Project Management Institute.
Garling, R. (2015). project metrics week 7 paper. AMU
Lipke, W. H. (2009). Earned schedule: An extension to earned value management– for managing schedule performance. Raleigh, N.C.: Lulu Pub.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Subramanian, V., & Ramachandran, R. (2010). McGraw-Hill’s PMP certification mathematics: project management professional exam preparation. New York, NY: McGraw-Hill.
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

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.

The effects of activity time variance on critical path planning

A Critique of

Lanny A. Karns and Lloyd A. Swanson

Article

“The effects of activity time variance on critical path planning”


Table of Contents

Abstract

Introduction

Network Analysis: CPM & PERT

Conclusion

Abstract

Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT) are the two most commonly used networking techniques for defining the duration of project tasks. While they have much in common, they’re based on different concepts and both were independently developed. PERT defines a probabilistic distribution of activity time defined using three time estimates which emphasizes minimum project duration while downgrading cost restraints. CPM uses one deterministic time estimate emphasizes cost over time restraints. CPM is the most popular of the two methods as it is deemed easier. Lanny Karnes and Lloyd Swanson in their article “The effects of activity time variance on critical path planning“ advocate combining the two methods asserting they cannot be totally independent due to an obvious relationship between time and cost ( Karnes, 2007).

Introduction

It is well known that there are many techniques Project Managers can use to support better project planning. Critical Path Methodology (CPM) and Program Evaluation and Review Technique (PERT) are two such tools that ae used by many Project Managers. These two techniques, while derived independently of one another, cannot be totally independent due to an obvious relationship between time and cost. While CPM emphasizes cost over time restraints and PERT emphasizes time over costs restraints, perhaps there is a way to bring the two together. Karnes believes the best way to combine these two would be to put CPM’s crashing strategy together with PERT’s probability distribution of activity times come out with the best possible duration and cost for the project (Karnes, 2007).

The three estimates of PERT; optimistic, most likely, pessimistic, are combined to determine an expected duration and variance for each activity. These expected times are used to create the critical path and the variances are added to determine the project duration variance. From these numbers we can develop a probability distribution showing project completion times. The problem here is that if the activity variances lie outside the critical path then they’re not considered when determining the project variance. The fact that they’re not considered can lead to errors in determining total project duration. A similar issue can happen when using CPM’s crashing strategy where multiple paths through the network have similar or close lengths. If we drop the assumption of deterministic activity times and the duration is allowed to vary, a decrease in the length of the critical path may not result in a similar decrease in project duration because of variances inherent in parallel paths. Simply allowing activity times to vary; which inevitably they will do in real life, can result in serious problems with CPM’s crashing strategy leading to wasted time and money (Karnes, 2007).

Network Analysis: CPM & PERT

Using CPM and PERT for network analysis can provide invaluable information for planning, scheduling and executing projects. The main purpose of network planning is to avoid crisis management by using picture representations (graphs) showing the total project activities in a logical order. This aids in determining sequencing and duration of activities and the project. The following information can obtained from such a graphical picture (Kerzner, 2009):

  • Interdependencies of activities
  • Project completion time
  • Impact of late starts
  • Impact of early starts
  • Trade-offs between resources and time
  • Supposing exercises
  • Cost of a crashing
  • Performance Slippages
  • Performance Evaluation

CPM was mainly worried with creating activity prerequisites and determining simple network solutions. It was primarily useful for keeping track of activities and identifying activity conflicts or sequencing flexibilities which could affect project completion. Later on, cost slope analysis was developed as a way to calculate the shortest project time within the constraints of costs and time constraints. This technique was used to determine effective savings in time when it is possible to “crash” or shorten the individual activity times. The time actually saved is divided into the cost increase from compressing the activity to define the net cost slope. The slopes are compared to the costs to determine if reducing project duration will result in cost savings.

PERT was designed to overcome inherent problems in assuming activity time estimates deterministically. By coming up with three activity time estimates it allows the user to develop a probability distribution for the length of each activity. Once this is accomplished the user can calculate sequencing and network solutions in a manner similar to CPM. PERT is a management planning tool that can be used as road map where the activities have been identified along with interdependencies. A PERT chart is usually designed from back to front with the end date in mind (PMBOK, 2013).

Using both CPM and PERT, a Project Manager (PM) is able to determine, with some degree of accuracy, the overall length of the project by determining the duration of each activity. From this analysis the PM can also determine the interdependencies of each activity and thus is able to sequence these activities in a logical order. From this information the PM can determine the Critical Path of the project seeing those activities that have no slack in comparison to those that do have slack (lags and leads). Through network analysis the PM can determine how to better utilize resources more effectively and to track how the project progresses thus keeping effective control on time and costs.

Conclusion:

Combining the best of CPM and PERT can make it so that the PM can accurately estimate the amount of time and cost for each activity in the project. But, we have to keep in mind that these are still estimates. One can reasonably assume, through probabilistic analysis, how accurate these estimates are; it still needs to be taken with a grain of salt by keeping a watchful eye on the projects progress. PM’s have to keep in mind how difficult it is to get PERT’s three activity estimates from the subject matter experts or those who will perform the work. Probably part of the reason why many PM’s choose to use CPM over PERT is due to it being easier to determine duration from past history then to wrangle it out of software programmer.

References:

Karns, L. A., & Swanson, L. A. (2007). The effects of activity time variance on critical path planning. PMI. Retrieved from http://www.pmi.org/learning/time-variance-critical-path-planning-1959

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.

Project Planning: Improved approach incorporating uncertainty

A Critique of

Vahid Khodakarami, Norman E. Fenton, and Martin Neil

Article

“Project Planning: Improved approach incorporating uncertainty”


Table of Contents

Abstract

Introduction

CPM and Uncertainty

Bayesian Network

Conclusion

Abstract

Because of the unique nature of projects, there may be uncertainties or differences in the products, services, or results that the project creates. By its very definition a project and its activities can be new to members of a project team, generally necessitates more out-and-out planning than other routine work. It inevitably involves uncertainty. The basic inputs of time, cost, resources for planning are not deterministic and can be affected by uncertainty. Vahid Khodakarami, Norman E. Fenton, and Martin Neil feel there is a causal relationship between these uncertainty sources and project parameters and this causality isn’t considered in current project planning methodologies. In their paper they present an approach, using Bayesian network modelling that they feel addresses both uncertainty and causality in project management. And they show this using the Critical Path Method (CPM) to handle uncertainty and how you can manage different sources and parameters of uncertainty in project planning.

Introduction

It is well known that there are many techniques Project Managers can use to support better project planning. Critical Path Methodology (CPM) is one such tool that is used by many Project Managers. There are many ways to consider uncertainty in project planning. Group Creativity Techniques such as brainstorming, nominal group technique, idea/mind mapping, and affinity diagram, and multicriteria decision analysis all help to take uncertainty into consideration when planning a project. Khodakarami feels that these techniques rarely quantify uncertainty effectively. Their paper focuses on project scheduling and in risk management.

Risk management, while it includes identifying, analyzing and responding to potential risks by using mediation planning, it was felt that it pays too much attention to the positive events while minimizing the adverse events since the term risk is associated with events instead of uncertainty(Khodakarami, 2007).  In their article the authors point out that using Bayesian Networks in conjunction with CPM helps to address uncertainty in scheduling because it allows you to take into consideration many different knowns rather than speculating on unknowns.

CPM and Uncertainty

Risk management is highly important to project planning. If the PM doesn’t consider and plan for risks they’re only planning to fail. The current view of risk is restrictive when it comes to uncertainty because it looks at events rather than sources of uncertainty. One source of uncertainty is activity duration. Normally duration is determined by looking at past history and by talking with subject matter experts (SME). Much uncertainty comes from not knowing exactly how long it could take to actually complete a task. This uncertainty arises from not knowing resource availability, possible occurrence of identified risks, lack of prior experience and the subject nature of the data such as expert judgement.

Critical Path Methodology is a deterministic technique for determining scheduling. It calculates the critical path (CP) by outlining the network of dependencies between tasks and determines duration for each arriving at what the earliest time is the project could be completed. It has a starting task and determines the order of the tasks using dependency between the tasks drawing out a network diagram that shows the tasks and their dependencies. Using the estimated durations for each task the PM can determine the earliest and latest start times and finish times for each task. From this calculation the PM would be able to draw out the critical path because he would be able to see which set of tasks have no slack time between them. This is the critical path of all tasks that have to be completed with their given timeframe, all other tasks have flexible amount of time between them that should they start earlier or later it will have no effect on the overall project schedule.

The critical path can be calculated using the following formulas:

D – Duration

ES – earliest start time

EF – earliest finish time

LF – latest finish time

LS – latest start time

The earliest start and finish times are determined by working forward through the network diagram, determining the earliest time a task can start and finish using the start and finish time of its predecessors. The first task always starts with zero. The latest start and finish times can be determined by working backwards through the diagram.

Bayesian Network

Bayesian Networks provide decision-support for a wide range of problems involving uncertainty and probabilistic reasoning. It is a probabilistic graphical model that represents a set of random variables and their conditional dependencies. For example, it could represent the probabilistic relationships between diseases and symptoms. If symptoms are known, the network can be used to determine the probabilities of other various diseases (Wikipedia, 2015).

An example of a Bayesian Network could be:

Sprinkler        < – >         Rain

Wet grass

The main use of Bayesian Networks (BNs) would be for statistical probability outcomes. The idea is that the PM has a set of known events and they want to determine potential outcomes. BNs can explicitly quantify uncertainty, reason from effect to cause as well as vice-versa, make predictions from incomplete data, and combine objective and subjective data arriving at decisions based on visible auditable reasoning. resources’.

As the project advances duration of an activity becomes a known and by equating actual with predicted durations, the BNs can update the probable estimations for risks and resource usage and as such, this distribution can be used for later for estimating more accurately other activities with similar dependencies.

Conclusion:

Using BNs to help improve the planning process makes sense. It is better able to determine the probability of events occurring. Many current methods are too deterministic in their evaluations; CPM for example. But by combining CPM and BNs the PM can bring the power of BNs so that their plans schedules are more realistic and they’re better able to make an informed decision based on better information. But one has keep in mind from decision making under uncertainty is the risk that the project manager wishes to incur (Kerzner, 2009). Even with BNs being a better tool to use to narrow down uncertainty, it is still uncertainty.

References:

Bayesian network – Wikipedia, the free encyclopedia. (n.d.). Retrieved October 8, 2015, from https://en.wikipedia.org/wiki/Bayesian_network

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.

Khodakarami, V., & Fenton, N. (2007). Title: “Project Scheduling: Improved approach to incorporate uncertainty using Bayesian Networks. Project Management Journal, 38(2), 39-49.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Effective Management of Project Change Orders

A Critique of

Edward E. Douglas’s

Article

“Effective Management of Project Change Orders”


Table of Contents

Abstract

Introduction

Planning for Change

Planning and Design

Change during Application Build

Closeout

Conclusion

Abstract

Scope is the total sums of all the products/services that are required to complete a project (PMBOK, 2013). But even when the scope has been completed and a freeze is agreed upon, change occurs. Edward Douglas’s article “Effective management of project change orders” discusses how to effectively manage any requested changes that may come up during the life of the project. And while he concentrates considerably on the construction industry, much of what he suggests is applicable to any project. Could these concepts be used in another industry such as IT applications development projects? This paper will explore that possibility.

Introduction

Scope is the total sums all the products/services that are required to complete a project (PMBOK, 2013). But even when the scope has been completed and a freeze is agreed upon, change occurs. Edward Douglas’s article “Effective management of project change orders” discusses how to effectively manage any requested changes that may come up during the life of the project. And while he concentrates considerably on the construction industry, much of what he suggests is applicable to any project.

In this paper I will apply what Mr. Douglas suggests to Information Technology (IT) projects as there are a lot of similarities in the methodology Edwards advocates. For instance, we can all agree that the earlier we can identify a change the easier it would be to implement that change and the less costly it would be to implement. Further into the life of the project, the harder it will be to implement and the cost goes up. For example, it is much easier to change the foundation of a house before you pour it then it is to do so after the roof has been installed. In the programming world, it is much easier to make changes to the user interface while it is still in design then it is when you’re ready to push it out to production. There are many different methods and processes that can be put into place to help ensure that changes are identified and considered early in the process rather than later. Are these 100% effective? No, but it does help to eliminate many a costly error or change.

Planning for Change

Before any planning of what the project is actually to do begin, the project leadership needs to develop a project change management plan. The object is to put into place an agreed upon process for managing change should it occur.

The change management plan needs to plan who has the authority to approve changes. One has to take into consideration the threshold in which a change, such as a simple one, can be made by the project team, or if it is of such impact to the project that it needs to be approved by a higher authority. The plan has to outline the process for approval and everything that is needed for approving changes.

This plan needs to consider the process for submitting the requested change. Questions to be answered are who can make the change request? Who does a change request need to be submitted to? These are not easy to answer questions. Usually it’s the Project Manager who should initially receive the initial request for change. But sometimes one of the lead managers can receive a change request and then submit it to the Project manager. But, a change request should always go through the Project Manager since they oversee the entire project and can see impact where others are not aware (PMBOK, 2013).

The change management plan needs to consider how a change will be analyzed for impact to the project. What will be the impact to the schedule? Will it require overtime or extra resources or specialized help (availability)? Once the change request goes through impact analysis it will need to go through the approval process. The analysis process needs to outline what information is required and in what format should it be delivered and to whom it should be delivered in order to get approval. Should all change requests go through a steering committee for consideration, or can the PM decide that a requested change is too far outside the scope of the project for it to proceed (Verzuh, 2012)? Perhaps consideration of the change will take away resources from work underway and will have an adverse effect on the project timeline and budget; should the project budget money towards considering change requests?

Planning and Design

The most appropriate phase in which to take on change would have to be during the planning and design phase. It is best to consider and implement change as early as possible in the project as it is easier to and more cost efficient than it would be in later phases (Douglas, 2003). It is recommended that the PM and the sponsors freeze the scope of the project as early as possible in the planning or design phase. This holds true in construction as well as in IT projects; IT projects will find it a little easier to make changes to the scope even while in the execution phase. The master schedule should also be completed and approved during this period so that any requested changes can take into consideration impacts to it. Early completion of the design of the application will allow for build reviews and to catch any possible changes before construction of the application even begins.

By determining the scope, the work required, like through a Work Breakdown Structure (WBS) and completing the design of the application before even beginning to execution a build the project team can identify any changes that may be needed and to determine if implementation is needed. If the change identified is needed then the steering committee can determine if it wants to approve the impact the change will have to the project.

Change during Application Build

Since the project leadership team created a change management plan early in the project it would seem reasonable to say that any changes to the scope would go through this process before any change occurs.

The team would have to be thoroughly knowledgeable on the project plan and scope and understand the impact any change could have on its outcome. When a change is requested the team would have to put together an analysis of the impact that change may have. The PM would have to determine if he even wants to commit resources to doing the analysis of a requested change. The first questions to be answered are whether there is time and money in the project to consider changes. Another concern would be the impact of cumulative changes to the project. The danger here would be scope creep and budget overruns leading to financial failure of the project (Douglas, 2003).

Closeout

The concern here is that if the project is not properly closed; have all changes been completed; have all changes been properly documented, even those not approved? Subcontractor and vendor claims have to be closed before usage of the projects product and/or service is used. Potential problems include changes that were not completed properly or just simply not done. If the project is not properly closed problems could crop up. Too often closing the project is given little notice. The project team and leadership have often moved on to other projects leaving the PM to try to clean up the pieces.

Conclusion:

Douglas points out that it is best to develop and to put into place a proper change management plan. PMI points out that it is best to develop a number of management plans that help to guide the different processes of the project; a plan for each phase, so to speak. Many of the suggestions and guidance given by Douglas can be used in projects in other industries, too.

References:

Douglas, E. E. (2003). Effective management of project change orders. AACE International Transactions; ABI/INFORM Global, PM111.

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.

Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.

Applying the work breakdown structure to the project management lifecycle

A Critique of

Shelly A. Brotherton, PMP

Robert T. Fried, PMP

Eric S. Norman, PMP, PgMP

Article

“Applying the work breakdown structure to the project management lifecycle”

Table of Contents

Abstract

Introduction

WBS Structure

Work Packages

Aligning with Scope

Going from WBS to Scheduling

Conclusion

Abstract

To some the Work Breakdown Structure (WBS) can be a burdensome chore. To others it is a necessary tool in which to define the tasks, and only the tasks needed, to complete a project successfully. Today, project managers are discovering the high value associated with creating work breakdown structures (WBS) early in the course of project management and a projects success may be attributed specifically to use of a WBS.

Project Managers know that many things can and do go wrong with projects. Much of the failures can be attributed directly to poor planning, and especially with poor development of a WBS. Ms. Brotherton, Mr. Fried, and Mr. Berman article discusses in detail the concepts and usage of a deliverable-oriented WBS in project management. This paper discusses their views on using a WBS in a project, its development and usage throughout the project, and compares their analysis with the goals of the class syllabus.

Introduction

The Work Breakdown Structure (WBS) is used in project management to identify and organize the tasks needed in which to complete a project successfully. It only calls for those tasks needed, and only those tasks needed, in which to reach a successful outcome (PMBOK, 2013).

The WBS can be very basic or it can be very sophisticated. WBS’s can be simple, perhaps too simple. The Project Manager (PM) has to be careful not to create a WBS that is too simple that it fails to adequately identify and describe the tasks needed to complete the project. This poorly developed WBS causes misunderstanding, rework, and leads to costly delays. It can also make it difficult to identify when problems arise due to an inability to identify what needs to be done and in what order.

The WBS can also be over-complicated, from decomposing work packages too much so that it over defines how the work is to be done, to having so many work packages with short durations it makes it difficult, if not impossible, to manage.

Ms. Brotherton, Mr. Fried, and Mr. Berman article, “Applying the work breakdown structure to the project management lifecycle” discuss in detail how a deliverable-oriented WBS is applied to a project and focuses on why the WBS is needed while also pointing out some of the pitfalls to be aware of. They point out that project success can be directly attributed to creating a well thought out WBS (Brotherton, 2008). Poorly developed or planned WBS can result in detrimental project outcomes including re-planning, rework, unclear work assignments, scope creep, increasing budget costs, missed target dates, unusable products and/or delivery features. Even worse, you have a very unhappy project sponsor.

WBS Structure

When planning a project the project manager needs to determine the work that needs to be done to complete the project successfully. He does this by creating a Work Breakdown Structure (WBS). A WBS is the process of subdividing the project deliverables and project work into smaller and smaller elements commonly referred to as work packages (PMBOK, 2013).

The WBS provides a common framework from which to organize all the work needed to complete the project. A WBS can be made up of different levels with the number of levels determined by the project needs. The first three levels will usually reflect the integrated efforts of the project. Level one, sometimes called the “home” level, concerns the authorization and release of work. Another rule to keep in mind is the 100% rule (Kerzner, 2009). The 100% rule represents 100% of the total work of the project. Each level below the previous level has to add up to 100% of the level above it. Level two is reserved for budgetary information; level three usually involves scheduling. Levels four and lower make up the work packages of the project. The sum of the work of the child level must equal 100% of the work at the parent level. Each level is planned in sequential order identifying dependencies and order of completion keeping in mind that some tasks can be done in parallel to others.

Work Packages

Each of these work packages need to be manageable, independent or have minimal interface with other ongoing elements, be Integratable and measureable. It has to have clearly defined start and end dates. All objectives must be linked to company goals. Responsibilities for each element is determined and assigned using a responsibilities assignment matrix (RAM). The focus should be on deliverables deriving tasks and organizing those tasks into work packages (Brotherton, 2008).

A work package represents a decomposition of the upper level deliverables into fundamental elements where the components are verifiable and measurable. Verifying the level of decomposition only requires doing the amount of work that is necessary and sufficient to complete the deliverable required by the project. Ideal packages are usually 80 hours or two to four weeks in length (PMBOK, 2013).

Aligning with Scope

One important aspect of a WBS is to ensure that each of the deliverables and associated tasks align with the goals of the project and the company. The PM can do this using a scope sequencing process to show dependencies between different elements identified in the WBS. Like in building a house, you need to show the sequence of the different parts of the deliverables identified in the scope of the project; first you need the foundation, then the walls, than the roof. The PM can show this relationship by using a dependency diagram (Brotherton, 2008):

Going from WBS to Scheduling

One issue bothersome to PM’s has always been taking the various levels of the WBS from definition to actual scheduling. Brotherton points out the PMBOK guide shows the PM specifically how to go from a deliverable-oriented WBS to scheduling in five easy steps (Brotherton, 2008).

First: The PM defines the activities. The tools used here are decomposition, rolling wave planning, and expert judgment (PMBOK, 2013)

Second: Sequencing the activities. As just stated, you need to set the order in which the activities are to be done. You do this by identifying the relationships and the dependencies between elements.

Third: Estimating the resources needed. How many people are needed for which task. This part of the process will help with determining the budget for the project.

Fourth: Estimating project durations. Here the PM, using tools like past history and expert judgment, determines how long each task should take. Combined with number three above a total budget can be estimated.

Fifth: Develop the project schedule. With all of the above information, a project schedule can be determined thus documenting the total time it should take to complete the execution portion of the project. Add in a start date and a completion date can be determined.

Conclusion:

The WBS is a very important piece of a project. It further defines the scope of the project so that by its completion the sponsor, the steering committee and the project team will have a fully approved understanding of what their project entails. It will provide a detailed description of all the tasks needed to complete the required deliverables within the scope of the project. It will show the sequence in which the work needs to be done. It will be a useful tool in determining the scheduling of the project and for being able to track those activities to ensure the project is on schedule and within the scope and cost of the project since everything within the WBS is trackable (Fleming, 2010).

References:

Brotherton, S. A., Fried, R. T., & Norman, E. S. (2008). Applying the work breakdown structure to the project management lifecycle. PMI. Retrieved from http://www.pmi.org/learning/applying-work-breakdown-structure-project-lifecycle-6979

Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square, PA: Project Management Institute.

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.

A Critique of Ashok Kumar and Vinay Goyal article “Software requirement analysis enhancements by prioritizing requirement attributes using rank based Agents”

A Critique of

Ashok Kumar and Vinay Goyal article

“Software requirement analysis enhancements by

prioritizing requirement attributes using rank based Agents”


Table of Contents:

Abstract

Introduction

AOP in the Project Environment

Related Work

Agent Oriented Software Application with Scope and Requirements Gathering

Conclusion


Abstract:

Software using agent methodologies is an evolving method growing very rapidly in software development projects.  Agent oriented programming (AOP) is a paradigm where the construction of the software is centered on the concept of software agents.  The difference between object oriented programming (OOP) and AOP is that AOP has externally specified agents at its core whereas OOP is object oriented providing methods with variable parameters embedded within.

Systems composed of interacting autonomous agents suggest an encouraging software approach for developing and managing applications projects in complex environment. However, this multi-agent system standard introduces a number of new concerns when compared with more customary methods to software development. As such, new analysis and design methodologies, perhaps even new tools, may be needed to effectively create such systems.

Professors Kumar and Goyal conducted experiments to determine how effective AOP was in the project environment in determining user requirements. Their contention was that AOP is very helpful in the Software Development Lifecycle (SDLC) showing improvements in cost and effort. Professors Kumar and Goyal feel that the autonomous and reactive nature of AOP makes it possible for designers to visualize a solution. Their experiment aimed to prove this contention true. The following paper discusses their work and how it applies to the integration of scope, requirements gathering and time in managing projects.

Introduction

Agent oriented software; software that is capable of thinking and making decisions based on past events has been coming of age in the gaming world for many years. Now, it is being developed for use in the everyday business world, especially for use in developing business applications. But can it work in determining scope and requirements for business application projects?

Professors Kumar and Goyal experimented with agent oriented, which is growing very rapidly, to determine its effectiveness in determining requirements in application development. Software development industries have invested huge efforts in this domain and results published by many of them seem positive. This paper examines their work and compares how effective it may be in everyday project scope development and requirements gathering.

AOP in the Project Environment

The concept of AOP and the idea of centering your software on the concept of agents were first used by Yoav Shoham and his studies around artificial intelligence (AI) (Shoham, 1993). He used only single parameter agents at first that were specific to his studies. Shoham would later develop theories around game-theory and has won awards around his studies concerning the intersection of computer science, game theory, and economics, particularly in multi-agent systems. Kumar and Goyal are attempting to expand on this theory by putting it into practice to determine if there would be any improvement in the Software Development Lifecycle (SDLC). They point out that past studies show an improvement in the process and that agents have helped minimize project costs (Kumar, 2011).

By fine tuning agents and what is called the SDLC process-state-plug-in for two-way communications the result is that the agents can improve on organizing resources in such a way that helps to better utilize time requirements. Kumar and Goyal conducted such an experiment specifically to improve the requirements analysis process. The agents would sense the requirement environment and deliver a checklist of what it considered to be important requirements. This functionality goes along with the idea of artificial intelligence (AI) in that we can set programs to not only identify parameters when they’re presented; we can also make it so the program learns by storing information it can draw from so that it can make suggestions based on prior events.

The objective of an agent-based model (ABM) is to search for explanatory perception into the combined behavior of agents (they’re not necessarily “intelligent”) following simple rules, usually in natural systems, rather than in answering specific practical or business problems. Typical topics for ABM’s in MAS are online trading approach, disaster response or modeling social structures.

Related Work

The analysis process for using agent-oriented analysis and design involves using the GAIA Methodology. GAIA is made up of the following stages (Wooldridge, 2000):

  1. Any protocols should be identified and associated with each role. Protocols show the interaction that could occur between each role
  2. Identify individuals, departments, or organizations as key roles model that occur in the system with a description of each
  3. Elaborate on the role model using the protocol model. This should produce a fully elaborated roles model documenting the key roles in the system, their responsibilities and permissions together with the protocols and activities of each role

From these and other experiments engineers have been able to develop what are known as an autonomic computing mechanism that is capable of self-configuration, self-organizing; a kind of self-adapting software with the ability to use available information about its ever changing environment to change its decision making process. It stores event outcomes in a database using it to judge future events in order to make a decision.

Agent Oriented Software Application with Scope and Requirements Gathering

Part of the problem with using rank based agents is whether these agents can be flexible enough to meet the needs of business. Flexible agent based architectures have been experimented with by software developers and is considered the foundation for many next generation systems. But the success of these agents will very much depend on how they’re fitted into a business environment and they’re ability to change with that environment (Kerzner, 2009). While lining up specific requirements in an online form to roles, responsibilities, and permissions to ABM’s would make gathering requirements much easier, it cannot take the place of intuition. Part of the requirement for being a project manager is having a god business sense and intuition about what will work and what won’t work (PMBOK, 2013). While Kumar’s work certainly shows promise, as their test results seem to bear out, it’s difficult to see how these tools can be used in determining overall project requirements.

One part of managing projects is determining which resources will be used and when. While the ABM’s can help in determining skill level needed and matching to specific tasks, it cannot determine if that resource will be a good fit into the project team. Often this determination is a purely gut feeling on the part of the project manager.

Conclusion:

Can agent based methods be applied to all aspects of scope development and requirements gathering thus saving time and money? Yes, it can be. Currently it would seem to work well with identifying and matching applications requirements to roles and responsibilities. It would prove to be especially effective when used to determine security requirements with role permissions, especially in today’s security crazed world. But even in everyday business transactions carried out online in the business world, the ability to develop applications using ABM would help to save a tremendous amount of costly planning time. The real question here is will companies spend the time and money to develop such methods. Only if it was proven to them that it would cut development cost drastically would implementing ABM’s be considered. As with any new technology, it will take many years for full realization.

References:

Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.

Kumar, A., & Goyal, V. (2011). Software requirement analysis enhancements by prioritizing requirement attributes using rank based Agents. International Journal of computer science and information security, 9(8).

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

Shoham, Y. (1993). Agent-Oriented Programming. Artificial Intelligence. doi:10.1016/0004-3702(93)90034-9

Wooldridge, M., Jennings, N. R., & Kinny, D. (2000). The Gaia Methodology for Agent-          Oriented Analysis and Design. Autonomous Agents and Multi-agent Systems.

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.