PM Papers

IIPMC Balanced Scorecard

noreply@blogger.com (Thomas Kennedy) — Mon, 31 May 2010 13:40:00 +0000

Strategic Plan, Part III: Balanced Scorecard for the

International Institute of Project Management Coaching (IIPMC)

In previous papers I conceptualized and proposed the creation of an organization, the International Institute of Project Management Coaching (IIPMC.org), and created a SWOT analysis to examine its strengths, weaknesses, opportunities, and threats. In this paper, using the format of the Balanced Scorecard, I define the value chain and strategic objectives needed to begin working toward the mission and vision of the IIPMC.

IIPMC Value Chain

The value chain is a visual representation of the relationships between key components of the strategic plan. The relationships flow through all four areas of the Balance Scorecard: financial, customer, internal, and learning and growth. The following diagram outlines the value chain for the IIPMC.

Financial. As outlined in the value chain diagram, the two financial objectives of the IIPMC are revenue growth and positive free cash flow. To achieve its mission, the IIPMC must generate revenue to cover the costs of developing and maintaining the balance of the value chain. Without revenue, none of the other components can exist. As I will summarize in an IIPMC Balanced Scorecard table, I have also included a measure for obtaining the initial funding needed to launch the IIPMC. The positive free cash flow is a way of supporting the value of debt free living. I realize an organization can generate positive free cash flow and still hold debt. However, the intent behind this measure is to ensure sufficient cash is available to cover the ongoing operations of the business without the need to enter into a debt situation. The measure reduces or eliminates the need for debt.

Customer. The customers of the IIPMC provide the revenue and cash flow. In this value chain the customer is a combination of two separate entities: the project managers who will receive coaching and the project management coaches. Acquiring and retaining both types of customers is important to revenue growth and positive free cash flow. To retain customers, they must value the services that the IIPMC provides. These services include continued education, positive coaching relationships, and ultimately, successful project implementations.

Internal Business Processes. The IIPMC must become excellent at certain internal processes to provide the value services for its customers. Market research and execution is key to finding and acquiring customers. Providing products like a quarterly journal, an articles database, and the Project Management Coaching Best Practices (PMCBP) manual are foundational to supporting its customer’s educational needs. The Coaching Connection is the forum that will bring project managers and coaches together. But ultimately, successful achievement of the mission lies in IIPMCs PM Coach Certification process. Without quality coaches it is impossible for the IIPMC to achieve its mission.

Learning and Growth. The IIPMC must develop the infrastructure needed to support its internal business processes. New media development creates the IIPMC online presence, the primary intended source for both volunteer and customer acquisition. In addition, the IIPMC will need to acquire or develop the systems needed to support the operations of the organization. The discussion forum will allow project managers to post questions and receive responses from certified coaches. The coach evaluation system will allow project managers to see a coach’s past performance and help the project manager in the selection process. The member management system will automate the on-boarding of new members, fee collection, and proactively pursue renewal memberships. The certification system will manage the process of evaluating and initially qualifying project management coach candidates and facilitate the remaining steps in the certification process.

The final component of the IIPMC value chain is volunteer acquisition and development. As a nonprofit organization, the IIPMC will function primarily through volunteer workers. As a result, finding and developing volunteers to perform the work of the organization is a critical objective of the overall strategy.

IIPMC Balanced Scorecard

In alignment with the value chain, the following table lists the strategic objectives of the IIPMC.

Table 1. IIPMC Balanced Scorecard

Conclusion

By developing the value chain and seeking to achieve the objectives outlined in the Balanced Scorecard, the IIPMC will begin the process of achieving its mission of improving the performance of project managers worldwide.

IIPMC SWOT Analysis

noreply@blogger.com (Thomas Kennedy) — Tue, 25 May 2010 01:38:00 +0000

Strategic Plan, Part II: SWOT Analysis for the
International Institute of Project Management Coaching (IIPMC)

In a previous paper I conceptualized and proposed the creation of an organization, the International Institute of Project Management Coaching (IIPMC). The mission of the IIPMC is to improve the performance of project managers worldwide. To create the IIPMC, I must develop a strategic plan. The next step in strategic plan development is performing a SWOT analysis. In this paper I examine the strengths, weaknesses, opportunities, and threats related to the creation of the IIPMC as outlined in the following table.

Table 1. IIPMC SWOT Analysis Summary

IIPMC Internal Strengths

Good organization name and clear mission/vision
Virtual organization, global with low overhead
No debt!

IIPMC Internal Weaknesses

Does not exist!
Susceptible to name loss
No nonprofit status
Unproven and undeveloped core process (PMCBOK)
Unrecognized credential
No alliance with PMI or OGC
No advisory board
No members or customer base
Limited technological infrastructure
Limited financial resources
No strategy

IIPMC External Opportunities

Economy is improving, more projects, PM failure rate still high
No organization providing PMC credential
Internet and collaboration technology simplify communication
Additional revenue from spin-off products

IIPMC External Threats

Coaching competitors already established
Easy for competitor to copy
Copyright or other legal infringement
No adoption from coaches

IIPMC Internal Strengths

Because the IIPMC does not yet exist, it has few internal strengths. However, as a result of the last paper, the IIPMC does have a good organization name and a clear mission and vision statement. In addition, with the technology available today, the IIPMC can function as a virtual organization supporting a global presence with very low overhead. Finally, one of the biggest strengths of the IIPMC is that it is debt free. These points, although few, provide a solid foundation from which to further develop the strategic plan.

IIPMC Internal Weaknesses

As an organization that does not yet exist, the internal weaknesses of the IIPMC are many. Although the organization name is good, I have not registered it and I have not performed a name search. As a result, the name is susceptible to loss to another organization. In addition, I intend to run the IIPMC as a nonprofit; the organization will need to meet the legal requirements to register as a nonprofit.

Another weakness of the IIPMC is that its products do not yet exist. The IIPMC must first develop the Project Management Coaching Best Practices (PMCBP). Even after development, the core processes are not yet proven. In addition, the Project Management Coach (PMC) credential has not yet received recognition. It could take years for the IIPMC to gain enough recognition for the PMCBP and the PMC credential to hold any creditability. The IIPMC will also need to develop the forum that will be used to connect the PMCs to project managers and organizations seeking performance improvements. This development could take significant time and resources.

The success of the IIPMC is partially dependent on its relationships with key stakeholders. No alliance exists with the Project Management Institute (PMI) or the Office of Government Commerce (OGC), the two leading organizations that administer project management certifications. In addition, the IIPMC will need to put in place a board of directors to help guide and monitor the development and execution of the IIPMC strategy. The IIPMC is also absent its most important relationship: its members or customers. As with the products, these relationships will take time and resources to develop.

As if those internal weaknesses were not enough, the IIPMC has limited financial resources. As a nonprofit, the IIPMC will need to raise funding before making significant advances toward executing its strategy, which the IIPMC must also develop. The weaknesses are overwhelming.

IIPMC External Opportunities

On a more positive note, the IIPMC is in a good position to leverage some of the external opportunities that currently present themselves. The economy has made a turn for the better. As a result, organizations are beginning to fund more projects. However, as discussed in the previous paper, project failure rates are still high. This combination provides an opportunity for the IIPMC if it can show how using a PMC improves project success. In addition, no organization currently offers the PMC credential; IIPMC has an opportunity to be the first.

Another key opportunity is the current capabilities of the Internet and collaboration technology. As a virtual organization, the IIPMC will need to connect people from around the globe. The technology available today provides this capability with relative ease. The technology will continue to advance and make it easier for people to communicate about anything, anywhere, at any time.

Although not a current opportunity, once I establish the IIPMC, it will have opportunities to generate additional revenue through spin-off products. The IIPMC could develop revenue from local chapters, additional books or training materials, speaking engagements, and logo merchandise items.

IIPMC External Threats

As for external threats, although no project management specific coaching certification organizations currently exists, many coaching organizations do. As a result, it would be relatively easy for an established coaching organization to add a project management credential to an already existing portfolio of coaching products. In addition, the IIPMC might find it difficult to develop its products without infringing on copyrighted material or experiencing other legal challenges. But by far, the biggest threat to the success of the IIPMC is rejection from the coaching community. Unless those who provide coaching services to project managers adopt and support the PMCBP and PMC credential, the IIPMC will not succeed.

Conclusion

As a new organization, the IIPMC faces many challenges that it will need to overcome to become a viable business. The task for the IIPMC is to develop a strategy that will leverage its strengths and opportunities while minimizing or eliminating its weaknesses and threats. In the next paper I will develop the objectives needed as part of a comprehensive strategy aimed at achieving the IIPMC’s mission and vision.

International Institute of Project Management Coaching

noreply@blogger.com (Thomas Kennedy) — Tue, 18 May 2010 00:34:00 +0000

Strategic Plan, Part I: Conceptualizing a Business

According to Pearce and Robinson, strategic management is “the set of decisions and actions that result in the formation and implementation of plans designed to achieve a company’s objectives" (2009, p. 3). Organizations use project management to implement strategic plans. A significant body of knowledge and training exists to support project management best practices. The Project Management Institute and the Office of Government Commerce provide globally recognized project management credentials. Universities offer bachelor, masters, and doctorate degrees in project management. Amazon.com offers thousands of books on project management and project management training companies abound. However, even with these resources available, organizations report that more projects fail than succeed.

The Standish Group, a key researcher that tracks IT project success rates, reports almost 70% of IT projects fail to achieve the purpose for which they were initiated. KPMG Canada reports similar results at a 61% project failure rate. With so much project management training and best practices available, project failure rates should be much lower. Project managers invest considerable time learning best practices and obtaining certifications, neither of which ensure proper application of best practices. Training focuses on imparting knowledge and teaching specific skills but does not help the project manager apply knowledge and skills while managing projects. The problem is not bad training or poor practices. Instead, the problem is improper application of project management best practices.

To improve project manager performance and thereby increase project success rates, the behavior of project managers must change. The project manager needs someone with a history of successful project implementations to help identify and correct bad habits. The project manager needs someone who understands how to change behavior. The project manager needs a coach.

The most effective way to learn any trade is through one-on-one coaching from a master of that trade. As a result, I propose coaching by successful project managers who are certified in the art and science of coaching. In this paper I conceptualize and propose the creation of an organization, the International Institute of Project Management Coaching, intended to improve the performance of project managers worldwide.

IIPMC Mission and Vision

The role of the mission statement is to “describe the company’s product, market, and technological areas of emphasis in a way that reflects the values and priorities of the strategic decision makers” (Pearce & Robinson, 2009, p. 11). The vision “presents the firm’s strategic intent that focuses the energies and resources of the company on achieving a desirable future” (Pearce & Robinson, 2009, p. 37). In essence, the mission describes what or who the organization is and the vision defines what the organization aspires to become. In response, I propose the following mission and vision:

Our mission is to create a globally recognized network of project management coaches focused on improving the performance of project managers worldwide. Our products will:

Promote the value of project management coaching.
Provide guidelines for the best practices of project management coaching.
Ensure the highest quality of project management coaches through an independent certification credential.
Connect credentialed coaches to project managers and organizations seeking project mangaement performance improvements.
Define the technological platform needed to support effective project management coaching.

Ultimately, our aspiration is to become the world’s leading membership association for project management coaching.

IIPMC Values

Values are the “beliefs, business principles, and ways of doing things that govern a company’s operations and the behavior of organization members” (Thompson Jr., Gamble, & Strickland, 2006, p. 19). Values guide an organization’s strategic direction. The IIPMC’s values are:

Dedication to every project manager’s success. The IIPMC will evaluate every product and service against the contribution it makes toward improving the performance of project managers worldwide.

Trust and integrity in all relationships. Trust and integrity are key ingredients for any successful relationship. Coaching is no exception. Our members and coaches will adhere to a code of ethics that represents this value.

Continued improvement through research and application. We owe it to our members, coaches, and project managers to search continually for better ways to improve the performance of project managers worldwide. Through research we will seek new ways to achieve our mission.

Debt free living. We started debt free and we will remain debt free. We will administer the IIPMC through a network of volunteers. We will raise the funding needed before taking on any new projects or expenses. We believe living debt free will give us long-term stability and will set an example for other organizations to follow.

Conclusion

The creation of the International Institute for Project Manager Coaching will provide the resources needed to improve the performance of project managers worldwide. As the success rate of projects increases as a result of project manager coaching, the IIPMC will achieve a competitive advantage as the world’s leading membership association for project management coaching.

References

Pearce, J. A., & Robinson, R. B. (2009). Strategic Management: Formulation, Implementation, and Control (11th ed.). New York: McGraw-Hill/Irwin.

Thompson Jr., A. A., Gamble, J. E., & Strickland, L. (2006). Strategy, Winning In The Marketplace: Core Concepts, Analytical Tools, Cases (2nd ed.). New York: McGraw-Hill/Irwin.

Beware of Project Selection Biases

noreply@blogger.com (Thomas Kennedy) — Tue, 29 Sep 2009 00:14:00 +0000

Organizations execute corporate strategies through projects. All have a limited amount of funding available and must choose the projects that best meet their objectives. Organizations use project selection processes to compare projects. The intent is to select the projects that provide the best value, as measured through the selection criteria. If project selection teams are able to evaluate objectively potential projects, the organization will be able to select the projects that best meet the selection criteria. However, Lefley (2006) believes that biases of selection team members may influence project selection.

Lefley set out to evaluate the selection of an information technology project for the UK-based Association of International Accountants (AIA). His intent was to investigate empirically whether the bias of the project champion influenced project selection. The project champion in this case was the person who proposed the project and his department would have benefited directly from a successful implementation.

The AIA uses a three-component model to attempt to convert opinions and views into actual judgmental values or numbers: financial, risk and strategic fit. The project champion along provides the financial data. However, all members of the project selection team provide input into the risk and strategic fit components. Therefore, Lefley decided to compare the results in these two areas to see if he could identify any biases.

In the risk area, each team must determine a score for risk probability and risk impact. The team develops a collective group of risks and then individually scores each risk. Lefley then calculated the mean probability score for the project champion, the highest team member and the mean value for the remaining team members. In all mean risk measurements, the project champion had the lowest mean.

Click to enlarge

In the strategic fit area, each team member must evaluate the project against a list of weighted strategic benefits provided by the organization’s management team. The evaluation creates a strategic fit index for each team member. The team provides its judgmental values after each round of three discussions. Lefley calculated the mean index score for the project champion, the lowest team member and the mean value for the remaining team members. In all mean strategic fit index measurements, the project champion had the highest mean.

Click to enlarge

The results showed that the project champion felt the risks for this project were lower than the rest of the members of the selection team. In addition, the project champion felt that the strategic fit was higher than the rest of the members of the selection team. Lower risk and higher strategic fit will make the project appear more attractive than other projects. If the project champion scores were influenced by his biases toward the project, selection of this project might not be in the best interest of the organization.

Lefley realizes that further study must occur to understand fully the relationship between project champion biases and project selection. However, he believes that the biases of selection team members may influence project selection. In addition, through the development of an evaluation model like defined in this study, organizations can identify the biases early in the process and improve its project selection process.

References

Lefley, F. (2006). Can a Project Champion Bias Project Selection? Management Research News, 29 (4), 10.

Case Study: Project Selection and Change Management

noreply@blogger.com (Thomas Kennedy) — Sun, 13 Sep 2009 22:12:00 +0000

In a Kerzner (2003) case study, Corwin Corporation is an internationally known rubber products manufacturer with a reputation for quality. Corwin’s management is conservative and favors expanding markets for existing product over new product development. The company receives frequent requests to manufacture specialty products. A strict management policy and a risk adverse culture results in a 90% no bid on specialty product inquiries. However, Corwin selected to respond to a bid from one of its customers. The project was a complete failure and cost Corwin its relationship with the customer. This case study examines the mistakes Corwin made during the initiation and execution of the failed project.

Case Overview

The Peter’s Company is one of Corwin’s good customers. Corwin received a request from Peter’s to manufacturer a new rubber product. Peter’s had established a $250,000 budget for the project. However, they did not have the internal resources available to take on the project themselves. As a result, they decided to outsource the project and they wanted Corwin to design and manufacture the product for them.

Corwin was initially resistant to accepting the new project. Peters needed a proposal and acceptance from Corwin within a few days or they would lose the $250,000 budget for the project. However, Corwin was not comfortable with the required turnaround time. Peters offered a 5-year profit sharing deal to incent Corwin. One of Corwin’s managers instructed his staff to create a proposal for $250,000 to align with the Peter’s budget. Peters accepted the proposal.

The project started poorly. The project manager was not present at the kickoff meeting. In addition, Corwin allowed the customer direct access to engineering and manufacturing staff, which created a considerable amount of confusion and frustration within the Corwin organization. Continuous change and unclear requirements resulted in inconclusive results and additional frustration. The project quickly ran out of control. Ultimately, Peters terminated the project and Corwin was stuck with thousands of dollars in wasted project expenses.

Major Mistakes

Corwin made some major mistakes in its handling of the Peters project. The first mistake was in its project selection process. New product development does not fit within Corwin’s conservative, risk-adverse market expansion focus. Although Corwin had a product selection policy in place, they did not formally evaluate the request from Peters against the policy. Instead, management at Corwin allows the 5-year profit sharing incentive to influence negatively its decision making process. If Corwin had of followed its policy and process, the project might never have been accepted.

Corwin agreed to a fixed price contract. In a fixed price contract, the vendor takes on the majority of the financial risk. Fixed price contracts work well in situations where the requirements are clear and the vendor is confident that they can meet the requirements for the agreed price. However, the Peters project did not fit the criteria for a fixed price contract. Peters was only able to provide a rough draft of product specifications. Incomplete specifications are at high risk for change. Changes to product specifications can affect the cost, which can negatively affect Corwin in a fixed price contract. In addition, the contracts manager at Corwin was unfamiliar with fixed price contracts resulting in his inability to watch out for the best interests of the organization. If Corwin had followed its normal pricing process, they might have proposed a might higher cost for the project and Peters might never have accepted the proposal.

Senior management failed to engage in and support the project. Three of the four decisions makers were out of town during the proposal process. Due to the short turnaround requirements for the proposal presentation, senior management was unable to participate in the proposal process. In addition, senior management stayed at arm’s length during execution and only engaged once they became aware of major problems with the project. If senior management had been involved at the onset they might never have accepted the project.

Line managers were engaged too late in the process. Once the proposal was accepted, the project manager attempted to engage the line managers to obtain the resources needed to support the project. However, the line managers became upset because they were not involved earlier in the project. The project manager expected the line managers to provide resources to support the project but did not give them any opportunity to provide input during the proposal process. They were resistant to providing resources after the fact. If Corwin had involved its line managers early in the process, they might have been able to provide information that would have influenced the proposal.

Corwin decided to purchase all the projects raw material prior to formal contract signing. The procurement decision exposed Corwin to unnecessary risk. If a problem had developed between the companies before contract signing, Corwin might have been stuck with the expense of the raw materials. In addition, Corwin had only detailed five of 30 tests sufficiently to determine material needs. If the tests changed, the materials might have changed also.

Corwin did not use a structured change management process. The customer representative continuously changed the testing process resulting in inconclusive results. Since the contract was a fixed price, Corwin had to assume responsibility for costs related to the additional testing. When Peters requested an additional five tests beyond the agreed scope, Corwin should have evaluated the request and provided Peters with a proposal outlining the costs to add the tests to the scope. Uncontrolled change exposed Corwin to unnecessary risk.

Conclusion

In an attempt to please a good customer, Corwin accepted a project that did not fit its conservative and risk adverse culture. Corwin compounded this problem with additional major mistakes that eventually lead to its customer cancelling the project at significant cost to Corwin. This case study highlights the importance of a project selection process, senior management involvement and an organized change management process.

References

Kerzner, H. (2003). Project Management Case Studies. New Jersey: John Wiley & Sons.

Ignoring Projects Risks Can Lead to Project Failure

noreply@blogger.com (Thomas Kennedy) — Mon, 07 Sep 2009 22:05:00 +0000

As organizations grow and expand to other countries around the world, deploying upgrades and new systems across multiple locations and time zones can become complicated. As is outlined by Ram Garg (2008) in his article about Lucent’s Wireless Call Server, project risks that are ignored can lead a project to failure. This article review outlines the know and unknown project risk events the lead to the failure of the Wireless Call Server deployment project.

Known Risks

Lucent had set an objective to deploy a new Call Server to its locations in five different countries. They identified a series of risks that needed mitigation in order for the project to succeed. First, due to the location of the offices, they knew that time zones would complicate live communications between project teams. There was no common business time across all five locations. As a result, someone within the locations had to participate in the update calls after their local business hours. In order to ensure fairness across the team, they rotated the time of the call so that the members took turns participating after hours.

In addition, Lucent determined that about 20 percent of the time, one of the groups working on the project would be away on vacation or holiday. The scheduling group was able to collect this information in advance and incorporate it into the project schedule. As a result, the scheduling team was able to build a timeline that was appropriate to resource availability. Lucent further developed contingencies into the schedule to accommodate sick time and personal leaves for its project team members.

Most of the balance of the known risks focused on technical issues. Lucent was well aware of the technical challenges with the new Call Server deployment and they developed a top notch team of technical support analysts to address any issues that might come up during the early stages of the deployment.

However, as the project developed, Lucent identified additional risks that were unknown to them during the initial project-planning phase. Their inability to respond effectively to the unknown risk events are the key problems that contributed to its project failure.

Unknown Risks

Lucent had identified the need to have a local project manager in each of the five locations. The local project manager would manage the daily operations of project execution and would report updates and additional risks to the overall project manager. However, Lucent did not anticipate that the skill level of the local project managers would vary and their different approaches would cause inconsistencies across the execution phase. In addition, the project managers and the project teams were unclear about roles and responsibilities, creating additional con fusion across the project teams. The overall project manager lacked authority and credibility with the local project teams in each location. Instead of a collective global team, they functioned like five separate teams. As a result, the project developed in five slightly different directions and created unnecessary confusion and complexity across the project teams.

The centralized technical support team became another key problem. Lucent did not staff the support team to align with the local time zones of the five project teams. As a result, the team was overwhelmed during times with business hours overlapped. In addition, the local resources became frustrated when they could not get in direct contact with a support person during the support teams off hours. In response, the local teams began sending email messages with support problems. However, the email message rarely included all the information that the support team needed to resolve the project. The support team would send a follow-up message in which the local team would respond with additional information. The email support communications went on for days and sometimes weeks before issues were resolved, further delaying key components of the project deployment.

Staff turnover is another risk that Lucent did not anticipate. Project team members became increasingly frustrated with cross-team communications and ongoing schedule delays. As a result, some of the key technical skill within the teams left Lucent for other opportunities. Lucent had to recruit replacements and train them on the new systems before they could proceed with parts of the project. The staffing problem caused additional delays and frustration as the project teams started to direct blame toward each other. Project managers stopped sharing local problems with the collective team in fear of further finger pointing. Communications continued to break down. The atmosphere across the organization became so volatile that Lucent eventually decided to cancel the project.

Conclusion

Lucent had failed to identify key risk areas during the planning stages. In addition, they failed to respond appropriately when the new, previously unknown risk events occurred. Organizations will only continue to grow and expand across the globe. If they are to expect success in project execution, they will need to effectively identify and manage project risk. Without proper risk management, project risks can lead a project to failure.

References

Garg, R. (2008). Delivering Multiple Sites and Time Zone Projects. PM World Today.

Discussion Questions on Project Quality Management

noreply@blogger.com (Thomas Kennedy) — Thu, 03 Sep 2009 21:57:00 +0000

Quality Management is a key factor in managing customer expectations and ensuring that the project requirements are met. What tools and techniques are used to measure quality control?

I am going to take a major left turn on this one. When talking about quality, many think of the same types of quality work that is done in a production environment. In Project Management: A Systems Approach, Kerzner talks through seven tools that are used to measure quality control: data tables, cause-and-effect analysis, histogram, pareto analysis, scatter diagrams, trend analysis and control charts. But I don’t see these as the focus of quality in project management. Instead, I view quality as the degree to which the project meets requirements. The requirements that I focus on are the measures of time, cost, and scope.

Within scope is the list of the deliverables expected from the customer. Those deliverables should be described in enough detail that you can measure what is delivered to confirm that they meet the stated requirements. If they do, your quality for scope is good. The same goes for schedule. When you develop a schedule you should measure your performance against the schedule. If you are on schedule, your quality is good. Same for budget. So to me, quality is more than data tables and histograms measuring parts and pieces. Quality extends to the project management process itself, and yes, to the project manager. If the project is producing the desired scope, on time and within budget, the project manager is doing quality work.

Should we also provide the highest level of quality on every project?

Absolutely NOT. Producing quality beyond what is required is known as gold plating. Some believe that if you can give the customer extra stuff for nothing that you are providing higher quality. That isn’t the case because if resources on your team have time to do stuff that isn’t within scope, they are wasting time and money producing something that wasn’t asked for. As a result, they are costing the overall project more time and money that it would have cost if they had just focused on the requirements. The focus should be to meet the requirements of the project, not to exceed them.

When is too much quality a bad thing? Give an example.

Too much quality is a bad thing when it costs you more time or budget than it would have to provide the quality needed to meet the requirements of the customer. In other words, it is always a bad thing! Think of it this way… if you go to the ATM machine and request to take out $100 dollars and the machine gives you $100 dollars, you would consider this a quality transaction because it met your requirements. However, if it kicked out $120 dollars, it would have still met your requirements but it would have unnecessarily cost the bank an extra $20 dollars. Would you be happier as a customer? Absolutely! However, the bank would not be in business for long if it kept gold plating ATM transactions.

Discussion Questions on Project Scope Management

noreply@blogger.com (Thomas Kennedy) — Thu, 03 Sep 2009 21:48:00 +0000

Scope change management is an area frequently overlooked during a project. However, it is one of the most important areas of concern for a project manager as scope changes are typically the source of project overruns. What are the three most important elements in scope change management? Why?

I agree 100% about the importance of scope change management. I haven’t run a project in recent times that did not have changes to the scope at some point in the project. For me, the three most important elements in scope change management are schedule, budget and risk.

For every change we consider we evaluate the impact on these three elements. We determine the activities that we must add to the schedule in order to produce the added scope deliverables. We consider the additional costs related to producing the scope deliverables. We also evaluate the risks associated with adding the new scope. In the risk area, if the risk impacts the schedule milestones or our ability to produce the deliverables, we develop risk mitigation plans, which might include additional schedule and budget contingencies. So these three areas, schedule, budget and risk are always evaluated when we consider scope changes.

Who is responsible for scope change control?

I suspect many will say the project manager is responsible for scope change control. However, I don’t agree with that position. Everyone working on the project is responsible for scope change control. The project manager should facilitate the analysis, review, approval and implementation of formal scope changes, but the project manager is not able to fully control scope without the agreement from all stakeholders. Why? Because the project manager is unable to see all direct interactions between the stakeholders. For example, I have a person on my LA project team that is installing computers in the showroom. I am not there all the time, so I am unable to see the direct conversation that might occur from day to day. Someone in the showroom might ask him to add an additional computer to a workstation that is out of scope. He has the ability to fulfill the request, but in doing so he would be spending time and money on an activity that is not part of his assigned scope. So in order to have true control, everyone must understand and follow the scope change process.

Does the customer have the right to make changes to the project scope? If so, what constraints apply? If not? Give an example.

No. The customer does not have the right to make changes to the project scope. However, the customer does have the right to request changes to the project scope! Whether the request is to add or remove scope, the project manager should evaluate the impact of the change, submit the information to the change board and implement what is decided.

For example, at my company the projects I manage are for internal customers. The internal customers control the budget. However, we control the resources that implement the projects. So when the customer wants to add something to scope, even though they will fund the addition, the change still impacts project resources. We must evaluate the impact, review with the change board and implement what is approved.

Discussion Questions on Project Baselining

noreply@blogger.com (Thomas Kennedy) — Wed, 02 Sep 2009 21:42:00 +0000

A project baseline is essential in order to be able to determine the earned value for your project. This baseline is set at the start of a project and typically not modified. However, modifications are occasionally required.

To set the context for my answers below, we do not use formal EV calculations to report on project performance. Instead, we report progress against scheduled activities and the project budget through a simplified process. We also extend the typical baselining process to include the scope document, the schedule, the budget and the risk response plan. We only change the baseline in response to an approved scope change. When our internal customer and sponsor have approved the change, we update the scope, schedule, budget and risk plans to reflect the approved change. The updated documents than become our new baseline.

What magnitude of change results in the re-baselining of a project?

Our re-baselining is typically triggered by a scope change. Any scope change that adds activities to the schedule or increases the budget runs through our change management process. Once the change is approved, the baseline documents are updated and we continue working the project to the new baselines.

How might such a change impact the scope of the project?

As mentioned, at our company it is usually a scope change that impacts the baselines, not the other way around. We don’t typically run into situations where the schedule or the budget change—they are typically driven from the scope. However, in the event of a change in budget or schedule (for example, we are asked to cut 10% from the budget), we would process this just like any other change request. First we would evaluate the impact to the project. Next we would develop a list of the options available to support the request. Third, we would present the information to the change board, and finally we would implemented the approved change. In the example of a budget reduction, one of the options might be extending the duration of the project in order to push out some expenses to the next fiscal. Or we might recommend reducing scope to cut some cost out of the project. We will present the options and our recommendation and the change board either approves or sends us in a different direction. Once the decision is made we update the baselines for the four key documents and move on.

What can the project manager do if the customer does not accept the new baseline?

As described above, on occasion, none of the options presented by the team are acceptable to the change board/sponsor. As a result, we will brainstorm other options. However, no change is made without the approval of the change board. As a result, if the customer (to us it is our internal customer) does not accept the change, we don’t make one. We continue the project as currently approved. This process is probably much simpler for us internally than it would be for a company working with an external customer. For us the process is pretty black and white. If they internal customer wants to add scope to the project, we report back the impact on schedule, budget and risk. Yes, they have the ability to work with us to talk through options, but ultimately, they either accept the changes or they don’t get their new scope. Gotta like that!

What other individual expectations should the project manager manage when re-baselining a project?

When we re-baseline, we go back to each of the stakeholders and communicate the new baselines. They key is to ensure that everyone understands that a change was approved and also understands the impact of that change on the scope, schedule, budget and risks. The project manager is responsible for resetting the expectations of each of the stakeholders to align with the new project baselines.

Case Study: Small Project Cost Estimating

noreply@blogger.com (Thomas Kennedy) — Sun, 30 Aug 2009 21:36:00 +0000

In the Kerzner (2003) case study, Small Project Cost Estimating at Percy Company, Paul spends his first five years out of collage performing cost estimates for the Manufacturing Division of Percy Company. Percy issues fixed cost estimates for its projects, as indicated by the lengthy and costly procedure used to generate accurate quotes. Paul was promoted to a new position within the project office. His new responsibility was to coordinate all estimates for all divisions of Percy. During this time he did not perform any cost estimating.

After a year in the project office, Paul was assigned to a small projects division. The first five estimates that Paul created were accurate. However, the sixth estimate was off by $20,000, causing an expensive cost overrun. The case study asks to answer the question, “Why did the overrun occur?”

The case study does not provide enough detail to determine the actual root cause of the cost overrun. However, the case study points to a lengthy and costly procedure used to generate accurate fixed price quotes. Kerzner warns that fixed cost quotes have the “disadvantage of requiring a long period for preparation and adjudication of bids” (2003, p. 820). The case study also indicates that the small projects division is unable to afford the cost of the lengthy estimating procedure. From Paul’s perspective, if he was unable to follow the estimation procedure that he was taught as a member of the Manufacturing Division, he is less likely to generate accurate cost estimates.

The first five projects could have been very similar to previous projects and Paul was able to use previous cost estimates to create his estimates. However, the sixth project could have been very different and required a more thorough cost estimating procedure. In addition, due to the duration that had passed since his previous role in the Manufacturing Division, the cost of materials or labor could have changed and Paul might have been unaware of the change. Regardless of the cause, Percy can solve the problem.

According to Kerzner, an organization should “only consider fixed bid contracts if the manufacturing requirements are known exactly” (2003, p. 820). As indicated by the case study, the small cost projects are unable to “withstand the expenses needed for formal divisional cost estimates” (2003, p. 146). To address this problem, Percy should consider a cost-plus contract format for the small projects division.

References

Kerzner, H. (2003). Project Management Case Studies. New Jersey: John Wiley & Sons.

Kerzner, H. (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. New Jersey: John Wiley & Sons.

Discussion Questions on Project Risk

noreply@blogger.com (Thomas Kennedy) — Fri, 28 Aug 2009 21:25:00 +0000

Risks can be categorized in three categories: known knowns, known unknowns, and unknown unknowns. After categorizing risks, the project manager should then mitigate those risks.

Can all risks be mitigated? Explain.

Mitigate is only one of three risk treatments that we use when managing risk at my company. Mitigate means to reduce the probability or impact of a risk event. This is option two for us. Option one is to eliminate the risk by eliminating the cause of the risk. For example, let’s say I need to be in LA next week to perform acceptance testing on the technology installed. One risk is travel delays due to bad weather. To eliminate this risk I could travel a day or two in advance to ensure I had adequate time to get to the site before the testing is scheduled to begin.

If we aren’t able to eliminate a risk we look for ways to mitigate it. We look at impact and probability separately. We might be able to do something that reduces the impact of a risk even if we can’t reduce the probability. For example, when we open our new showroom in LA one risk is that we have a technical problem during the opening day show. We have done everything we can at this point to test the systems to ensure they are working properly, so we can’t do much more to reduce the probability of a problem. However, we can reduce the impact by having a technical resource on-site during the show. In that way if something does go wrong we can respond to it quickly and minimize the impact to the people at the show.

The third treatment is to transfer the risk to a third party. For example, if the showroom burns down, we can transfer the financial risk to an insurance company. Purchasing fire insurance does not reduce the probability of a fire but it does reduce the financial impact.

How would you assess the probability of a risk occurring and the impact that risk has on your project?

We have a risk matrix that we use to evaluate probability and impact on projects risks. Typically during the early stages of project planning we will brainstorm a list of potential risks. We also leverage risk documents from previous projects to help develop the list. Once we have the initial list we talk through each task and try to assign a high/medium/low rating for impact and probability. This is purely a subjective measure. However, the combination of impact/probability generates a priority rating for each of the risks which we then use to determine which risks we will work on further.

For the risks that score above a certain level we develop risk response plans and we add contingency to the schedule and the budget. We use a % system to determine the contingency amount. For example, if the plan to respond to a certain risk will cost $50,000 and add 4 weeks to the schedule, if we think there is a 10% chance of it happening, we will add $5,000 to the budget and 1 day to the schedule. Some risks will become reality, others will not. The percentages balance out over the project.

How should project managers deal with risk events?

In our environment we have people responsible to watching the risk events or triggers. Assuming the project team has developed risk response plans (and identified the triggers), the project manager should ensure that the person assigned to the risk event activates the appropriate response plan.

Discussions on Project Procurement

noreply@blogger.com (Thomas Kennedy) — Fri, 28 Aug 2009 21:19:00 +0000

During the procurement execution stage of a project, the project manager must determine whether to make or buy a product. The project manager must also assist in the selection of vendors to supply products/components necessary to complete the project. What criteria should be analyzed before reaching the make or buy decision?

Kerzner provides a list of considerations in his Special Topics chapter in his project management text, Project Management: A Systems Approach, starting with cost. Cost can be a consideration if the vendor is able to complete the work more cost effectively. However, other factors might hold more weight than cost. For example, in my recent LA project we outsourced the audio/visual. The primary reason wasn’t cost—it cost about twice as much to outsource it than it would have cost to do it ourselves. In this case we outsourced because the capabilities of what we wanted in the new showroom were beyond our internal capabilities, which is the seond on Kerzner’s list--added expertise.

I like that Kerzner also lists minimization of company risks. When we outsourced the audio/visual we negotiated a fixed price contract. As a result, the cost risk to our company was mitigated. Some might argue that you pay more in fixed price contracts. That might be the case, but our concern was locking in the budget and ensuring we were able to meet scope, not getting the least expensive price.

The last item Kerzner mentions is focusing on essential items. We refer to this internally as our core competency. If we need to accomplish something that isn’t directly related to our core competency, we will put more emphasis on outsourcing. If we don’t need to use up our valuable internal resources and can hand it off to an external resource, we are very open to that.

How does your organization select its sources?

My company has a large number of preferred vendors that we use for work all over the world. We are very loyal to our vendors. So we will continue to work with the same vendors year after year, assuming they are meeting our needs. However, if we have a need that isn’t met by an existing supplier, we will seek a new partnership.

Depending on the size and scope of the work to outsource, we typically go through an RFP process. We define our requirements, work with a number of sources to find qualified bidders, maybe initially issue a RFQ to help narrow the field, hold bidders conferences, etc. We will try to narrow to two or three bidders to negotiate the final pricing and contract.

What are some differences between contracting and outsourcing?

We use the terms interchangeably. However, some view contracting as bring in outside resources to temporarily offset an internal labor shortage. For example, if I need a couple of additional people to help with a Windows 7 deployment, I might contract those “bodies” from a temp agency. We manage the work and the temp agency provides the bodies. In contrast, outsourcing is assigning the work to another company. Continuing with the Windows 7 example, we might hire an external company to perform the upgrade for us.

Discussion Questions on Project Execution

noreply@blogger.com (Thomas Kennedy) — Thu, 27 Aug 2009 21:03:00 +0000

Project execution affords the opportunity to adhere the project plan and its various components. What are the key elements of project execution?

The key elements of project execution are the project scope, the project schedule and the project budget. The scope defines the work that must be done in order to achieve the objectives of the project. The scope items are broken down in WBS elements and time phased to develop a project schedule. Costs for each activity in the WBS are rolled back up to form the project budget.

What is the relationship between a project charter and the project manager's ability to successfully execute a project?

According to Kerzner, the primary purpose of the project charter is to assign authority and responsibility to the project manager and to define at a high level the business purpose for the project. The charter is used by the project manager to request resources from line manages and to ensure the project team is clear about the objectives and initial scope of the project.

As a project manager, what areas would you monitor to ensure project execution is on track?

As a project manager, I focus on scope, schedule and budget. For scope, I ensure the project team is working on the approved scope items and only the approved scope items. I also monitor the specific activities within the project schedule, giving additional attention to the activities on the critical path. Finally, I watch spending against the approved budget to ensure that costs will align with the approved plan. If the team is working on items that are in scope, completing their activities on time and staying within budget, I consider the project execution on track.

How often would you review the project's progress?

The frequency in which I monitor the project’s progress depends on the stage of the project. Typically I meet weekly with the project team and update the core PM documents (scope, schedule, budget). However, during some parts of execution I might meet daily with the project team to ensure the execution is going as planned. For example, I am just finishing a project to build a new showroom in Los Angeles. The project has taken about 8 months from charter approval to the current stage. During that time we had a 2 week period where our key resources were on-site installing the phone system, network, computers, audio/visual and office equipment. I met weekly with the team throughout the project except during the two week on-site installation—we met daily during the actual on-site implementation.

Properly Initiating a Project

noreply@blogger.com (Thomas Kennedy) — Sun, 23 Aug 2009 20:49:00 +0000

During the first week of University of Phoenix’s Project Management Capstone course, students learn about three areas involved with properly initiating a project: project proposals, project selection methods and project chartering (University of Phoenix, 2009). Each organization develops strategic plans and many of the strategies are implemented through tactical projects. Departments within the organization develop proposals based on the strategies and the organization selects the proposals based on priority and potential benefit to the organization. Once a project is selected, the project sponsor creates and issues a project charter and the assigned project manager plans, executes and closes the project, successfully meeting the objectives outlined in the charter. At least that is how project initiation is supposed to work. But what would happen if the objectives were not clearly outlined? If the sponsor did not issue a charter, could that negatively affect the project? What if there was no sponsor? This paper examines the potential negative impact of improperly initiating an information technology (IT) project and provides recommendations for improving the project initiation process.

The Problem

A group within the IT department of a "company that shall remain nameless" was responsible for supporting the desktop computer environment. In the late 1990s the IT department was preparing to move the desktop environment to Windows 2000. However, the custom written software distribution system used by IT was not compatible with the new version of Windows. In addition, the developers who wrote the application were no longer with the company and the source code was unavailable.

IT management instructed the group to find and implement a replacement software distribution system so it would be in place in time for the Windows 2000 migration. The team worked to identify the industry leading Windows 2000 compatible software distribution systems and brought each in for a presentation. The team liked one of the presentations particularly well and recommended to management that they purchase the system. Management made the purchase and the team was instructed to deploy the new system.

Everything seemed fine until the team started working with the software. They quickly realized that the software was much more complicated than they had expected and that it did not function the way that they had anticipated. In addition, the team was not clear about what was expected from them. Management seemed to have a different idea of what the system was intended to do. The lack of clear direction and confusion within the team created a stressful environment. As time went on and the team was unable to show results from the software purchase, members within the team started blaming each other for the poor decision. What had started out as a simple request, to replace the software distribution system with one that was Windows 2000 compatible, had turned into a complicated, stressful and expensive mess.

The Opportunity

Management turned to one of its seasoned IT project managers to resolve the project. The project manager had a history within the organization of successfully rescuing projects. The project manager met with the team to learn as much as he could about the project’s history. He quickly identified four problems. First, management had not identified a project sponsor to support the project. Second, management had identified the problem they were trying to solve (Windows 2000 compatibility), but they did not provide any objectives or requirements for the solution. Third, the project did not have a formal project manager. And fourth, there was no formal documentation to launch the project officially.

The project manager decided to start the project from scratch. He worked with management to identify a project sponsor and worked with the sponsor and the IT team members to identify the business problem, the business and technical objectives and requirements and documented each within a formal project charter. The project sponsor signed the charter and distributed it to the affected teams within IT.

The project manager then worked with the IT team members to develop a Request for Proposal and an evaluation matrix to use to evaluate the proposal responses. The project team evaluated the responses against the matrix and selected a new solution that was a close fit to the business and technical objectives and requirements of the project. The project manager lead them through the rest of the planning, executing and closing phases to help the team successfully meet the project objectives.

Closing

Project managers should follow the project initiation best practices, like the IT project manager did at this company. By following a structured process during the initiation phase of the software distribution system replacement project, the IT project manager was able to establish a clear foundation from which the team could work. By working with a project sponsor to document the business and technology objectives and requirements within a project charter, the project manager was able to obtain the authority and clarity needed to effectively lead the project team to a successful implementation.

References

University of Phoenix. (2009, August 11). Week 1 Topic 1: Project Initiating Processes. Retrieved August 2009, from CPMGT/305 Project Management Capstone: https://ecampus.phoenix.edu/classroom/ic/classroom.aspx

Discussion Questions on Project Risk

noreply@blogger.com (Thomas Kennedy) — Thu, 20 Aug 2009 19:55:00 +0000

Project risks can/cannot be eliminated if the project is carefully planned. Explain.

Project risks cannot be eliminated by careful project planning. A risk by definition is an event that might occur. If you are certain it will or will not occur, it isn’t a risk! However, through careful planning a project team can reduce the likelihood or impact of a risk.

The chances of risk events occurring and their respective costs increasing change over the project life cycle. What is the significance of this phenomenon to a project manager?

Project risk is highest during the early stages, when the project team is still flushing out the detail and the actual work is still in front. The amount of risk reduces as work is successfully completed and as the team gains a better understanding of the details. This is important for the project manager. The more information and clarity the PM can obtain early in the project the less risk or unknowns the PM will need to deal with later in the project. In contrast, some projects just don’t have the level of detail needed during the early planning. This should prompt the PM to add reserves to both schedule and budget to accommodate the risks associated with the lack of detailed information.

Explain the difference between budget reserves and management reserves.

I’ve seen different terms used depending on who you read. I use contingency reserves and management reserves. A contingency reserve is a time or money allocation assigned to an identified risk. The project manager typically has control over the contingency reserve. A management reserve is a separate fund set aside to address the unknown unknowns. The management reserve is typically controlled by the management team or the project sponsor.

How are the work breakdown structure and change control connected?

Assuming the project has an actual change control process in place, any approved changes trigger updates to the project management documents. This includes the scope of work, the project schedule (which can be build from the WBS), the project budget, communications documents, risk management plan, so on and so forth. However, if the project team does not follow a formal change control process there might be no connection between the two.

What are the likely outcomes if a change control process is not used? Why?

I think it depends on the project. For a simple project that will only take a few days and only involve a couple of people, the lack of a change control process might be irrelevant. However, for a larger project that has a longer duration and many people involved, the project could quickly spin out of control without some form of change control. I am just finishing a project in LA for a new showroom we just built for my company. We established a change process early and used it about 6 times through the project. Each time when we received a scope change request we evaluated the impact on the other areas of the project and provides that information for the sponsor to review. This gives the decision makers the information they need to make solid (or at least better informed) decisions. All six of the change requests were accepted. However, the key advantage to me as the PM and the team is that we were able to handle the changes in a structured manner.

Discussion Questions on Project Network Construction

noreply@blogger.com (Thomas Kennedy) — Thu, 20 Aug 2009 19:48:00 +0000

Define activity, event, and path as used in network construction. What is a dummy activity?

According to Kerzner, an event is the starting or end point for a group of activites. An activity is the work required to proceed from one event or point in time to another. A path any sequence of activities and paths. Dummy activities are artificial activities use to show dependencies between events but do not consume resources or time like a typical activity.

What characteristic of the critical path times makes them critical?

The critical path is the longest path through a network diagram or between milestones. If an activity takes longer to complete than expected, the added duration will negatively impact the start/complete dates of the balance of the activities, also pushing out milestones on the path and the potentially the end date of the project.

What two factors are compared by Gantt charting?

Gantt charts are used to plot activities or events against time or dollars.

How does the Gantt chart differ in purpose from the project master schedule?

Traditional Gantt charts are just bars spread over a time scale. As a result, they do not show activity interdependencies and other information like network diagrams do. Kerzner states that without the interdependencies, the bar charts have little predictive value. However, using modern software like MS Project, the PM can modify the traditional bar charts to include activity interdependencies.

What are some benefits of the network approach to project planning? What are some drawbacks?

Kerzner provides a list of the benefits in the text. I won’t relist them here. Instead, I want to highlight one that I feel is the most important. The network approach helps to identify the interdependencies of activities. I use MS Project to schedule the activities for my projects. We have a structured approach to developing the schedules. We typically work with experts in each area to identify the tasks needed to complete the requirements or deliverables. We assign resources . We identify the duration of each activity and we identify the interdependencies. It is the interdependencies that bring the schedule to life. Without interdependencies between the activities, you just have a long list of tasks that all start on the same date and end on different dates depending on the duration assigned. Without the interdependencies you will have people trying to start stuff that they can’t actually start because they relay on something else being completed. The interdependencies are the biggest benefit of the network diagram. But they can also be a drawback. Interdependencies can become very complicated, especially on larger projects with multiple departments and plans. The trick is to keep the network diagrams simple enough to work with but still have enough detail to drive the right activities at the right time.

Should the critical path activities be managed differently from noncritical path activities? Explain.

Absolutely. Activities on the critical path directly impact milestones on the critical path and potentially the end date of the project. The project manager should focus more attention on critical path activities because of the impact on milestones and the overall project. However, this doesn’t mean the PM can ignore noncritical path activities. Some paths within the network can become critical paths if the activities on the path slip far enough to chew up the slack. So the PM must close attention to the critical path activities while also keeping an eye on activities that might become critical.

Reference

Project Management: A Systems Approach to Planning, Scheduling, and Controlling, by Harold Kerzner.

Lying and Deception in Project Contract Negotiations

noreply@blogger.com (Thomas Kennedy) — Mon, 03 Aug 2009 19:00:00 +0000

Is it unethical to lie during contract negotiations? How about deceptive negotiating tactics? Are they unethical? Business people do it all the time—they hide their true intentions or stretch the truth in order to win. The United States Court of Appeals recognizes that “both sides presumably try to get the best deal” and that “no particular demand in negotiations could be termed dishonest” (Shell, 1991). If everyone is doing it, what is the problem?

According to an article published by Richard Shell (1991), business people commonly use some form of deceptive behavior when negotiating a contract. For example, the seller might impose some form of deadline in order to attempt to pressure the buyer into signing an agreement. Or, the buyer might deceptively communicate she will not budge on an issue, in essence lying about her true intentions. Many would question the ethics of these business practices, but Shell raises a greater concern: the courts might consider some unethical behavior or statements as fraudulent.

The Fraud Litmus Test

A statement is fraudulent when “the speaker makes a knowing misrepresentation of a material fact on which the victim reasonably relies and which causes damages” (Shell, 1991, p. 1). The definition provided by Shell appears straightforward. However, expanding on the four key areas, knowing, misrepresentation, material and fact, will help a negotiator better see and understand the fine line between unethical and fraudulent negotiating tactics.

Knowing

If a negotiator makes a statement that he knows to be untrue, this behavior can meet the first criteria for fraudulent negotiating tactics. In addition, even if the statement is not a direct lie but is a conscious disregard for the truth, Shell indicates that the courts have stretched the definition of knowing to include these reckless statements. However, the knowing test is not restricted to statements made by the negotiators. If the negotiator selects to ignore internal information in order to avoid sharing undesirable information, the courts could treat this as if the person knowing made a false statement.

Misrepresentation

According to Shell (2001), “the law requires the speaker to make a positive misstatement before it will attach liability for fraud.” In other words, in order to misrepresent information, one of the parties must ask or raise an issue and the other party must respond with inaccurate or incomplete information. However, misrepresentation also extends to situations where one party has information vital to the negotiation and knowingly withholds disclosure of the information. Shell (2001) notes that the “legal test of disclosure is whether equity or good conscience requires that the fact be revealed.”

Material

Knowingly misrepresenting information is not enough to quality as fraudulent behavior. In addition, the information that is knowingly misrepresented must be material to the contract. Shell (2001) defines material as “information that is essential to making decisions during negotiations” For example, if one party fabricates the involvement of a competitive vendor in order to create price leverage, information about the involvement of a competitor is material to making decisions during negotiations.

Fact

Shell (2001) defines fact as “any information that one of the parties represents as true and accurate.” If the information is false, this negotiating tactic could meet the fact criteria for fraudulent behavior. In addition, if one of the parties makes a statement about his intentions but does not truly intend to do what is stated, the courts could consider this as fraudulent behavior. Shell (2001) points out that “the courts consider it fraudulent when statements are made that are designed to conceal a set of facts detrimental to the negotiator’s position.”

Applying the Criteria

The University of Phoenix provides a class on Procurement and Risk Management. Two of the objectives of the class are to identify contract award criteria and to analyze ethical issues related to the contracting process. As part of the assigned reading for the class, Huston (1996) outlines recommendations for contract award criteria. In order to create pricing leverage, Huston recommends negotiating with at least two vendors. In addition, organizations should develop an evaluation matrix that is used to compare objectively vendor Request For Proposal (RFP) responses.

Through the use of award criteria and the evaluation matrix, Huston states that the buyer should award the contract to the vendor with the highest score. However, what if a company negotiates with more than one vendor to create cost leverage while they fully intend to award the contract to a preferred vendor? Is this behavior unethical? Does this behavior meet the requirements for fraudulent negotiating tactics?

The Network Negotiation

The situation described recently happened during a network contract negotiation at my company. We were building a new office in the Los Angeles area. They had contacted three vendors and asked for responses to a network cabling RFP. However, based on a glowing review from the local contractor working on the project, my company intended to award the contract to the vendor recommended by the contractor. By continuing to involve the other two vendors, my company was able to leverage the competitive nature of the negotiations to drive the preferred vendor’s cost down.

If the preferred vendor was unable to meet the RFP requirements, my company would have awarded the deal to one of the other vendors. However, if all three vendors met the requirements and were within a small cost margin, they intended to award the contract to the preferred vendor. The negotiators did not communicate their intentions to the other vendors. Some might view this behavior as unethical while others would consider it a savvy approach. However, does this behavior meet the criteria for fraudulent negotiating tactics?

Knowing

The negotiators at my company clearly knew about their intentions to award the contract to the preferred vendor. In addition, if the negotiators selected to ignore this internal information in order to avoid sharing undesirable information, the courts could treat this as if the person knowing made a false statement. In this area, the intentions toward the preferred vendor could meet the first criteria for fraudulent negotiating tactics.

Misrepresentation

As mentioned earlier, the vendors did not ask the my company negotiators about its intentions. As a result, my company did not directly misrepresent the information about its preferred vendor. However, misrepresentation also extends to situations where one party has information vital to the negotiation and knowingly withholds disclosure of the information. Had my company disclosed their intentions to award the contract to the preferred vendor, that information might have directly impacted the negotiations of the other vendors. In this area, the intentions toward the preferred vendor could meet the second criteria for fraudulent negotiating tactics.

Material

All three vendors were aware of their competition during the RFP process. From the vendor’s perspective, knowledge of the preferred vendor might have been essential to making decisions during negotiations. With that knowledge, one or both of the vendors might have decided to reject the RFP and focus their energy on other opportunities. In this area, the intentions toward the preferred vendor could meet the third criteria for fraudulent negotiating tactics.

Fact
As previously stated, Shell (2001) defines fact as “any information that one of the parties represents as true and accurate.” My company did not communicate any inaccurate information regarding its intent toward the preferred vendor. In addition, the negotiators did not make any statements that inaccurately represented its intentions. Furthermore, my company did not make any statements that were designed to conceal any facts related to the preferred vendor. As a result, the intentions toward the preferred vendor do not meet the fourth criteria for fraudulent negotiating tactics.

Conclusion

Is it illegal to lie during contract negotiations? Are deceptive negotiating tactics illegal? As outlined above, if the tactics meet certain criteria, the courts might rule them as fraudulent. However, is the legality of negotiating tactics of most importance? A tactic that is legal is not necessarily ethically right. H. Ross Perot is quoted as saying, “Do not govern your life by what is legal or illegal; govern it by what is right or wrong” (Shell, 1991, p. 9). If a negotiator focuses on what is ethically right during contract negotiations and avoid what is wrong, the negotiator probably will not need to worry about the legality of the negotiation tactics.

References

Huston, C. L. (1996). Management of Project Procurement. The McGraw-Hill Companies, Inc.

Shell, R. G. (1991). When Is It Legal to Lie in Negotiations? Sloan Management Review , 9.

Risk Management in Project Contracting

noreply@blogger.com (Thomas Kennedy) — Sun, 02 Aug 2009 18:29:00 +0000

Risk management is an important part of the project contracting process. Cooper (2005) positions contracts as a tool to help allocate or transfer risk in business transactions. The contract is intended as an “agreements between parties for the conduct of specific actions or functions, in return for consideration” (Cooper 162). Through a properly executed and managed contract, both the customer and its vendors are able to more effectively manage risks related to development projects.

Contracting Risks

The contracting process has some inherent risks. First, both the buyer and the seller must ensure risk is appropriately balanced between the parties. Unless there is a risk balance for the roles and responsibilities of the parties, one of the parties is taking on an imbalance that could negatively affect its business should there develop conflict in the relationship.

Ambiguity is another risk related to the contracting process. Ambiguity is the possibility for one or more of the parties to interpret information in more than one way. Lack of detailed requirements or unclear roles and responsibilities can create ambiguity between the parties.

In addition, the type of contract selected will impact risks associated with the contracting process. Huston (1996) identifies four primary types of contracts: fixed price, unit price, target price and reimbursable contracts. Each contract type has its strengths and weaknesses for both the buyer and the seller.

Resolving Contracting Risks

According to Cooper, the basic principle of the contracting process is to “allocate risk to the party best placed to manage it, through specific wording in the contract document” (Cooper 162). This approach is used to help develop balance between the contract parties. By clearly defining roles and responsibilities and determine which party is best suited to accomplish contract tasks, the parties are able to ensure the most qualified party is able to control the outcomes of its portion of the contract.

To address risks related to ambiguity, the parties must write the contract clearly so to minimize any confusion about the requirements of the work to be performed. As the clarity of requirements increases, the risk associated with misunderstanding and conflicts reduces. Some buyers might consider the extra work needed to develop clear requirements as lengthy and costly; however, the investment on the front end can greatly reduce the risk of conflict during contract execution.

The buyer and seller must select a contract type that best aligns risk with the responsibilities outlined in the contract. For example, a fixed price contract will provide the most cost risk management for the buyer but increases cost risk for the seller. In order to maintain a risk balance between the parties and to reduce ambiguity, the buyer must provide clearly defined requirements so that the seller is able to determine the costs associated with delivering to the buyers expectations.

Finally, the parties must ensure a process is in place to manage the contract relationship. Cooper says even a well written contract can fail if not managed appropriately. The parties should discuss, and if possible build into the contract, the processes and procedure to ensure successful management of the contract.

Works Cited

Cooper, D., Stephen, G., Raymond, G., & Walker, P. (2005). Project Risk Management Guidelines: Managing Risk in Large Projects and Complex Procurements. West Sussex: John Wiley & Sons Ltd.

Huston, C. L. (1996). Management of Project Procurement. The McGraw-Hill Companies, Inc.

Requests for Proposal in Project Management

noreply@blogger.com (Thomas Kennedy) — Mon, 27 Jul 2009 18:26:00 +0000

The information technology (IT) department within my company uses Requests for Proposals (RFP) when obtaining products or services from vendors outside of the organization. A RFP is a “type of procurement document used to request proposals from prospective sellers of products or services” (Project Management Institute, 2004, p. 371). Although the IT department uses RFPs as part of its standard procurement approach, my company can improve its approach by incorporating RFP best practices into its standard process.

RFP Best Practices

The best practices for managing the RFP process generally fall into six categories of activates: planning, creating, issuing, evaluating, and awarding. Each area will vary depending on the products or services that are procured. However, the following best practices provide a solid baseline to work from.

Planning the RFP

RFP planning is the “process of documenting project purchasing decisions, specifying the approach, and identifying potential sellers” (Project Management Institute, 2004, p. 316). The first step in the planning process is to determine which products and services the organization will develop internally, or procure from an external source. Know as a make or buy analysis, the results of this process can vary widely depending on the project and its procurement needs. In addition, for each team, the team needs to determine the type of contract that they will use to management the procurement. General categories for contract types include fixed-price, cost-reimbursable and time and materials contract. Contracts are often used to help manage the risk associated with procuring products and services from external vendors.

Once the products and services are identified and the contract type is determine, the team can focus on determining the resources needed to develop the contents for the RFP. Resources might come from within the organization, externally or a combination of the two. As part of the process, the project team should develop a responsibilities matrix in order to provide clarity about the roles of each person involved with developing the RFP.

In addition, the project team will develop an initial list of potential vendors that will be able to respond to the RFP. Organizations might use vendors from previously established relationships. However, if the procurement is for a unique product or service, the project team will need to find vendors that are qualified to response to the RFP. Using internet groups like LinkedIn or advertising in public papers are a couple of ways to find potential suppliers.

Once the planning is complete, the project team should document the procurement plan and all related decisions in a procurement statement of work.

Creating the RFP

Once the planning is complete, the project team shifts its focus to creating the RFP document. The organization should have clearly defined corporate policies and procedures and use standard templates for its RFP and procurement documents. In addition, the RFP should include “standard terms and conditional and any other items that the buyer specifies to establish what the seller is to perform or provide (Project Management Institute, 2004, p. 315). Other items include product or service technical specifications with the level of detail tailored to the needs of the project.

Once the initial RFP draft is complete, the organizations legal department should review the contents before the document is issued to prospective bidders. The legal department will ensure that “the language describes the products, services, or results that will satisfy the identified project need” (Project Management Institute, 2004, p. 315).

Finally, the project team will create the criteria using a weighting system that they will use to evaluate vendor responses. The team should create the evaluate criteria before review vendor responses to ensure its evaluate is as objective as possible.

Issuing the RFP

Once the project team has created the RFP, they send it out to the previously identified bidders. The team might send out a scaled back version of the RFP, a Request for Information (RFI), to the initial list in order to narrow down the prospective bidders. The RFI can also serve as a tool to help identify areas within the RFP that need further information or clarification.

In addition, the project team might elect to hold a bidders conference. In a bidder’s conference, the prospective bidders are brought together and the project team reviews the details of the RFP. The bidder’s conference allows the vendors to ask questions and to seek clarify about the desired products and services. This process also benefits the buyer because they are able to update the RFP with the additional information needed for the vendors to respond accurately to the request.

Evaluating the RFP Responses

After a predetermine amount of time has passed, the project team will open and review initial proposals from each of the bidders. The initial review is an opportunity for the project team to determine if the proposals obtain sufficient information to perform the evaluation. The project team will answer open questions and clarify details as necessary. The answers and clarifying detail is sent to each of the bidders to ensure each is working from the same base information.

Once the project team has reviewed the proposals they will evaluate each response against the evaluation criteria. Through the initial evaluation the team should reduce the number of vendors to two or three, known as the short list, in order to simplify the contract negotiating process. However, the team should continue to negotiate with at least two vendors in order to maintain price leverage. The team will continue to negotiate the pricing, terms and conditions of the contract with each of the short list vendors until they are able to arrive at a mutually beneficial agreement.

Awarding the Contract

The final step in the RFP process is to award the contract. Typically the final selection is made by the project sponsor or senior management in response to the evaluation results and the recommendations of the evaluation team. Generally speaking, Hulston (1996) recommends awarding the contract to the vendor that scores the highest on the evaluation.

Once the vendor is selected, the project team will notify each bidder of the RFP selection decision. The organization will work with the winning bidder to formalize the contracted negotiated during the evaluation process. In addition, the project team will update its project management documents to reflect the decisions made during the process and to reflect the new contract relationship.

My Company's RFP Process

The IT department at my company uses some standard practices to manage its RFP process. However, my company can improve its approach by incorporating RFP best practices into its standard process. The following sections will outline my company’s processes and recommend improvements in each area.

Planning the RFP

The IT department follows the first step in the planning process by determining which products and services they will procure from an external source. However, for most projects they do not perform a formal make or buy analysis. Instead, they rely mostly on expert judgment and experience to select the products or services to outsource. In addition, IT negotiates fixed-price contracts. My company believes fixed price contracts help reduce its cost-related contracts. However, unless the scope and requirements are fully determine prior to contract signing, my company opens itself up to cost increases incurred as a result of change requests. In addition, the IT department is often unable to define the deliverables of the project in enough detail to define fully the scope of the project. The lack of detail further exposes my company to change requests and increased costs. In order to create enough detail for more accurate contracts, my company should spend additional time on the front-end planning for projects that require external procurement.

My company does a good job of identifying potential vendors. Due to its global presence, the IT department has established relationships in most markets and the products and services they procure are industry standard. However, my company should occasionally revisit its list of standard vendors in order to improve negotiating leverage.

Creating the RFP

The procurement group at my company has established default supplier agreements that are used for all procurement. In addition, my company has a clear set of policies and procedures that project managers are expect to follow when interacting with potential suppliers. However, the actual RFP documents differ widely across the departments within IT. The RFP documents are typically created from scratch for each project. my company can improve its RFP process by develop standard templates to use for its RFP documents. In addition, as part of the lessons learned after each projects, my company should develop a feedback mechanism that will allow for adjustments to the templates to improve the RFP documents for future projects.

In addition, my company is inconsistent in its use of a legal review as part of its RFP process. The legal department is involved with the final contract terms and conditions. However, the RFP process would benefit from involving legal sooner in the process.

Finally, the use of formal evaluation criteria is inconsistent at best. Most of the selection is perform subjectively by the project team and management will rely on the team’s recommendations. The subjective nature of the decision can become problematic if a conflict later exists with the vendor and management must reassess the selection process.

Issuing the RFP

The IT department at my company does a good job of issuing and managing RFP responses. When appropriate, the IT department will hold bidders conferences and they ensure that any follow-up information is distributed to all responding vendors. my company believes in keeping the bidding process as fair as possible.

my company will also keep at least two bidders in the RFP process in order to provide leverage in negotiations. In addition, they will try to eliminate as many vendors as possible early in the process in order to reduce its workload and to ensure vendors that have little chance of winning the bid do not invest time in the process if unnecessary.

Evaluating the RFP Responses

The primary concern for my company’s evaluation process is the lack formal evaluation criteria. As addressed earlier, most proposals are reviewed subjectively. The team discusses the pros and cons of each proposal and works together to select the solution that they feel provides the most value to my company. Historically this has worked fine for my company, but they could benefit significantly through the use of formal evaluation criteria.

Awarding the Contract

Finally, my company does a solid job of awarding its contracts. The IT department involved the legal team to ensure contracts are clear and that everyone involved with managing the ongoing relationship understands the roles and responsibilities

Conclusion

In general, the IT department at my company has an RFP process that works well for them. As outlined, IT could improve its process by adding a make or buy analysis, considering other contract types, developing standard templates for RFP documents and developing formal evaluation criteria for each project. By adding these additional best practices my company can improve on an already excellent RFP process.

References

Huston, C. L. (1996). Management of Project Procurement. The McGraw-Hill Companies, Inc.

Project Management Institute. (2004). A Guide to the Project Management Body of Knowledge. Newtown Square: Project Management Institute.

Contracts in Project Management

noreply@blogger.com (Thomas Kennedy) — Mon, 20 Jul 2009 18:06:00 +0000

Procurement and project management have many integrated relationships, one of which is controlling procurement risk through the use of contracts. In an article written by John Kavanagh, the author describes a speech delivered to the British Computer Society by BCS fellow and vice president Rachel Burnett where she positioned contracts as an investment as opposed to an expensive list of restrictions. By investing the time to develop clear contracts, both the buyer and the seller can control risk and reduce the need to use litigation to resolve disagreements.

Contracts Reduce Risk

Kavanagh says that Burnett advises as part of a standard project management process to use contracts to reduce procurement risk. A contract should be “a checklist and a reference point for project risk management, not a dry legal document forgotten about in a drawer” (Kavanagh, 2004, p. 1). By investing in the development of a contract during the procurement process, Kavanagh says that the overall procurement experience will cost less and will reduce risk. However, both Kavanagh and Burnett recommend keeping the contracts simple and that the contracts should be organized in such a way so that the information in the contract is useful for managing the procurement and project risk.

The Burnett speech was delivered to the British Computer Society, an organization of IT professionals in the Kingston and Croydon branch. To support her point, Burnett used an example from a “long-running dispute between Co-operative Group and ICL, now part of Fujitsu, which has ended up in the Appeal Court, not least because no contract was finalized before the work began” (Kavanagh, 2004, p. 1). In addition, because the companies did not have a contract in place, they were unclear as to what was expected from each of the parties. Burnett points out that the cost of litigation far exceeds what it would have originally taken to put a contract in place. She also concludes that “the number of cases with good contracts that go to court is minimal” (Kavanagh, 2004, p. 3). The dispute example is from the Information Technology industry; however, the same principles apply to any significant procurement relationship.

Contracts As Standards Practice

In his book, Management of Project Procurement, Huston (1996) also supports Burnett’s approach to procurement. Huston says that the “objectives of the procurement process are to obtain the goods and services for a project in accordance with the technical, quality, schedule, cost, and other performance objectives of a project” (Huston, 1996, p. 3). As part of a six step process, Huston recommends clearly documenting the product or service requirements and creating a formal contract with the bidder that best meets the requirements. The contract development is completed before any of the work begins, just as Burnett advised in her speech. By following the six step process, both the customer and the vendor are able to work together to create a clear agreement.

Although Burnett’s focus was on the advantage of contracts for developing clarity between the parties, Cooper (2005) positions contracts as a key tool for allocating or transferring risk. Huston provides a list of pricing approaches also intended to manage risk; however, the pricing approach is less effective without a formal contract. Cooper advises allocating ownership of responsibilities within contracts to those that are in the best position to control the outcomes of those responsibilities. By allocating risk and establishing roles and responsibilities through a formal contract, all parties gain a level of clarity that they could not otherwise obtain.

Contract Examples

The company I work for uses contracts to manage its information technology procurements. As Burnet advised in her speech, my company includes contingency clauses in its contracts. A contingency is intended to outline the appropriate actions for addressing minor breaches in the contract instead of resorting to expensive litigation. For example, a contingency might include target completion dates for deliverables from its vendors. If the dates are missed, the contingency might include some form of financial penalty for the vendor. Through the development of a clear contract, my company is able to reduce the need for costly litigation.

In 1995, my company decided to outsource its internal help desk operations. They spent six months working with an outside vendor to develop a contract that clearly outlined the requirements for the work as well as a series of contingencies should any problems arise. About six months into the contract, my company was unhappy with the work of the vendor, even through the vendor was meeting the service levels. The contact was written to give either party the ability to terminate the agreement without cause within one year of the original contract signing. my company decided it was in its best interests to discontinue the relationship and executed the termination contingency without the need for further legal action.

Would a contact have reduced the likelihood of the Co-operative Group and ICL litigation as Burnett implies? Co-op had hired ICL to create a point-of-sale system that was to be deployed to Co-op’s locations. However, Co-op was unhappy with what they deemed sub-standard software and ICN was delivering weeks behind schedule. When the case was reviewed in court, the judge ruled that Co-op and ICL did not have a contact in place. As a result, the judge ruled in favor of ICL and ordered Co-op to pay compensation (Computer Weekly, 2003). If Co-op had taken the time to develop a clear contact with ICL both parties might have better understood expectations and could have worked out the differences. Regardless, without a contract, Co-op did not have the legal ground necessary to defend its position in court. Co-op ultimately lost its case against ICL.

Conclusion

Both of the examples from my company and Co-op support the position presented by Burnett during her 2004 speech for the British Computer Society, that organizations should use contracts to help control the risk in project procurements. Organizations should view contracts as an investment, not an expensive list of requirements. By investing the time to develop clear contracts, both the buyer and the seller can control risk and reduce the need to use litigation to resolve any disagreements.

References

Computer Weekly. (2003, February 26). Doubts Over IT Courts. Retrieved July 20, 2009, from ComputerWeekly.com: http://www.computerweekly.com/Articles/2003/02/26/192796/doubts-over-it-court-as-co-op-challenges-icl-ruling.htm

Cooper, D., Stephen, G., Raymond, G., & Walker, P. (2005). Project Risk Management Guidelines: Managing Risk in Large Projects and Complex Procurements. West Sussex: John Wiley & Sons Ltd.

Huston, C. L. (1996). Management of Project Procurement. The McGraw-Hill Companies, Inc.

Kavanagh, J. (2004, January 27). Use Your Contracts as Checklists for Managing Risk on IT Projects. Business Information UK , p. 3.

Managing Project Procurement

noreply@blogger.com (Thomas Kennedy) — Mon, 13 Jul 2009 17:50:00 +0000

The information technology (IT) department at my company follows a structured approach to managing infrastructure projects. Infrastructure projects include the installation of a network, telephone system, office equipment, file servers and audio/visual equipment. Most of the products and services needed to complete the projects are purchased from sources outside the company. To ensure consistency across projects, the IT department follows a standard procurement process for each project.

The procurement process includes “all of the activities that are required to obtain the goods and services required for a project” (Huston, 1996, p. 3). The primary objective of the procurement process is to “obtain the goods and services in accordance with the technical, quality, schedule, and cost objectives of the project” (Huston, 1996, p. 3). The procurement process can be broken into six basic steps:

Step 1—Define Goods and Services

At my company, the project manager is typically responsible for managing the procurement process. In the first step, the project manager must identify the products and services needed for the project and determine which to purchase from an outside source. Typically, my company will purchase any technology hardware and software used in infrastructure projects from external sources. However, installation and configuration services are sometimes provided by my company and other times provided by outside vendors. The decision for services depends on the type of work, the location of the installation, and the availability of internal resources. For example, we will usually perform our own network equipment installation and configuration. An internal resource will travel to any office around the world to perform the work. In contract, we rarely installs our own network cabling throughout the buildings—this work is typically outsourced to a local service provider.

In order to define the technology goods and services needed for a new office, the IT project manager will work with designers from the internal facilities department and external architects to review designs and floor plans for the new facility. Through the review process the project manager documents the technology requirements and creates a scope statement. The project manager reviews the scope and requirements with a project core team to specify the technology needed to meet the requirements and develops a preliminary installation schedule and a rough order of magnitude budget. The scope, schedule and budget are reviewed with the project sponsor and key stakeholders. If the schedule or budget does not align with the sponsor’s expectations, the process is repeated until the sponsor approves the preliminary plans. Once the preliminary plan is approved, the project core team will create documents that define in detail the products and services that they plan to procure. The documents will include a “complete description of the technical, quality, schedule, cost, and other performance requirements” (Huston, 1996, p. 5).

Step 2—Select Bidders and Complete Request for Proposal

Once the project manager has a clear and detailed description of the products and services, the next step is to identify the vendors that are qualified to provide what is needed. If the new office is in a location where we have worked previously, they will leverage existing relationships for procurement activities. However, for new offices in new locations, we must search for and identify qualified vendors. The project manager will often rely on the local construction contractor to recommend vendors. In addition, we will solicit recommendations from other project managers through tools like LinkedIn.

The project manager will also oversee the creation of the Request for Proposal (RFP). My company uses standard templates for its RFPs, adjusted for the specific project type. In addition, project teams leverage previously created RFPs as check points to ensure they cover the needed information. The RFP will include the scope, requirements, and detailed product specifications. In addition, the RFP will request a copy of any vendor contracts, an outline of the vendors change management process, licensing requirements, and any vendor testing and acceptance criteria. My company also includes its standard policy on gifts and a list of required meetings and standard reports. Finally, the project manager will prepare an evaluation matrix that the team will use to compare the vendor responses.

Step 3—Prepare Bid Proposals

Once the project manager completes the RFP, a copy is sent to each qualifying vendor. The vendors are given a window of time, usually a few days, to review the proposal. The project manager than coordinates a bidder’s conference to review the RFP in detail and answer any questions. For infrastructure projects, the bidder’s conference is held at the construction site in order to give the vendors firsthand exposure to the site. Although the bidders conference can be uncomfortable for the vendors, they are encourages to ask questions openly as any additional information generated through the process benefits all parties by providing additional clarity.

After the bidders conference, the vendors are left to create proposals in response to the RFP. If one of the vendors has additional questions, the question and answer is sent in writing to all the vendors. Again, the intent is to share information with all parties with the intent of providing clarity. The RFP includes instructions about the format, submittal process, and due dates for the RFP proposals. Any vendor that does not follow the instructions is excluded from further consideration.

Step 4—Evaluate Bids / Award Contract

Once the due date for proposal submission has passed, the project manager will close the submittal process and work with the project team to begin evaluating the bids. Prior to a detailed evaluation, the project manager and team must determine if anyone involved with evaluating the bids has received any gifts or special treatment in violation of corporate policy. If a violation is identified, both the company employee and the vendor are excluded from the evaluation process.

The project team uses the evaluation matrix developed during Step 2 to compare the proposals for each vendor. The team reviews each proposal and scores it against each area outlined in the evaluation matrix. The purpose of the evaluation matrix is to help facilitate a thoughtful comparison between the proposals; the evaluation matrix is not used to determine a winner, although the highest scoring vendors is typically awarded the contract.

Once the team completes the initial evaluation, they eliminate the vendors that are the least likely fit for the project. The project manager will continue negotiations with the remaining vendors, typically two but not more than three vendors. The project manager might ask the vendors to modify proposals based on new information learned; the process continues until both the vendor and my company have developed a win-win contract. Finally, the project manager will select the vendor and award the contract. Huston (1996) approach is to award the contract to the vendor with the highest evaluation. However, as mentioned previously, my company uses the evaluation matrix as a tool to foster discussion and to help with the decision process, not a tool to make the decision for them.

Step 5—Contract Management

Once the contract is signed, the project manager must manage the contract and the vendor relationship to a successful completion. Some organizations have separate contract managers. However, for infrastructure projects, my company typically depends on its project managers to manage the contract. This differs from ongoing operations-related contracts which are usually handled by the affected department’s manager.

To help facilitate collaboration and communication, the project manager will typically add a person from the vendors organization to the project core team. The vendor representative is included in all discussions and decisions that impact the contract, scope, schedule, and costs for the project. Including the vendor and continuing to develop open relationships and communication is a key to successful project execution.

However, even with the inclusion of vendor representation within the project core team, keeping information updated and coordinated across multiple vendors is problematic. If a change is needed in one area of the project, the change often affects the work of more than one vendor. My company provides its vendors with a centralized document storage system for vendors to use to coordinate information across the project. The use of this tool, in addition to regular discussions with the core team helps to reduce disconnects between the key areas of the project team.

Step 6—Close Out Contract

The final step in the process, whether because the work is complete, or because the team determines the work is no longer needed, the project manager must close out the contracts. In a normal situation where the vendor has completed the work, the project manager will facilitate an acceptance process. During the acceptance process the project manager will use the acceptance criteria developed during Step 2 to review the work and obtain acceptance from the internal customer, typically the project sponsor or a designated alternate. If the customer identifies any deficiencies, the vendor will resolve as needed before the contract is closed.

After contracts are closed, the project manager will ensure all final payments are made for services and products. The project manager will also update the budget to ensure all costs have been recorded accurately. Finally, all project related documentation, including procurement and contract information, is archived in a document storage system and made available to other project managers for future reference on similar projects.

Conclusion

My company follows a similar procurement process as outlined by Huston (1996). The six steps, defining, selecting, preparing, evaluating, managing and closing are all important to obtaining the “goods and services in accordance with the technical, quality, schedule, and cost objectives of the project” (Huston, 1996, p. 3).

References

Huston, C. L. (1996). Management of Project Procurement. The McGraw-Hill Companies, Inc.

Discussion Questions on Financial Measurements for Projects

noreply@blogger.com (Thomas Kennedy) — Sat, 15 Nov 2008 18:16:00 +0000

What is meant by capital planning?

Capital planning is the “decision-making process with respect to investments in fixed assets.” In other words, it is the process of finding and selecting profitable projects or proposals in which to invest company resources. Financial Management covers five approaches to calculating the potential return on a project or proposal: The payback period, net present value, profitability index, internal rate of return, and modified internal rate of return.

Why is IRR important to an organization?

IRR, or internal rate of return, is important to an organization because the calculation connects the project back to the primary goal of every organization—creating wealth for its shareholders. Organizations want to pursue projects that generate a rate of return higher than that required by its investors. The IRR calculation provides the internal rate of return needed to perform the comparison. “If the internal rate of return on a project is equal to the shareholders’ required rate of return, then the project should be accepted, because the firm is earning the rate that its shareholders require” (Keown, Martin, Petty, & Scott, 2005, p. 300).

Why is NPV important to a project?

NPV, or net present value, calculates future cash flows expected from a project, discounted to present value, and compared against the initial outlay required for the project. If the discounted cash flow projection is equal to or greater than the initial outlay, the project is profitable and should go forward. If the net present value is negative, the company should pursue other opportunities.

How would you select from multiple projects presented to your organization?

At my company, we also focus on wealth creation for our investors (as described above for IRR). However, we use EVA for project selection instead of MVA (market value added measures the total wealth created by a firm at a particular point in time). EVA is a way to determine the value created that is over and above the shareholders required return, but EVA allows us to compare that value over specific periods of time (like comparing one quarter to another). We evaluate all financial decisions using the EVA model. Not all of our decisions generate positive EVA. In some situations we choose between the options that generate the less negative EVA (I will explain this further if anyone is interested). Ultimately it is about generating wealth for the investor. “Managing the firm in ways that increase EVA will generally lead to a higher MVA” (p. 446).

Works Cited

Keown, A. J., Martin, J. D., Petty, J. W., & Scott, J. D. (2005). Financial Management: Principles and Applications. Upper Saddle River: Pearson Education, Inc.

Discussion Questions on Motivation

noreply@blogger.com (Thomas Kennedy) — Sat, 21 Jun 2008 16:44:00 +0000

Motivation is the “forces coming from within a person that account, in part, for the willful direction, intensity, and persistence of the person’s efforts toward achieving specific goals that are not due to ability or to environmental demands” (Hitt, Miller, & Colella, 2006).

What is the relationship between motivation and job performance?

Motivation is one of the factors that can influence the job performance of an individual. When motivation is equal between employees, job performance will increase or decrease as a result of other factors like individual abilities and environmental factors. Likewise, if factors like abilities and environment are similar for employees, performance can increase or decrease in relation to the motivation of the individual.

Give an example where you were motivated to do a good job.

About 10 years ago I was asked to take over the management of a relationship with an external IT support vendor. The contract had been in place for about a year and my company was very unhappy with the quality of support they were receiving from the vendor. I accepted the assignment and immediately dove into researching the causes of the dissatisfaction and developing recommendations.

Discuss what the specific motivation was and describe whether motivation was enough to accomplish the job you wanted to do.

In this project I was motivated in two areas. First, I was motivated by my desire to improve the quality of support for those within my organization (institutional power). Employees had suffered poor technical support for a number of years. The outsourcing was an attempt to fix the problem, but just made things worse. In addition, I was seeking an opportunity to fulfill my potential as a leader and to maximize the use of my unique skills and abilities (self-actualization).

Although I had significant motivation to resolve the service problems, motivation was not enough. I knew very little about the call center industry when I first took on the job and had to spend a significant time learning about best practices and analyzing the situation. Ultimately I felt we could build a higher quality support organization if we were to bring it back inhouse. My proposal was approved and within one year we were providing world-class technical support for my organization. The support was so good that formal organizations like the Help Desk Institute would bring members to tour our call center to learn about what we had implemented. It was a huge success. But as I mentioned, motivation was not enough. Without developing the skill and knowledge needed to succeed, we would not have achieved our objectives.

Sources

Hitt, M. A., Miller, C. C., & Colella, A. (2006). Organizational Behavior: A Strategic Approach. Hoboken, NJ: John Wiley & Sons, Inc.

Discussion Questions on Project Team Decision Making

noreply@blogger.com (Thomas Kennedy) — Sat, 21 Jun 2008 16:38:00 +0000

What are the advantages and disadvantages to group decision making?

As outline in Organization Behavior, A Strategic Approach, there are many advantages and disadvantages to group decision making.

Advantages:

Groups can generate more and better alternatives
Groups can display superior judgment when evaluating options
Group decisions typically generate higher acceptance
Group decision making can help individual members grow

Disadvantages:

Takes more time to reach decisions
Compromises may limit full evaluation of ideas
Groups can be dominated by one or two key people
Managers may rely too much on groups

Give an example of a decision made by a group that you were involved in.

About 5 years ago I lead a large team responsible for upgrading our network operating system to Active Directory. We experienced many of the advantages and disadvantages described above while attempting to make decisions. We had no shortage of ideas generated from the group (advantage). Most critical areas were discussed in detail, which lead to better overall decisions (advantage). But decisions typically took a long time (disadvantage) and key technical areas were typically dominated by a small number of the people on the team (disadvantage).

One of the most difficult decisions that the group had to make was to determine the administrative rights for each of the teams that would use the system going forward. The decision directly impacted the daily roles and responsibilities of a group of teams within the IT organization.

Describe the group dynamics involved in making the decision.

There were seven groups affected by the delegation of administration decision. Two of the groups, the Admin Team and the Infrastructure Team had equal administrative rights prior to the Active Directory deployment. However, based on security requirements, we were asked to reduce the total number of administors from 12 (the number at that time) to four. The Admin team felt that they should have all four on their team while the Infrastructure team felt they should be the ones with the admin rights. In addition, another team of IT resources in our UK office felt they needed admin rights since they were responsible for supporting our international locations.

As the project manager I allowed the project team to discuss the merits of each approach for some time. Each team was trying to convince the others that their approach was the right one, but they were unable to gain agreement across the larger project team. I realized that we would not come to a group agreement, so I made a recommendation to the project sponsors, obtained their support, and then delivered the decision to the team. I asked the security group to increase the number of admins from four to five, assigned two to the Admin Team, two to the Infrastructure Team, and one to the team in the UK. The project team found this to be an acceptable solution and we were able to move forward.

Sources

Hitt, M. A., Miller, C. C., & Colella, A. (2006). Organizational Behavior: A Strategic Approach. Hoboken, NJ: John Wiley; Sons, Inc.

Improving the Project Closure Process

noreply@blogger.com (Thomas Kennedy) — Sat, 06 Jan 2007 13:53:00 +0000

As the final individual assignment for a Project Management class at University of Phoenix, I have decided to write about the affects of crashing or eliminating tasks on project closure. Why did I choose this topic? The topic of project closure has not been adequately addressed during this class. In addition, the company I work for does not do a very good job of closing IT Infrastructure-related projects. Through researching articles and writing this paper, I have identified some key problems with project closure. I will elaborate on the affects of those problems at my company, then make recommendations for project managers to follow to overcome the problems.

Project Closure Failures

In the article “Not So Fast,” author Mary Brandel outlines observations regarding project closure. Brandel claims that the majority of companies do not perform proper project closure (2006). As a result, they do not achieve the return on investment that the project was originally set out to achieve. Brandel identifies three main reasons for project closure failures: 1) failing to plan project closure, 2) neglecting to complete all project closure tasks, and 3) ignoring actual return on investment.

Failing to plan project closure. Brandel claims that “companies do not do closures well because they do not plan for them” (Brandel, 2006, p. 37). Instead, project planning is focused on building or creating the deliverables of the project. This problem exists within the information technology department at my company as well. Many of the projects are managed by people within the IT operations group. They know how to install and upgrade systems, but they have not been formally trained on project management best practices. As a result, any planning that is done is focused on installing or upgrading the system. Little planning is done in relation to closing projects.

When my company built a new technical support center, they engaged development resources to modify the help desk software to align with internal process. The requirements for development were clear and the programmers executed flawlessly. However, the developers received an endless list of new enhancement requests for the system which delayed the production release by almost a year beyond the date that the original requirements were met. If the project manager had planned to close the project after the initial requirements were met, the system could have gone into production much sooner than it did.

Neglecting to complete all closing tasks. Even with companies that plan for project closure, some have a tendency to “neglect important steps at the project’s close that can make or break your ability to achieve a full return on investment” (Brandel, 2006, p. 37). The article gives an example from a project that was intended to reduce headcount; however, at the end of the project, they neglected to execute the layoffs. Like many companies, my company has more projects than resources to execute them. As a result, once the core deliverables for a project are created, resources are quickly shifted to work on other projects. At times, some tasks are left incomplete.

This happened with a project to replace a software distribution system at my company. After the new system was in place, the project team disbanded to work on other projects. However, they did not complete a key part of the project closure—shutting down the old system. As a result, the servers from the old system were maintained by the operations team for just over a year before someone realized that the maintenance activities were no longer required. If the closure tasks were completed as originally planned, the equipment could have been retired much sooner saving the company valuable time and resources.

Ignoring actual return on investment. Many companies that plan for closure and execute the closure tasks still fail to “evaluate whether ROI was actually achieved” (Brandel, 2006, p. 37). Once the project is approved, they focus all efforts on meeting the project schedule and budget. If the schedule and budget is met, the project is deemed successful. However, it is possible to meet the schedule and budget but fail to generate the return on investment that the project set out to achieve. This is probably the weakest area of information technology project management at my company.

With a recent upgrade to my company’s anti-virus and firewall client software, the upgrade cost was justified through an estimate that the new system would take 50% less time to manage. Successful implementation would result in valuable resources freed to work on other priorities. The project was implemented on time and within budget and was considered successful. However, no measures were performed after completion to determine if the time reduction was realized. In reality, administrators spend more time with the system today—not because the project failed to achieve its objective, but because the new system has additional capabilities that consume administrative resources. If the project were evaluated upon close, management may have seen the problem and taken steps to correct it.

Recommendations

Once one understands the cause of problems, creating solutions can be an easy task. In many cases, simply doing the opposite of the actions that caused the problem will eliminate them. In order to counter the problems discussed, project managers should follow three basic steps to improve project closure processes. First, plan for closures. Use a standard project template that includes the default steps needed to properly close projects. For each project, add to the template any additional items needed to address unique requirements of the specific project. Next, hold the project team accountable to completing the project tasks as identified in the project plan. Ultimately, the project manager must keep the team focused until the last task is completed. And finally, measure the deliverables. Include in the closing process steps to “verifying that the original assumptions were met” (Brandel, 2006, p. 37). By following these three simple recommendations, project managers will counter the problems identified and bring projects to a more successful completion.

References

Brandel, M. (2006, January 16). Not So Fast! Computerworld.