Project Initiation: A Critical Look- A Review

The question has come up, probably countless times, of just how closely companies follow PMI’s PMBOK guidelines on initiation. Mark Mullaly responds that not many do. His belief; that objective, reasoned, analytical and rational thought processes in choosing projects that meet a business’s goals or fit its strategy were the furthest thing from the truth. Truth be known, Mullaly felt that while this was widely known and practiced, many Project Managers would rather ignore what they know to be a critical topic in the industry.

rich garling

Politics
Mullaly’s belief was that for many companies the decision to choose one project over another had little to do with any rational, reasoned, or analytical thought. The decision had more to do with politics, pure and simple. Someone within the company, with plenty of clout and power, decided they wanted their pet project done. While there are some companies that follow a formal analysis of the merits of a proposed project and how it fits into the scheme of things, there just aren’t that many. And those that do follow some formal process don’t do a really good job of it.

The Process
In Mullaly’s article he explains what the initiation process for all projects is supposed to be, it is where all projects start. Someone comes up with an idea. That idea is analyzed determining what is the scope of the idea, what will need to be done, how long it will take, and roughly what will be the cost. According to the PMBOK Guide, the initial scope is defined, initial finances are committed, business case is written, stakeholders are identified, the Project Manager is selected, the charter is written and when approved the project becomes official (PMI, 2013).

The Business Case
One of the key deliverables is the business case or project proposal (Verzuh, 2012), a document that Mullaly feels is inappropriate to use to justify accepting an idea as a project (Mullaly, 2011). He feels that the formal usage of a business case is to justify the project in purely financial terms. We use tools such as NPV (Net present value), DCF (Discounted Cash Flow), IRR (Internal Rate of Return) and ROI (Return on Investment). Basically, you are trying to put a dollar value on costs and benefits. He feels it is impossible to put a dollar figure on an intangible such as security. Mullaly felt that any financial number measuring benefits, in a business case, is an estimation based upon an approximation derived from an inference; basically, we used the swag method or just simply guessed (Mullaly, 2011).

Communicating
So Mullaly suggests the best way to deal with hazarding a guess as to the cost of and the benefits derived from a proposed idea is through communicating. He feels we need to be open and honest about the kind of project we’re doing. We need to be open and honest about whether or not the financial projections justify moving forward with the project. The assumptions being made to create the financial projections need to be clearly defined and every one of the stakeholders needs to agree to those assumptions. All this effort is just asking whether a project is adequately worthwhile to examine further.

Business Strategy
As we have read in Verzuh’s book, initiation is highly important to business strategy. During this stage of the process the business should be deciding if an idea fits into the business strategy or meets the goals of this strategy. The business is supposed to justify the project because they have determined that it fits into the business strategy and meets its goals. The business further decides based on its ability to meet the cost and resource demands the project will put on the business. If it doesn’t, it should be denied (Verzuh, 2012).

But I have to agree with Mullaly, that while the optimal is to base the decisions to go/no go on whether the cost of the idea and the resources required bringing the idea to fruition are worth it to the company, many times I have seen where none of those criteria are used. There are times where an idea became a project, and then some other project that was approved by someone in upper management, which no one else knew anything about, started to pull resources and money from this project that had gone through the so-called approval process.

Initiation Process
While the process I described above is the optimal, it would be nice if we actually did it this way. I never seen it done that way at any of the companies I have worked for, although two have come close. Very few companies I have worked for actually have a process in place and those companies that do have a process usually follow a hybrid in-house system. Where I currently work we have a hybrid system. The initiation phase is called Demand Management. An idea form is submitted, a small committee of team managers review the idea form and then decide if the project merits assigning a project manager to it. The project manager is tasked with doing the initial requirements gathering from which an E0 Estimation is created and presented to the business requestor for approval.

Project Proposal
One of the problems I see is that the initiation process I described at my place of employment doesn’t take into consideration how well the idea fits into the business strategy or goals. In fact, nothing is ever mentioned. I honestly don’t think any of the managers know the company’s business strategies. Mullaly points out that one of the reasons why projects fail is because they simply don’t take the time to analyze and determine if the project fits the company strategy.

One document in particular, when properly used, can actually help to fully define the project so that an informed decision can be made. The project proposal contains the project goal, states the problem/ opportunity, offers a solution, details the costs/benefits of doing the project, shows how the project fits into the overall enterprise portfolio, defines the business requirements. It includes the scope, the risks, and a high level schedule. In a nutshell; it makes the business think the proposed project through to ensure that the business is choosing the project wisely.

In conclusion, what Mullaly and Verzuh both point out, that when used correctly, the process works. Mullaly just points out what is really common knowledge; many companies and organizations do not follow the process and the do so at their own risk. Part of a Project Managers job is to guide the team through the process and to help their company develop a process that allows them to make an informed choice that benefits the company and fits their strategic goals.

References:
Mullaly, M. (2011, March 1). ProjectManagement.com – A Critical Look at Project Initiation. Retrieved from http://www.projectmanagement.com/articles/262617/A-Critical-Look-at-Project-Initiation
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.

Feed Shark

Procurement Vendor Selection Criteria

Introduction
Many of the projects involved working with offshore contract developers. They provide Business Systems Analyst, Web Page Designers, Program Developers, Database Administers, and Project Managers. In order to select a vendor that would provide the quality work needed for the project, the sponsors and the project management, in conjunction with company procurement department, needed to develop evaluation criteria in which to measure information coming from the vendors. An Request for Proposal (RFP) would be issued to each of the vendors and from submitted RFP’s the selection committee would identify those vendors ranking highest in the criteria determined by the purchasing agent, and the selection committee to be relevant and material to properly evaluate a proposal (Fleming, 2003).

Project Description
The project was to develop a user form that would be used company wide by employees requesting access to various business systems used throughout the company. These users were located globally, the main project team was located in North Chicago, IL, and the business sponsors were located in Germany. The third party suppliers were located in both the United States and India. Documentation used in this process included the Project Management Plan, the Statement of Work and the project plan schedule (PMBOK, 2013).
Once the requirements were identified, and the solicitation package prepared, the criteria for selecting the responding vendors needed to be determined (Kerzner, 2001).

Selection Criteria
The following criteria would be used to select the vendor:

  • Criteria/Weight
  • SharePoint Experience / 30%
  • Resource Availability / 20%
  • Management Capabilities / 20%
  • Cost / 30%

Since the project consisted of developing an online SharePoint form it was considered highly important that the vendor have experience with developing in SharePoint, especially the latest versions. And since there was another project handling the upgrade to the newest version that would have a significant impact on our project it was very important that the vendor have experience with upgrading to the newest versions. The project was given a very tight timeline along with a tight budget; resources had to be available when needed according to schedule and within budget. This meant that managing those resources according to the project schedule would be a high risk and highly important (Kendrick, 2009).

The group also defined the relative value to be used to score each category:

Score Meaning:

4 – Fully satisfies
3 – Substantially satisfies
2 – Partly satisfies
1 – Does not satisfy

The group wanted to ensure that the meaning of each score was interpreted correctly. For example, if the criterion is “cost,” then a low cost would have a high satisfaction level. To calculate weighted scores for each criterion, multiply the weighting factor by the scoring factor. Total the weighted scores for each criterion to calculate the weighted score totals for each alternative.

While a number of criteria can be used; time, cost, expected management team of the project and previous performance history, were considered important to the project. As an example, assume that 100 points is the most that can be given to each of the criteria. The vendor that is selected would have the greatest number of total points. Weighing factors can also be applied to each of the four criteria. As an example, previous performance may be worth 200 points, thus giving 500 points as a maximum. Therefore, the lowest price supplier may be downgraded significantly because of past performance and not receive the contract (Kerzner, 2001).

SharePoint Experience Criterion
As noted above, experience with the SharePoint platform was a major requirement. The vendor also had to have resources that were highly experienced with the programming languages that make up SharePoint. These languages included C#, VB.Net, Java and SQL.

This experience with SharePoint required a further breakdown in the criteria used to select the vendor. The following ranking breakdown was created:

Qualifications of the vendor
a. Experience of proposed consultants
b. Availability of proposed consultants
c. Cost of each consultant
2. Experience with SharePoint
a. Versions
b. Number of years
c. Past performance
d. Experience with similar projects
e. Database experience

The following table would be used to record the criteria results for each vendor:

Vendor/Criteria SharePoint Experience Consultant Experience Consultant availability Consultant costs SP Versions Year’s experience Past performance Similar projects Database experience Resource Availability Management Capabilities Total Cost Totals
Vendor 1 4 2 3 4 2 2 2 4 4 2 2 4 35
Weighted Score 1.2 0.25 0.375 0.5 0.25 0.25 0.25 0.5 0.5 0.4 0.4 1.2 6.075
Vendor 2 4 2 3 4 2 2 4 1 3 2 2 4 33
Weighted Score 1.2 0.25 0.375 0.5 0.25 0.25 0.5 0.125 0.375 0.4 0.4 1.2 5.825
Vendor 3 4 2 3 4 3 1 3 2 2 2 2 4 32
Weighted Score 1.2 0.25 0.375 0.5 0.375 0.125 0.375 0.25 0.25 0.4 0.4 1.2 5.7
Vendor 4 3 1 3 2 2 2 2 4 4 2 2 4 31
Weighted Score 0.9 0.125 0.375 0.25 0.25 0.25 0.25 0.5 0.5 0.4 0.4 1.2 5.4

Conclusion:
As an alternative or in addition to the weighting systems, the selection committee decided to adopt decision rules. A decision rule tells the committee how to deal with a criterion under fluctuating conditions. For example, a decision rule might be: if management is rated anything less than satisfactory, the entire proposal is unacceptable, or, if the proposed price is thirty percent higher than the projects original estimate, it will be judged as being potentially unrealistic and the vendor’s proposal will be reevaluated to determine if there is a misunderstanding of the requirements. Thus the team was giving more meaning to the numbers making it easier to make a decision using the criteria being used to measure each vendor.
References:
Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.
Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project. New York: AMACON.
Kerzner, H. (2001). Project management: A systems approach to planning, scheduling, and controlling. New York: John Wiley.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.

The Importance of Stakeholders

Stakeholders are vitally important in all projects. There will always be someone who has an interest in seeing a project succeed. In fact, no project gets started unless someone has an interest in it. Keep in mind that the main stakeholder, the sponsor, most likely came up with the idea for the project in the first place.

One thing is clear, you as the Project Manager, needs to identify all stakeholders in your project (Verzuh, 2011). Stakeholders are defined as those individuals or groups who are actively involved in the project or whose interest may be positively or negatively affected by the performance or completion of the project (PMBOK, 2013). And there can be many stakeholders and they can have an interest in the project in the most interesting or unusual ways. Stakeholders can also be both internal and external to the project.

Stakeholders have various levels of responsibility in a project. The sponsor is the main champion and also approves all expenditures. Your Program Manager oversees your project and numerous other projects similar to yours. The project team interest is in producing a quality result seeing it to completion. Customers/users interest is in wanting to use a product/service that will solve their problem or fulfil a need. As you can see, there are many different users and each of them has a different reason for being interested in the project.

Identifying these stakeholders can be challenging. Sometimes it’s easy to find them and other times you may get surprised that someone has influence over the outcome of your project. You have to ask the question of who is impacted by this project and in what way are they impacted? Does a stakeholder have approval powers over my project? If so, how, and what is the potential impact?

It is highly important to be very thorough in identifying these stakeholders. Miss one and it could cost you dearly. The three main ones are the sponsor, the resource manager and those with decision authority. I use a stakeholder register to store all information on a stakeholder. I look for such information as name, title, phone, email address, contact preferences, what is their role/interest in this project, what decision making responsibility do they have? And I ask each, or I find out what I can on the company systems, who is their boss?

I ask that last question due to past experience. I just recently inherited a high profile project that is showing signs of trouble. One of the first tasks I gave myself was to identify all the tasks, those responsible for those tasks and what did these tasks impact. I’m looking for all stakeholders, but first I have to understand what the project is all about so that I know where to look. I don’t want to be talking to the sales department if the project has nothing to do with sales.

After 2 weeks of identifying the tasks and the stakeholders we had a risk that became an issue. One of the functional groups that was supposed to supply a resource to perform certain tasks for us, and we had been assured they would do, suddenly told us they couldn’t do it. Two people from this functional group had actually approved these resources. The catch, their boss had the final decision authority and he wouldn’t give it claiming it was outside of their described duties. Lesson learned: always ask if the person you’re talking with has the final authority on making a decision.

So the key is to identify all the key players and stakeholders who have an interest in your project, learn why they have an interest, what their role will be in the project and keep a record of all information on these stakeholders. Word to the wise: don’t show it to any stakeholders, this is your information for your eyes only.

References:
A guide to the project management body of knowledge (PMBOK® guide) (5th ed.). (2013). Newtown Square, PA: Project Management Institute.

Verzuh, E. (2012). The fast forward MBA in project management (4th ed.). Hoboken, NJ: Wiley.

Three Spaces

It’s interesting how Zachary Wong, in his book Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation, felt that personal space is the most complex and least transparent of the three spaces (Wong, 2007). I have to agree wholeheartedly as my experiences show how putting a team together can be very challenging. It’s hard enough trying to pick the right mix together of onshore resources, especially if they’re of similar cultural upbringing and experiences; but try to create that mix from onshore resources of multiple cultures along with offshore mixed cultural resources. That is quite a handful of challenges.

I would consider the most important aspect of picking resources, besides making sure they have the technical knowledge and experience to complete the tasks, is are they of the right personality and temperament? Do their cultural beliefs and upbringing allow them to work effectively in the position being considered? As Wong suggested, everyday people are making judgment calls based on their beliefs and values (Wong, 2007).

I have had situations in which a fellow Project Manager had to determine when a task was going to be completed. This fellow Project Manager was a Junior Project Manager under my command. He needed to follow up with a Vice-President of the company to determine when he could reasonably expect approval of a document we need to move forward on a task. This Junior Project Manager was from India. In India they do not just go up or email, or leave a voice-message asking the question. They go about it in a roundabout way so as not to show disrespect, to show deference to authority. The problem here was that by the time he would get around to asking the question we would be behind schedule. Knowing this cultural difference meant my recognizing when to step in to cover a task while also showing respect to the Junior Project Manager so he wouldn’t lose face to his colleagues.

I will have to disagree with Wong on his feeling that some values are derived genetically (Wong, 2007). I believe that all values are learned or chosen by the way we’re raised. The only genetically passed on behaviors for humans are those dealing with survival. As Abraham Maslow described, people are motivated by five psychological levels of needs in which the most important one is physiological; basically the need to survive comes first placing cultural after this one is satisfied (Maslow, 1943). The balance of those needs: security, social, esteem, and self-actualization are all cultural, not genetics.

I have worked with many people from many different cultures. Many of these colleagues have successfully assimilated themselves into the American culture, their differences notwithstanding. It seems to me that if culture was genetic than these individuals would not be able to assimilate so easily. While there are differences in physical differences due to geographic location, and thus learned behavior due to those locations, our genetics is the same across the world. Our learned behaviors are only different due to location and society.

References

American Journal of Physical Anthropology. (1996). biological aspects of race. American Journal of Physical Anthropology, 101, 569-570. Retrieved from http://physanth.org/about/position-statements/biological-aspects-race/

Maslow, A.H. (1943). A theory of human motivation. Psychological Review 50 (4) 370–96. Retrieved from http://psychclassics.yorku.ca/Maslow/motivation.htm

Wong, Z. (2007). Human factors in project management: Concepts, tools, and techniques for inspiring teamwork and motivation. San Francisco: Jossey-Bass.

Contract PM

I live the changes that have come to the IT world in corporate America: I’m a contract consultant who goes where the demand is. What I mean by that is the market has changed over the last twenty years. It has gone from where employees could count on a job for life to where you’re hired on to perform a specific task within a given time frame. Once you have completed that task, you move on.

For instance, I work for a recruiting firm headquartered out of New Jersey. I’m assigned as a Project Manager to a major corporation in Deerfield, IL. The ratio of contract consultants to full-time employees is 75% – 25% and wants to change that ratio to 90% – 10%. Many companies today find it increasingly beneficial to hire contractors who specialize in what the company needs. MCI’s Dick Liebhaber pointed out that it is easier to buy scope than to recruit, train and mentor permanent employees (Fleming, 2003). Companies can instantly buy the brain power they need for the specific task at hand. The cost savings in training and benefits has to be enormous.

Global trends are also affecting how HR manages resources. The breadth of the available pool of talent opens tremendously when you have the world in which to look. Jeremy C. Bradley, in his article in the Houston Chronicle, notes how traditionally HR has been a somewhat isolated profession, but with globalization and mass communication the world is becoming a smaller place (Bradley, 2015). Training has to be a cross-cultural event; meetings are conducted using multi-technical tools like big screen television, WebEx and webinars. Many things have to be considered when putting a team together.

What is interesting, and it takes the opposite view, is a study conducted by the Society for Human Resource Management in which respondents stated that the three biggest challenges facing HR Professionals was retaining qualified help, developing the next generation of corporate leaders, and creating a corporate culture that attracts the best qualified employees (Society for Human Resource Management, 2012). It looks to be an interesting task considering that many companies, and MCI, are moving in exactly the opposite direction.

References:
Bradley, J. C. (2015). Global trends that will affect human resources. Houston Chronicle. Retrieved from http://smallbusiness.chron.com/global-trends-affect-human-resources-61643.html

Fleming, Q. W. (2003). Project procurement management: Contracting, subcontracting, teaming. Tustin, CA: FMC Press.

Society for Human Resource Management. (2012). Challenges facing hr over the next 10 years. Survey Findings.

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.

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.

Enterprise Project Management & Project Management Office

Enterprise project management (EPM) is the integration of procedures, technology, organizational structure, and people that ensures alignment of projects to company strategy and goals.

There are three tiers of management in the EPM model. These tiers form the relationship between project, the projects resources, and company strategy. Project management focuses on the effective deliverance of selected projects. Program management is really management of multiple projects and it serves to coordinate projects and the resources that each of these projects share— particularly the people. Usually these projects share a similar goal and processes. Project portfolio management, associates the selection of projects and programs to the strategic goals of the company.

Program management is the management of multiple similar projects by individual project managers for each project and one Program Manager overseeing the whole. It strives to remove the confusion inherent by many related projects by effectively deploying limited resources, particularly personnel, among each project. It is able to do this by tracking relationships among projects, and managing projects or tasks that add value across projects yet are burdensome to any one project.

Project portfolio management (PPM) ensures that projects and programs promote organizational strategies and goals. It tries to do all of that by managing the limited resources available within the company. It requires disciplined decisions driven by priorities established by the Project Management Office or Executive decision.

Project Portfolio Management (PPM) has three primary purposes: align project selection with strategy; assign limited resources based on priorities; optimize deployment of resources across projects.
The benefits of PPM include: balancing projects by risk and reward; focusing on meaningful results that support strategic goals; choosing the right projects with the right resources to complete them; using strategic priorities to direct resource allocation.

The roles in PPM provide the authority and knowledge for PPM to function. The following roles should be included as part of any PPM: Steering Committee provides the link to the enterprise’s strategy and operations to ensure that the portfolio adds value to the organization; Portfolio Experts provide the working knowledge of portfolio management; Project Sponsors provide the expertise on the business benefits; Business Analysts are the experts on conducting analysis and documentation that help in making the decisions concerning a project.

Project Management Office primary purpose is to provide and maintain the project management standards and promote their use in an organization. The PMO actively supports a variety of projects by management of the perfunctory chores such as building and updating the project plan and budget documentation used by the projects. A PMO will also supply project managers to projects all over the organization. And, because it provides the project managers to the projects, the PMO can enforce the project management standards it establishes.

At work there are numerous PMO’s, usually one for each division and one main corporate PMO. Each of them operates differently from their colleagues in other divisions. The ultimate goal is have the one main corporate PMO guiding all the divisional PMO’s. work has a long way to go to meet that goal.

References:
Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square, PA: Project Management Institute.
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.

More on Project Communications

At one of the companies I have worked one of the documents each project is required to submit to the PMO is the “Project Management Plan (PMP)”. The PMP provides a mechanism in which to centrally locate many of the projects individual management plans including the Communication Plan, the Risk/Issue Management Plan, the Cost Management Plan, Change Management Plan, and the Document Management Plan.  PMI says that managing communications includes the methods essential to guarantee timely and correct planning of information used to run the project. This includes the gathering, dissemination, managing, controlling, monitoring, and eventual storing of project documentation (Project Management Institute, 2012).

Now, it’s not the typical plan that one would think of, nor is it a project schedule. This documents objective is to describe the project management system the team is going use to manage the project. The most important part of this whole document is the Communication Plan.

PMI points out that there is a need to define, plan and manage communications (Project Management Institute, 2012). I’ve learned through the years of managing projects that communications is all important. If you don’t communicate with the stakeholders and your team what is going on at any given moment in your project, your project will likely fail.

With the Communication plan we determined what types of communication would be required including status reports, Business Requirements Document, 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 (Project Management Institute, 2012).

The PMP also help us to define how we were going to communicate certain events in the project such as change management: 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.

The PMP plan describes the roles and responsibilities of those able to request changes and those who approve the changes. Its plan describes when a Change Request is required:

  • Changes to the project’s scope / Business Requirements have been identified or requested.
  • Changes to the project’s budget have been identified or requested.
  • Changes to the project’s schedule have been identified or requested.

The plan requires that a Change Request Form be used to request a change and that it must be submitted to the Change Review Board for approval. In our case there is no maximum dollar limit, every change request no matter the cost has to be approved by the business sponsors.

The Project Manager has to be a communicator as well as a leader. They cannot be afraid to bring bad news to the forefront. Good news doesn’t always happen in projects. But the bad news could help in keeping the project from going from bad to worse. I would rather be accused of over communicating than to be accused of under communicating. When I over communicate I can always cut back. I under communicating once and I lost my job.

References:

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.

Project Cost Management

Keith Custer, in his article “The Seven Deadly Myths of Earned Value Methods in Project Management” (Custer, 2009), describes how Earned Value Management (EVM) is misunderstood as a tool for managing costs in a project.

Keith Custer, in his article “The Seven Deadly Myths of Earned Value Methods in Project Management” (Custer, 2009), describes how Earned Value Management (EVM) is misunderstood as a tool for managing costs in a project. He points out that there is a fear of implementing EVM with detractors saying it is difficult and time consuming. They also claim that EVM is better suited for large ($1M+) or government projects but not for smaller projects (Custer, 2009).

But Custer claims that the process laid out over forty years ago is as appropriate for small as well as large projects and actually makes it easier to effectively manage them (Custer, 2009). In his article Custer lays out 7 myths about EVM stating his case as to why each of these is invalid.

EVM Myths in Managing Project Costs

Myth 1: That only contractors and government projects need use EVM (Custer, 2009). Custer points out that the reason why government and contractors use EVM is precisely because it is so effective at controlling project costs (Custer, 2009). In fact, it is effective as an estimating tool. Properly documented estimation can be more effectively tracked than hastily thrown together estimations. Custer also points out that the government borrowed EVM from industrial manufacturers who had developed the process early in the 20th century (Custer, 2009). He refers to the fact that like many projects in private industry, government projects are notorious for being under estimated and for costly budget overruns (Custer, 2009). The Office of Management and Budget (OMB) has consistently discovered in study after study that those projects run using EVM they rarely under estimate and rarely has significant budget cost overruns (Custer, 2009). In fact, data gathered since mid-1970 has shown a significant improvement in the ability to scientifically forecast the outcome of a project at the 20% completion mark (Fleming & Koppelman, 2010). Both Custer and Fleming point out that EVM’s WBS, schedule constructs, organizational breakdown structures, reporting, variance reporting provide a significant boost to estimating, project performance tracking and forecasting at any given point in the project (Custer, 2009) (Fleming & Koppelman, 2010).

Myth 2: EVM is only useful for large or long term projects: Any project of any size can benefit from EVM, according to Custer (Custer, 2009). And he is right. I have used EVM on projects ranging from $50,000.00 up to $8 million with great success. With smaller projects you have to increase the frequency of the reporting cycle so that you get timely results from monthly to weekly to daily depending on the duration of the project (Custer, 2009). The key point here is that EVM can alert the Project Manager to problems with the budget and schedule at any given point, but there is work involved. The work, though, is what I would consider to be minimal amount required for any size project: Scope, WBS, schedule, regular reporting.

Myth 3: EVM is too rigid: As I stated above, any good Project Manager knows that the minimum requirement for managing a project is scope, WBS, schedule, and regular reporting (Custer, 2009). Custer emphasizes that EVM requires strict detailed up front planning and quantifying of expected results (Custer, 2009). But to say that EVM is too rigid is completely wrong. In fact, it’s very flexible where many of the tools can be constructed to suit your needs on the fly without any negative effect on the data (Custer, 2009) (Fleming & Koppelman, 2010). One thing that Custer points to is the successful use of EVM in defense projects where there are huge risks involved (Custer, 2009). In many of those projects only the near term scope was known with many details not known for many years. The key, as noted by both authors, was a well-developed WBS that gave the Project Manager the flexibility needed to use EVM effectively (Custer, 2009) (Fleming & Koppelman, 2010). A project I’m currently running has a WBS that is not well-developed and my aim is to apply the rules of EVM to bring it into alignment so that I can use it as the tool it is meant to be.

Myth 4: There is such a thing as EVM lite: As noted earlier, yes, there is a sort of EVM lite (Custer, 2009). But you still have to do the work of developing a scope, WBS, schedule, and regular reporting. Custer refers to the many software companies that proclaim an EVM Lite version are really trying to just sell their software (Custer, 2009). The problem is that these companies leave out important aspects of the process, such as implementing management recommendations resulting from the EVM data gathered. Custer asks what the sense is in gathering the information if you’re not going to use it (Custer, 2009). Good point, I have seen many a Project Manager gather together the information, only not use it because it was not good news in their eyes. Never mind that the point of the information was to give management a truthful view of the status of the project so that they could make good decisions.

Myth 5: Implementing EVM is a lot of extra work: Yes, it is hard work, but not extra work since it’s work the Project Manager should be doing already. EVM is a process that allows the Project manager to use the information gathered and organized more effectively. It helps to draw out a clearer picture of the true status of the project. The EVM standards only reinforce the good project standards that should already be in place. EVM actually helps to integrate them (Custer, 2009).

Myth 6: Companies need to change their structure to implement EVM: While EVM requires that the WBS define who is responsible, the department and individual, it does not require a change in the organizations structure (Custer, 2009). Even in a functional matrix organized company, EVM only requires that each department be listed as to what they have agreed to do (Custer, 2009). In fact, EVM works very well in cross-functional organizations in tracking the costs of the project and rolling those costs up to the project level (Fleming & Koppelman, 2010). At Walgreens we use an EVM lite that was internally created in which accounting developed a system for tracking each project costs by department.

Myth 7: Implementing EVM requires expensive software: No specific software is required (Fleming & Koppelman, 2010). Many basic software’s such as Excel, MS Word, MS Project work quite well with EVM.

Conclusion

Controlling the costs of the project is one of the most important responsibilities assigned to the Project Manager. As has been pointed out, controlling project costs can be done quite effectively from estimation to project completion using EVM. Custer and Fleming point out, regularly, that the EVM processes and tools help the Project Manager to effectively estimate the cost of the project; to determine at any given point the true status of the project; and to accurately forecast its outcome even when only 15-20% of the project is completed (Custer, 2009) (Fleming & Koppelman, 2010). Like with any undertaking, you have to create the tools needed effectively and then use them effectively so they work for you. As I stated earlier, many of the projects I have managed were in poor shape when I inherited them. I had to literally rework the scope, the WBS, the project schedule so that I could use the EVM tools and processes to keep control of the costs of my projects. The tools and processes work. All you have to do is use them.

References:

Custer, K. (2009, January 21). The Seven Deadly Myths of Earned Value Methods in Project Management [Web log post].

Retrieved from http://www.projectsmart.co.uk

Fleming, Q. W., & Koppelman, J. M. (2010). Earned value project management. Newtown Square,

PA: Project Management Institute.

Kendrick, T. (2009). Identifying and managing project risk: Essential tools for failure-proofing your project.

New York: AMACON.

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.

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.

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.

Risk Management

Eric Verzuh notes that sometimes it seems that for every risk problem solved a new risk appears (Verzuh, 2012) and that can be so true. Perhaps the biggest risk to a project is when the team skips risk analysis because they consider it unnecessary.  Out of the 5 risk strategies described by Verzuh: Acceptance, avoidance, contingency planning, transfer and mitigate, he seems to have forgotten one…ignoring…hoping it goes away. What I will describe here, briefly, is where the team decided a possible event wasn’t going to be a risk, and there wasn’t much evidence to support it as a possible risk, yet it eventually turned into an issue.

Kendrick describes a risk as almost any uncertain event associated with work. It’s as the insurance industry characterizes risk as loss multiplied by likelihood. I was the project manager of a project that was developing an intranet system that the U.S. Navy would use to manage the recruits at three naval bases in the Midwest, south, and eastern parts of the country. The navy had a big interest in using current web technology to develop applications that could be used to manage recruits from boot camp to deployment. When I first started I was a one man team doing mostly proof-of-concept (POC) work.

Two years into the project, by then I had a team of 15, it was decided we should re-locate the web and data servers housing this system to a server farm located at Pensacola, FL. The navy has two bases located on the peninsula, virtually on opposite sides. While developing the requirements for this project we discussed some of the risks we would face. Most of the team was worried about working with servers located almost 1000 miles away. They felt a big risk was losing internet connectivity. They also felt that not having direct managerial control was a risk; basically we wouldn’t be in control of the box anymore and they were not happy about that.

The process I recommended we follow was basic PMBOK: Plan risk management; identify the risks; perform qualitative and quantitative analysis; plan the risk response; and control the risks. While identifying risk was ok with the team, they weren’t exactly thrilled with having to develop a response to each risk. One risk I identified was the possibility of a hurricane wiping out the entire server farm. Everyone disagreed with me. I had pointed out the bases, and both the main server farm and the back-up server farm, were located in Florida, on the Gulf of Mexico, and on a peninsula. They felt that there was sufficient protection that a hurricane could never wipe out the entire farm. I asked them to humor me, let’s develop a mitigation plan just in case. They said ok, but it was never completed. My resources were all working for different departments, only part of their time was devoted to this project.

Some of you may remember a hurricane named Ivan. Ivan, a category 5 hurricane, hit landfall just west of Pensacola back in 2004. Ivan had a surge wave that was reported to be 26’ tall. Ivan basically wiped out the back-up server farm first, and then the main server farm. And we had no back-up plan in which to keep the system alive. Or so they thought. I guess this is one reason why I’m a project manager. I had a back-up system created at Great Lakes just in case. Cost was minimal as I used the old servers we had used before to run the system. I had created a contingency fund and I had a program created to monitor the systems in Florida. If either one lost connectivity the spare servers would immediately back up the entire system.

The lesson learned here is that as a project manager I have to be prepared for any and all types of risks. If it’s difficult to get your team to prepare the plan, then do it yourself. In the end it’s your job on the line if a risk becomes a reality and you didn’t plan accordingly.

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.