Voices on Project Management

by , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

About this Blog

RSS

Recent Posts

Fair's Fair

Give Your Project a Home

A Hollywood-Style Move From PM to Scrum Master

To Have and To Hold

Leading With Integrity

Manage Risk Like a Formula One Driver

Categories: Risk Management

"Twenty-five drivers start every season in Formula 1, and each year two of us die. What kind of person does a job like this? Not normal men, for sure. Rebels, lunatics, dreamers. People who are desperate to make a mark and are prepared to die trying." --Daniel Brühl as Niki Lauda (Rush, 2013)

I attended my first Grand Prix in 2000 at the Indianapolis Motor Speedway, and quickly became a Formula One (F1) enthusiast. I have attended several Grand Prix races in Asia, North America and South America; visited iconic F1 destinations such as Autodromo Nazionale di Monza and the Ferrari factory in Italy; and even met a few World Drivers' Champions. 

Voices_Conrado_F1_3.jpeg

Over the years, I have noticed that F1 and project management are very similar. Every race of the season is a milestone. Engineers, designers and mechanics work for the driver, who is always looking to minimize risk and maximize opportunities -- just like the project team and a project manager.

Mr. Lauda, with 25 wins, one of the greatest F1 drivers, is well-known by racing fans for two things: his rivalry with James Hunt and his accident on 1 August 1976, during the German Grand Prix Nürburgring.

During the 1970s, Nürburgring was the season's most dangerous circuit. It was known as "the Graveyard" and had claimed the lives of five drivers. In the 1976 race, the weather conditions were far from ideal. Mr. Lauda called a meeting with the rest of the drivers to vote to cancel the race. The drivers understood that the Nürburgring ring required perfect weather conditions to be even remotely acceptable in terms of risk. Due to Mr. Lauda's position in the F1 standings, canceling the race would've benefited him, but he was more concerned about the danger.

The race went on despite the rain. During the race, Mr. Lauda's car went off the track and his fuel tank punctured, setting his car on fire. He was trapped for almost a minute in a searing inferno before other drivers could rescue him. Mr. Lauda suffered burns to his face and smoke inhalation. 

As with race car drivers, project managers face risk with different levels of severity. A project manager's risk tolerance level depends on different factors: organizational culture, national culture and experience. It's not only imperative that we provide early identification and assessment of risks -- the point is to know and stick to a risk threshold. We may face hardship for accepting the risk and not being successful, but we need to learn the lesson and move on. As Mr. Lauda said: "I accept every time I get in my car that there is a 20 percent chance I could die, and I can live with [that risk] -- but not 1 percent more." 

Another lesson in risk management from Mr. Lauda comes not long after his crash. Like a phoenix, 42 days after his near-fatal accident, he went back to the track and kept fighting Mr. Hunt for the championship. The Japan Grand Prix, the last race of the season, would crown the next World Drivers' Champion. Again, weather conditions were poor, delaying the race for several hours. While it was still raining, Mr. Lauda started the race but quit after a few laps. His team was surprised to see him coming back to the pit stop and asked him what was wrong with the car. Whie the car was in perfect condition, Mr. Lauda assessed the risk as too high. And when the team tried to present a technical justification for his quitting, Mr. Lauda told them to tell the truth: that he made the decision based on the weather. He had reached his risk threshold and decided to leave his championship hopes to other drivers -- including Mr. Hunt, who garnered enough points to beat Mr. Lauda and take the top prize.

We project managers are paid to decide the future of projects, programs and portfolios. Sometimes, those decisions are difficult to accept -- by sponsors and stakeholders, not to mention ourselves -- but will provide long-term benefits to our organization. And canceling or postponing a project, program or portfolio will not prevent our professional career from progressing -- on the contrary, it can reinforce our knowledge and experience. After the Japan Grand Prix, Mr. Lauda continued his successful racing career and became champion in 1977 and 1984.

I have my own experience of approaching risk management by determining the environment and sticking to thresholds. When working on a regional project in Central and South America in 2010, the project faced a geopolitical risk that slowed down progress. But in many countries in the region, 2010 was a presidential election year. This event usually contracted economic activities months before the election and sometimes even after. As elections impacted different countries at different levels, we had to define and implement contingency plans for some; for others, we accepted the risk, and yet for others, we didn't accepted the risk and suspended the project temporarily.

How do you face risk? Are you a risk taker or a risk-averse project manager? And how do you define acceptable risk?
Posted by Conrado Morlan on: June 27, 2014 05:31 PM | Permalink | Comments (3)

5 Things I Learned from My First Project Manager

Categories: Risk Management

In the early days of my career as system analyst, I had my first assignment working directly for a project manager. 

My project manager -- let's call her Rita -- was assigned to turn around a failing software package project. Over the next several months, under Rita's direction, the project was implemented with great success. 
   
When we parted ways at the completion of the project, I asked Rita for her keys to project management success. While tools and processes have changed over the years, what she said has served me well managing all types of projects. 

Following her advice has led to successful delivery outcomes and helped me mitigate risks along the way:
1. Schedule project meetings on Mondays   
Rita maintained that Mondays are better than Fridays to catch up on project progress. Her rationale was that you could better forecast and make the work for the current week visible. It also had the extra benefit of re-charging our minds for project work after a weekend.
 
2. Enable progress  
Instead of providing input on how the system would function, Rita spent time orchestrating the actual work of the project to enable progress. For example, during the project's design phase, she provided useful requirements and design templates that allowed us to better organize and align our efforts.

In addition, rather than assigning risks and issues to others on the team, Rita took personal ownership of solving them. This allowed team members more capacity for work while Rita worked in parallel to mitigate issues.  

3. Functional design is everything  
Rita always stressed that it was essential a project have sufficient time to complete a full functional design process with no shortcuts. She mandated that a full functional design process would also include the tracking of the design back to the requirements. On the project I worked on with Rita, this additional focus ensured that the software package was configured properly to meet all requirements. 

Rita also directed us to exhaustively pursue the design of interfaces. One of her constant comments was, "The value of what we implement is tied to the success of how it interfaces with everything else."  

4. Use prototypes where possible 
Rita often said, "It's easier to see a system than to talk about it." Presenting system functionality by drawing pictures on a marker board is not an effective method of conveying how a system will work. Rita acquired access to a prototype software installation. This prototype not only allowed the project team to readily show what the software would do, it also enabled quicker design of the software configuration. 

5. Manage delivery first, then costs 
Presenting a complex analysis of project budget during steering committee meetings is okay sometimes, but you must be able to answer fundamental questions around project progress. 

During her steering committee meetings, Rita would present escalated risk, issues and mitigation strategies for review and approval. This shifted discussion to delivery-related topics, which accelerated the progress of the project. "If you deliver successfully, the costs take care of themselves," she said. 

What are some project management principles you learned from your first project manager? 
Posted by Kevin Korterud on: December 06, 2012 12:52 PM | Permalink | Comments (2)

5 Ways Agile Helps Mitigate Project Quality Risks

Categories: Agile, Risk Management

The agile process helps reduce such risks as poor product quality or building the wrong product entirely. Though agile and Scrum were originally designed for software projects, their iterative process and techniques apply beyond their initial intended industry.

Here are five ways agile and Scrum techniques can curtail project quality risks:

1. All practitioners must review project requirements with the client.
In agile, the "user story" is the basic building block for agile requirement lists. A formal "acceptance test" is an integral part of that user story, as is explicitly reviewing it with the client to verify you have customer concurrence on the deliverable.

2. Agile teams collaborate while creating project components.
Inspections or pairing can prevent up to 50 percent of possible defects, according to research I conducted with colleagues. In addition, collaborating helps team members share other knowledge about the product or tools used to meet project needs at a critical stage.

3. Authors create a consistent set of verification measures.
Ideally, this takes the form of automated verification tests designed to catch missing functions or incorrect product behavior. These tests are run by the original author, as a sort of control against variables, and also used for regression testing by other team members. Yet even if a project passes these tests, it's also crucial that the product components are streamlined from the get-go so they can be easily maintained or extended in the future. This is called "refactoring."

4. Quality teams test small project deliverables as they are written.
Since the deliverables have been inspected or pre-tested, at this point you should expect few errors.

5. Feedback from a demonstration.  
Agile teams hold demonstrations for their stakeholders, showing items completed since the last demonstration. The key is to elicit feedback from stakeholders and use it to improve the product. This provides one final chance to confirm that what the team produced was what the customer wanted. In this way, ideas and changes can be addressed before the completion of the project.
 
In addition to the following checklist for agile and Scrum risk reduction, it never hurts for teams to employ risk lists to further improve project performance:

  1. Client review of each acceptance test
  2. Team collaboration in inspection or pairing
  3. Test automation by the author and refactoring cleanup
  4. Independent testing by the quality team
  5. Demo to the client

How else do you think agile helps mitigate risk? What steps do your teams take to mitigate risk?

Read the Organizational Agility report for an in-depth look at how agile organizations increase their success rate on new projects, even in a volatile global economy.

Posted by William Krebs on: October 10, 2012 11:16 AM | Permalink | Comments (1)

5 Things You Never Want To Hear On A Project

Starting out as project managers, we begin to recognize the signals that point to project risks. Initially, these signals come in the form of status reports, work plans and delivery metrics. As we gain experience, we learn to sense additional risk signals that come from observation and dialog. And those signals originate from project managers themselves.

These signals sometimes go unheeded because the ability to act on them can typically be constrained. For example, there is fear of making project customers unhappy if you raise objections, unrealistic expectations and a false belief that these types of messages will somehow motivate the project team.  

In my experience, here are some of the signals that have pointed to a project headed down the wrong path:     

1. "We'll start the project at the kickoff meeting."   
Many times, important project mobilization activities tend to be ignored in the haste to begin a project with a large group meeting. This fixation on the kickoff meeting causes key mobilization tasks to fall behind. Early action on staffing plans, on-boarding processes and communication mechanisms before the kickoff meeting are more important than making sure the chocolate chip cookies arrive in time.  
 
2. "This project WILL finish on time and budget." 
This signal typically appears at the first sign of progress or cost slippage. As opposed to dealing with the root cause of the slippage, many times project managers will shrink scope to meet time and budget. Reducing scope has the effect of reducing the overall value proposition for the project. Address this tendency by allocating sufficient time early in the project to identify business success criteria independent of schedule and costs.

3. "The CEO is the sponsor for this project or program." 
Name-dropping typically emerges when there is a conflict over resources needed by multiple projects. Project managers hope that by presenting the CEO or other executive as a sponsor, it will create commitment to the project. However, CEO's and other executives usually do not have the luxury of time to serve as a sponsor on a project. Leverage stakeholder management activities such as a level of funding approval list to confirm the primary sponsors for the project.

4. "We are four weeks behind schedule, but we'll make it up in the next phase."   
Unless there is a large change of scope, one of the more the unfortunate laws of physics for projects is that any schedule slippage is likely to carry over to the next phase. The best approach is to be transparent about the schedule delay. By making the slippage transparent, you enable leadership team attention and corrective actions.

5. "I feel green." 
A green status indicator in a project report typically means that no issues are present. However, a green status indicator does not always tell the complete story.

For example, despite deliverable dates that were slipping on one project, the project manager continued to declare a green status indicator. In an executive steering committee meeting, the leadership team challenged the project report. The project manager said,  "I know the deliverable dates are slipping but I'm still feeling green." To promote project team and leadership confidence, employ objective project metrics such as planned vs. actual deliverable dates or earned value analysis to show the true status of the project.

While tools, approaches and processes help manage delivery risk, recognize these signals and take the right steps to act on them.

What have you found to be good examples of signals that point to risks on projects? 
Posted by Kevin Korterud on: September 25, 2012 01:15 PM | Permalink | Comments (5)

Stick to Project Management Basics

The importance of fundamentals in project management is obvious, but easy to lose sight of.

As professionals who constantly strive to improve, we study, read, take courses, attend seminars, listen to podcasts and more -- all to become better project managers. Ironically, sometimes this desire to learn causes us to lose focus on the fundamentals.

Instead, we look to novelty, the latest trends and perhaps even the latest fads in the interest of improving.

Likewise, we might embrace sophisticated techniques without ensuring that we've properly implemented the basic things on which the sophisticated techniques depend.

I've often heard great sports figures and musicians emphasize the importance of fundamentals in their success. Project managers would do well to place similar emphasis on the basics of our profession. I'd go even further to suggest that before we embrace any new or sophisticated technique, we should first look at how well we are implementing the fundamentals.

For example, what good does it do us to implement the latest agile techniques on a project where we haven't adequately implemented rudimentary change management disciplines? Similarly, what good would it do to implement Monte Carlo simulations in a context where we haven't adequately identified basic risks?

In my estimation, our success depends almost entirely on how well we have implemented fundamental risk and change management processes.

Things go wrong and plans change -- yet we often charge ahead without adequately planning and preparing for those realities. Certainly, our intuition tells us this is true, and our experience validates our intuition. Yet it still often happens that we lose sight of the obvious fact that the basics matter and matter most.

If you should ever waiver in your conviction, look no further than PMI's 2012 Pulse of the Profession. The report notes that change management and project management basics are among the most critical project success factors.

New and sophisticated techniques have their place, but the best thing to do in any profession is to go back to basics. Don't let the allure of the sophisticated or the novel, distract us from the value of fundamentals.

To discuss Pulse of the Profession on Twitter, please use #pmipulse.

See more on the Pulse of the Profession.

Posted by Jim De Piante on: July 19, 2012 11:05 AM | Permalink | Comments (12)
ADVERTISEMENTS

A doctor can bury his mistakes but an architect can only advise his clients to plant vines.

- Frank Lloyd Wright

ADVERTISEMENT

Sponsors