Search This Blog

08 March 2013

Forcing versus Withdrawal for Conflict Resolution

Is it true that the Forcing conflict resolution technique is worse than Withdrawal?

Withdrawal can have negative or positive consequences. On the negative side, left to themselves, people may escalate the conflict to the point that the PM loses control. While time passes, risks may evolve into issues, or issues into problems.

On the other hand, people may calm down and consider each others' needs and opinions. In time, they may voluntarily find ways to meet all needs, or at least reach a compromise. They might also find a new solution. So the problem may solve itself. It's important for the PM to respect the team's ability to solve problems and allow them "space" to do so.

Forcing always has losers and creates the risk of driving a less-than-optimal solution. People don't disagree about issues unless somebody sees an aspect that the others do not see. Odds are, if you force a solution, you've missed an opportunity to find a better solution.

Forcing also implies showing disrespect for the "losers," so it demotivates them. Their decrease in performace can becomes a drag to the team. The negative feelings and the drag, in turn, affects the whole team's performance.

You may not have time to find better solutions. Although forcing ranks as the worst technique, circumstances may force you to use it. If you force a solution, you need to follow up with the "losers" to identify the negative consequences. This shows respect for their needs and their perceptions. It also allows you to find ways to mitigate any shortcomings in the forced solution.

06 March 2013

The Lobbyist on the Project Management Team

You are the project manager in an aircraft manufacturing company developing a new range of supersonic fighter planes. Since government approval and involvement are essential, you hire a lobbying firm to get government support to prevent unnecessary changes in your project. Which process is this an example of? (Source unknown)
While aircraft manufacturers conduct some research into designs and materials that they can incorporate into new aircraft, governments usually sponsor development of fighter jets.
 
Scope creep happens in almost all defense projects.
 
For example: 
  • The Defense Department wants the aircraft to provide certain capabilities for the Air Force.
  • Then the Navy wants compromises in the design so the jets can take off from carriers.
  • The Army and Marines add their particular use cases.
  • Allies want introperability with their systems.
  • Later, one politician wants to cut costs,
  • another wants the aircraft to use inadequate landing gear designed by the manufacturer in his home town,
  • and over 600 politicians and thousands of bureacrats want to influence the project.
  • Meanwhile, competitors and the nation's adversaries develop new technologies to which the designers must respond.
  • And one of the political parties, along with the press, begin mocking your aircraft by calling it an Imperial Tie Fighter.
If you let it, the politics will multiply the cost twentyfold, drag out the schedule an extra 15 years, and make your company a laughingstock. By the time of the first production run, the aircraft will already be obsolete.
 
The same sort of changes can happen in any project. One way to control the risk of scope change is to refuse to make changes, but too little flexibility can create customer dissatifaction and cost you future business.
 
For a better way to reduce the risk of scope creep, maintain close personal relationships with the stakeholders, keep them informed of the costs of changes, and negotiate agreements that best serve the business case.
 
The PM cannot always do this, so the company hires a lobbyist with exceptional people skills and knowledge of the bureacratic systems. The lobbyist uses various methods to convince the politicians and bureaucrats to resist tinkering with the project requirements.
 
In process terms, hiring a lobbyist does not proceed from the Project Communications Management processes. Lobbying does not contribute directly to producing the product or providing a service. A first pass through the Identify Stakeholders and Plan Communications processes would assume everything goes as planned and would focus on required reporting and coordination. The lobbyist's job goes far beyond that.
 
If the team identifies scope creep as a risk, they make a note to consider it later when they follow the Identify Risks process. They would, at that time, add recruiting a lobbyist to the Risk Management Plan portion of the integrated Project Management Plan.
 
Don't forget that, as a member of the project team, the lobbyist becomes a stakeholder. For example, the team must add the lobbyist's tasks to the WBS and estimated costs during the next iteration of project planning. They must also consider the lobbyist's information needs during the next iteration of the Project Communications Management processes.

24 February 2013

Project Selection

For project selection, the Project Management Institute's (PMI's) Project Management Body of Knowledge (PMBOK) Guide assumes you have more than one project from which to choose. By analyzing the options, you can determine which has the greatest value to the company. The formal method for choosing the best option is called a project selection method.
 
Suppose I have to choose between
  • fixing my child's favorite meal and leftovers for my wife, or
  • fixing my spouse's favorite and cheese mac for my child.
So I ask, "which gives me the better Return on Investment (ROI)?" To answer the question, I consider
  • How much time and money it will take
  • How much of a mess I will have to clean up
  • Does it align with my goals (fun vs. study time)
  • Rewards (somebody else WILLINGLY taking out the trash)
  • How long it will take to reap the rewards
  • Risks (what if I overcook the macaroni? or burn the steak?)
A Project Manager (PM) will place a priority on each criterion and score the probable outcomes. The sum of the weighted scores for each option yields a total score for that option.
I did this with my daughter last year when she needed to buy a car. The result surprised me and was not at all what I expected, but it turned out to be a great choice.

The primary use of project selection is for choosing between projects. However, one can also used it during the project life cycle. The projected ROI of a project can change, for example, due to changing market or regulatory conditions. If the ROI falls, it might be worth canceling the project so the funds and resources can be applied to a more promising project. This is a special case of selecting between competing opportunities.
 
The executives of a company I won't name signed a contract to deliver a product on a certain date. If the company failed to deliver on that date, the company would have to pay liquidated damages; and if the company canceled the project, it would have to pay penalties.
 
Unfortunately, the executives failed to have Engineering review the contract. It turned out that the company could not meet the deadline. The PM tried schedule compression, but as risks turned into issues, it became clear that the project could not meet its deadline.
 
What should they have done? The company should have used the project selection method to choose between
  • Completing the project and paying the liquidated damages
  • Canceling the project and paying the penalties.
Remember, the considerations aren't always directly related to the project. Things such as the company's reputation, the future value of establishing a market presence, or future business based on this project's design work have value, too. For example, cell phone companies often sell cell phones at a loss because they make their money on the service contracts.

Copyright 2011, Richard Wheeler

09 February 2013

Project Management Career Path

In terms of study, what path should one take to become a project manager?

First, unless you have several years of project management work experience, I would suggest obtaining the Project Management Institute's (PMI's) Certified Associate Project Manager (CAPM) certification. After that, study the qualifications for the Project Management Professional (PMP) certification and create a plan based on those qualifications. The plan should include studying PMI's Project Management Body of Knowledge (PMBOK) Guide and added studies based on the PMBOK Guide's process knowledge areas.

Second, familiarize yourself with the International Counsel on Systems Engineering (INCOSE) Systems Engineering Body of Knowledge (SEBOK). After achieving PMP certification, pursue INCOSE's certifications. PMI certification will give you a top-down perspective across all departments whereas INCOSE's certifications will give you a bottom-up understanding of the engineering processes and products.

Studying these two knowledge areas in this order should provide a faster path, on paper, to project management and beyond. However, if you would prefer a career path leading to a Chief Engineer title, you might reverse the order. Pursing Engineering in Training (EIT) and then Professional Engineer (PE) certifications would be valuable on the technical career path, too.

Third, study people, develop lots of relationships (focus on the personal aspects and what you can do for them, not on what you can get out of them), and find at least one mentor other than your supervisor. These are critical.

08 February 2013

Politics and the Project

Question:

Cultural norms include a common knowledge regarding how to approach getting things done. It also takes into account formal and informal leaders who exist in almost every organization. Most organizations have developed unique cultures that manifest themselves in many ways. Which attributes of a company culture is NOT consistent with the discussion of cultural "norms"?

A. shared vision, values, beliefs, expectations
B. policies, methods and procedures
C. consistent political views
D. view of authority relationships

I was given answer as "C".
Shared vision, values, beliefs, expectations; political views; and views of authority relationships are all cultural factors. Each is a valid topic of discussion to the degree that it affects the project and the organization.

Political views include both those related to national government and those related to the company goals, culture, and hierarchy.

Western employees are taught that religious and political views are inappropriate topics. However, Political Correctness (PC) is alive and well. For example, some countries suppress "subversive" or "counter revolutionary" political views. This can affect project success.

Even in the USA, many employers will fire you if you oppose certain movements such as homosexual marriage or affirmative action (discrimination in favor of disadvantaged minorities). The reasoning goes like this:
  • Diversity has value.
  • People who oppose a PC (politically correct) view create a workplace that is hostile to favored minorities and an atmosphere where conflict may arise.
  • This hurts members of those minorities, limits diversity, subjects the company to legal liability, and disrupts teamwork.
  • Thus, inconsistent political views concerning some topics can hurt the project.
You don't have to like PC, but it exists. PMs have to deal with it and sometimes even enforce it.

Consider a different meaning of "political views:" Every organizational hierarchy has "office politics." Competition, conflicting opinions, and popularity can affect whom you can rely on. A stakeholder or resource may oppose you, or others may not support your resource. Such factors affect how one succeeds in getting things done.

We may say (C) is an inappropriate topic, but political views are certainly a part of cultural norms, and some version of PC is enforced anywhere you go. Moreover, the question is not, "what is appropriate," but "which attributes of a company culture is [sic] not consistent with the discussion of cultural 'norms'?"  (C) cannot be correct.

While culture may affect policies, methods, and procedures, they are classified not as part of the enterprise environment (that is, external factors that affect the project), but rather as organizational process assets. (B) is correct.

Copyright (C) 2013, Richard Wheeler. Permission granted for use not involving publication.

16 January 2013

Buyers versus Users

The new project manager (PM) or systems engineer (SEs) knows that the Seller, the person or organization providing deliverable products or services, must fulfill the scope defined by the Buyer. The Seller and Buyer usually negotiate a Project Scope Description which the project Sponsor includes in the Project Charter. Details of the project scope description may be found in the contract, Statement of Work, and any subsequent approved Change Requests.
 
The PM also knows that the Project Requirements must detail the project scope through requirements analysis and through creation of a Work Breakdown Structure (WBS) that has enough granularity to define project tasks at a manageable level.
 
New PMs or SEs may overlook the importance of a third party: Users.
 
Users are people or organization who put their hands on the product or receive the service. The Buyer may or may not be the User. For example, as part of a project to set up a business office, a manager (the Buyer) may want to buy spreadsheet software for his analysts (Users).
 
In one contract, my company upgraded communications equipment for an agency (the Buyer) that needed new types of signal channels. The Buyer owned the equipment, but another contractor provided the operators, and yet other agencies utilized the communication channels.
 
Even though we took our direction from our contract with the Buyer, we coordinated with the third-party Users to validate the Buyer's requirements. Unhappy Users would have been reflected by an unsatisfied Buyer, which would have cost us future business.
 
The PM must gain acceptance from the Buyer by satisfying the requirements. However, in many projects, the PM must also define the requirements in enough detail to ensure that they reflect the Buyer's needs. This implies added responsibilities:
  • The differences between needs and requirements must be identified as early as possible in order to prevent expensive changes later.
  • If meeting the needs increases the scope, schedule, or cost, the PM must inform the Buyer and negotiate changes as soon as possible.
  • The PM needs the courage to help the Buyer understand what he needs and what he will not receive.
  • Enough time should be spent during the planning phase of a project to ensure that meeting the scope, requirements, and needs will result in a happy Buyer.

Returning to the example in the first paragraph: The manager may think he can get by with Lotus 1-2-3 (ca. 2000), but the analysts are familiar with Excel 2007 and need the new functions that come with Excel 2013. The PM needs to advise the Buyer to take a class in computer literacy.

Copyright (C) 2013, Richard Wheeler. Permission granted for use not involving publication.


Project Cancellation

While you are directing and managing your project execution, your sponsor tells you that your project has just been terminated. Will you complete Verify Scope process before closing your project?

Yes, verify scope provides an opportunity for the PM and the sponsor to document the project status at that moment... that can be used for lessons learnt as well for future projects. (Name withheld)

No.

Process 5.4, Verify Scope is the process of formalizing acceptance of the completed project deliverables and includes reviewing deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance of deliverables.... (PMBOK) Since the project has been canceled, no more deliverables will be accepted. Completing the Verify Scope process would waste resources.
 
Exceptions not indicated by the question
  • The terms of a cancellation could include acceptance of whatever has been completed.
  • The company could preserve the deliverables in their current state for use in future projects, in which case, knowing their quality would have value.
Note 1: If one traces the flow of outputs from the Verify Scope process, the next step for any Accepted Deliverable is process 4.6, Close Project or Phase.
 
Note 2: Documenting the project status at the time of cancellation would start with Work Performance Measurements produced by following process 5.5, Control Scope, the process of monitoring the status of the project and product scope and managing changes to the scope baseline. (PMBOK).
 
The PM would then follow process 10.5, Report Performance, to analyze the project's progress, producing Performance Reports. For the final step, following process 4.4, Monitor and Control Project Work, the PM updates Project Documents, including performance reports and issue logs. (The PM would also make other updates to Project Documents during that preceding processes.)
 
Note 3: Non-accepted deliverables would be subject to the Direct and Manage Project Execution or Perform Quality Control processes (and their design and production partner processes). The Direct and Manage Project Execution and the Close Project of Phase processes might invoke some sort of Disposal process to handle the non-accepted deliverables.

Copyright (C) 2013, Richard Wheeler. Permission granted for use not involving publication.