Cross Functional Integration in Project Management

Introduction:

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

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

Project Templates

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

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

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

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

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

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

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

Conclusion:

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

References:

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

Building Project Team

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

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

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

What Is Process

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

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

The Five Key Attributes of Good Team Process

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

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

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

Core Processes of High Performing Teams

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

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

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

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

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

Content

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

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

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

Conflict

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

Hidden Agendas

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

Project Hierarchical Flowchart

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

Figure 1.1. Project Hierarchical  Flowchart

Conclusion

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

References:

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

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.

Risk Management: A Discussion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WBS Explained

WBS stands for “Work Breakdown Structure”. Simply put, it delineates the work required to complete the project. A WBS makes a Project Managers life easier, and it ensures a complete understanding of the work required to complete the task at hand. A WBS is the delineation of the scope into work packages and activities required to complete successfully. It represents total project scope as well as product scope.

I have witnessed during my time as a Project Manager many a practicing project manager not using the WBS correctly or at all. Many find it burdensome; others think it’s useless, and others just do not understand how it. What’s worse is when management sees no value in the exercise of putting a WBS together.

A WBS is easy to understand and quite easy to create. It has immense effectiveness serving as an anchor for many a successful completed project. There are numerous publications that can guide you in developing a WBS. I will focus on the importance of a WBS to the project and some detail on writing one.

A WBS takes time, thought, and collaboration. It should have a method for identifying the hierarchy in either a hierarchical chart or as an outline. It should include a WBS Dictionary that explains in detail how to complete each package/activity. The dictionary spells out the expectation of the deliverable.

  • A WBS can receive information from:
    • The scope management plan
    • The scope statement
    • The requirements document
  • The WBS is related to:
    • WBS dictionary
    • Scope baseline
  • It provides information to
    • Activity list
    • Activity cost estimates
    • Project budget
    • Risk register
    • Accepted deliverables

What is the difference between a deliverable and activity?
A deliverable is the result or outcome of series of activities. The activity represents a small portion of the total work package and deliverable.

Why is WBS important?

  1. WBS is a hierarchical representation of the scope of a project; it represents the total scope of work required.
    • A WBS represents the total scope and hence it can act as a checklist for the project.
  2. A Project Manager can easily see the completed work and what is work remains in the project.
    • The deliverable represented by the WBS is easily monitored and tracked.
    • Each successive level of WBS provides a basis for more precise estimation of remaining effort, duration, resources and cost in which to complete the project.
  3. A WBS can serve as a template for future similar projects – specifically for repetitive processes thus making future projects easier and faster to plan.
  4. Activities are easily assigned to team members making accountability easier.

A WBS can reduce project risk.

Remember:

  1. A WBS uses nouns and adjectives to define work.
  2. The key is that we are talking about the nouns, the (mostly) tangible objects created through project work.
  3. Always put deliverables in the first couple of levels
  4. Only move from deliverables to tasks when you’ve pushed down several levels, and have gotten to packages that are reasonably small and estimable.
  5. The tasks to be performed are always in support of a deliverable.