SO NOW YOU’RE A PROJECT MANAGER

SO NOW YOU’RE A PROJECT MANAGER

Abstract
Changing project roles from developer to project manager may be more involved than you think. It’s time to broaden your view from emphasis on the tasks to viewing the whole project. The 3-word project manager job description is “to manage risk.” A good project manager makes the process look simple. Risks are varied and sometimes hard to identify. They include such items as managing requirements, schedule, and cost. This article shares a few items to ponder as you start your travels down the project management road.

I know what a project manager does
Yesterday Tom was a developer, now he’s been asked to take the lead on the project – be the project manager. It sounded like a good opportunity, but Tom wondered what’s expected of me now? Tom’s transition can be similar to building a house. Tom installed drywall yesterday, focusing mostly on cutting and installing the drywall. Occasionally he would help in other areas like painting or wallpapering. Now Tom is the general contractor who is responsible for building the entire house.

Tom has been coding for years, so he thinks he knows what a project manager does. Yet, things might not always be as they appear. As a developer, Tom might not see how the activity fits into the big picture; Tom’s observations can be seen differently from a project manager’s (PM) point of view.

So what is Tom in for? What specifically is involved in doing this PM job? The most concise job description is “to manage risk.” Risk is a 4-letter work with a lot of power behind it. Webster’s dictionary defines risk as “(1) possibility of loss or injury: peril; (2) someone or something that creates or suggests a hazard.” Risk comes in many forms. Tom is used to managing coding risk – error handling and exception processing; you don’t want those “out of memory” and “run time” errors popping up in testing or production. As a PM, the view is broader and so are the skills employed – communication, negotiation, organizational, leadership, and more. As a developer, just leave Tom alone and he’ll code it. As a PM, Tom will coordinate more activities, relying on others to complete them on time, on budget, and with quality intact.

Managing this risk thing
A PM manages 3 main risks – requirements, schedule, and cost. You must meet the users’ needs – stated and unstated elements of the requirements. If you don’t meet the need, it’s not worth doing. The product could work perfectly and be some “sweet code,” but if it doesn’t meet what the customer wants then it’s shelf-ware. As you deliver the product, you need to meet the implementation target with an acceptable level of quality and within the budget. The users don’t want those “out of memory” and “run time” errors popping up either. Think about Tom building a house. He might insist on certain things when the contractor is building his house. It must meet his living needs and quality expectations – floors must be level, no foundation leaks, walls must be properly painted, etc (requirements). Tom wants the contractor to work against his target date so he can move from his current residence to this new one (schedule). And the house must fit within his pocketbook (cost).

Managing requirement risk
Let’s start with requirement risk. When you drive, you usually have a clear destination in mind. Requirement risks are the detours and road construction that may slow down the journey. There are a few tools in the PM’s tool belt that can help.

• Make sure you understand the requirements. Do a process walk-though during requirements gathering (use cases, business scenarios). This could uncover unexpected requirements or different interpretations. Your definition of gray could be different than the customer’s (shades of gray).
• Document the requirements in a formal document or tool.
• Review requirements with sponsors and receive “signoff.” Any future requirements (new, new interpretations) should follow a project change control process to explain the cost and schedule impact. New interpretations can be a little trickier when it comes to budgeting and schedule considerations – Who pays any additional cost and is schedule impact allowable? While change requests may add a little more work and analysis, they will improve the final product being delivered. Project Management consultant Bill Duncan (2003) calls change requests a cause for celebration. The author explains that change requests mean that the customer is engaged and noticed something missing.

You hope that the requirements will easily describe what the user desires and needs. However, sometimes the requirements open themselves to a different interpretations of the end product, leading to missed quality expectations. When this happens, grab your PM tool belt.

• Users must be included on the project team and in team meetings. They can identify mistakes earlier in the process, instead of post-implementation. In her article “Ten Ways to Guarantee Project Failure” (2003), Naomi Karten explains that minimizing customer/user involvement is one way to guarantee project failure. She emphasizes that users help clarity project direction, scope, and expectations.
• Hold demo-and-discussion sessions to evolve concepts into reality. Talking about something is great, but seeing it brings a new reality and tests the model more visually.

Managing schedule risk
Schedule risk focuses on meeting the implementation date. The main tool involves using milestones to check progress. You can uncover a few more tools in the PM’s tool belt to help.

• Break larger tasks into smaller milestones (max 1-2 weeks) to understand progress/checkpoints/lag times. In his article “A Calculated Gamble” (2003), Payson Hall stresses the importance for risk management. He agrees that decomposing complex tasks into smaller tasks helps detect progress slippage better.
• Understand the critical path – the tasks that will delay the schedule if they miss their target end dates.
• Use newer technology, tools, and techniques earlier. Since they are new, there could be a few detours along the road. In the articles “Risky Beginnings” (2000) and “A Calculated Gamble” (2003), the authors agree that new technology can be a risk. The authors suggest including exploration time in the schedule and shifting tasks that use new techniques or tools to occur earlier in the project for earlier detection of problems and refinement of processes.
• Plan some catch-up time in the schedule, also called lag points. Normally, some tasks will take longer than others so this lag time can absorb unexpected downtimes and act as a shock absorber. When building a house, the contractor needs some shock absorbers for things like weather delays.
  

Managing cost risk
Anticipating and controlling requirements and schedule risks well can help manage the cost risk. Cost is the byproduct of all activity. There is even a cost associated with adding resources to meet unanticipated or off-schedule problems. It’s a good thing that the PM tool belt is not empty.

• With the sponsors, agree on a variance threshold that allows some overruns without having to run to the sponsors for approval each time
• Understand cost run (how much cost is forecasted each week vs actuals)
• Share cost overrun projections with the sponsors early in the project to help set expectations about the final cost

Delivering results
There’s a saying, “it’s not what you said, but how you said it.” This article has suggested some methods to manage risks, but the delivery is also important. Skills such as active listening, use of power, and conflict management are needed in order to deliver results. These are skills that are useful for developers, project managers, and others alike.

The author of the article “What it takes to be a good project manager” (1987) shares a study noting that communication skills were the most important project management skill. In one study, 84% of project managers surveyed believed that communication skills such as listening and persuading were at the forefront of project manager needed skills. The core of active listening focuses on listening and ensuring understanding. Once we have “really listened,” then we can look towards responding. Active listening can be helpful in mitigating requirement risk. Users typically explain the result they desire. Active listening allows us to ensure that we understand the requirement, reducing the shades of gray.

You want your response to achieve a desired result. As a project manager, your power to achieve that result can be somewhat limited. While Tom has a team of analysts, developers, and testers for his project, none of them report directly to him; there is a matrix reporting relationship. This reduces the power at his disposal. However, Tom still has influence over this team, sponsors, and others. Influence can be viewed as producing a desired effect without force or exercise of command (or power). In his article “Power, Dependence, and Effective Management” (1977), John Kotter explains several methods of influence including obligation, perceived power, perceived dependence, persuasion, and others. The proper method of influence should be tailored to the specific persons involved and situation. There are advantages and disadvantages with each method. For instance, persuasion can influence a very wide range of attitudes and behaviors requiring no power. Yet, it can be very time-consuming and requires the other person(s) to listen.

Within a project, there will be opportunities to exercise active listening and influence, especially during conflicts. Over time, one learns that conflict is healthy. It suggests that people are engaged and asking the “why” questions. In the white paper, “Communication Breakdown and Conflict within Teams” (2004), another author explains that conflict is essential for healthy teams to challenge old ways and sponsor creativity. The project manager needs to understand how to encourage the good conflict and minimize the bad. The article “Lessons for an Accidental Profession” (1995) explains that conflict should not be covered up because it festers if not addressed. The later eruption will have stronger effect than if confronted originally. There are several effective conflict management methods. In the article “Methods of Resolving Interpersonal Conflict” (1969), Burke shared a study showing that confrontation-problem solving was the most effective. Confrontation-problem solving focuses on using active listening to work through the differences towards a win-win solution. It defines the problem relative to the total needs while confronting differences and being open and fair. The book Getting To Yes (1991) reinforces this idea while acknowledging that sometimes a win-win is not possible. The BANTA approach (Best Alternative To a Negotiated Agreement) provides a structure to understand the perspectives and alternatives. The process exhausts the alternatives to the “best” alternative for each party. If a BANTA is not agreeable, then the process has healthily discovered that a win-win agreement is not possible.

Give it to me straight
Project Management is more than another development task that will take a few hours for a limited period of time. A PM’s time is spent each week for the duration of the project. It requires an extended skill set than that of the developer. You may be like Tom who still enjoys coding. While managing a project, you should not be a critical path developer too. If you will hold PM and developer roles in a project, you will need to balance your development and PM duties. A nice rule of thumb is 30% for development and the other 70% for project management. Last, take time weekly to write down what could go wrong – risk brainstorming and mitigation planning. It’s easier to miss potholes if you can see them coming.

I hope you have a better understanding of the road ahead. Good Luck.

If you are interested in more information on these topics, these references might be useful.

Burke, R.J. “Methods of Resolving Interpersonal Conflict.” Personnel Administration. Jul-Aug 1969.

“Communication Breakdown and Conflict within Teams.” Global Knowledge. July 2004. http://itresearch.forbes.com/detail/RES/1088099513_537.html.

Derby, Ester. “Risky Beginnings.” STQE Magazine (now called Better Software). http://www.stickyminds.com/BetterSoftware/magazine.asp. November/December 2000. Ms. Derby has a website supporting her project management consulting company and her many articles at http://www.estherderby.com/articles.htm.

Duncan, Bill. “Ignorance Is Risk.” Projects@Work. July/August 2003. At the time, Mr. Duncan was director of standards for the American Society for the Advancement of Project Management and a principal of consulting firm Project Management Partners (www.pmpartners.com).

Ensworth, Patricia. The Accidental Project Manager: Surviving the Transition from Techie to Manager. Wiley. 2001. This book can be found on many websites, including Amazon at
http://www.amazon.com/exec/obidos/ASIN/047141011X/qid=1112473736/sr=2-1/ref=pd_bbs_b_2_1/102-9708073-3841706.

Fisher, Fry, Patton. Getting To Yes. Penguin. 1991.

Hall, Payson. “A Calculated Gamble.” www.stickyminds.com. January/February 2003.

Karten, Naomi. “Ten Ways to Guarantee Project Failure.” www.stickyminds.com. April 2003. More of Ms. Karten articles can be found at http://nkarten.com/indepth.html.

Kotter, John P. “Power, Dependence, and Effective Management.” Harvard Business School Press. July 1977.

Pozner, BZ. “What it takes to be a good project manager.” Project Management Journal. March 1987.