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

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rebecca Braglio
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina

Recent Posts

How to Avoid Dysfunctional Project Team Setups

When Project Benefits Erode

What Do Next-Gen Project Leaders Look Like?

How to Avoid Useless Meetings

Future-Proof Projects — and Careers — With a Little Engineered Serendipity

When Project Benefits Erode

By Conrado Morlan

The project you led is complete! You are celebrating with your stakeholders and other project managers. The company is right on track to achieve its strategic goals based on the benefits delivered by your project.

After handing over the project to the business functions, you are now ready for your next move. You are nervous and excited about discovering your new assignment, so you don’t worry about your recently completed project. Somebody else will be following up on the project’s contributions to the organization. You’re done, right? Well, let’s find out.

During the first six months of your new assignment, you overhear that the benefits of the project you recently completed are not at the expected level. In parallel with your current assignment, you start looking for clues about what’s gone wrong.

Your findings reveal that related processes supporting the product or service delivered by your project are not aligned and are producing damage and losses, resulting in the erosion of benefits. Examples may include:

  • Regulatory fines—The project’s support processes did not provide regulatory reports on time or were missing data requested by federal and/or local authorities. The lack of compliance results in fines.
  • Overtime—The lack of clarity about the process and the changes brought by your project led the operational areas of the business to continue to do work as usual, producing incorrect results that had to be redone.
  • Overlooked tax deductions—The finance department was not notified of the new process, and the organization continued to pay taxes that were supposed to be exempted after the project was completed.
  • Union disputes—The implementation of the new project impacted union workers’ duties that weren’t contemplated in the current contract. New contract negotiations tend to be long and have a large impact to the organization.

So what should you do? Focus on your current project assignment and ignore the benefits erosion? Or work on a solution with the project’s stakeholders?

Whatever your answer, one thing you will need to do for sure is update the project’s lessons learned. The project may be over, but benefits didn’t reach the expected levels. So as the former project manager, you’re obligated to document what went wrong to support efforts at establishing a solution.

Have you ever learned of benefits erosion after completing one of your projects? If so, how did you react?

Posted by Conrado Morlan on: May 25, 2016 01:38 PM | Permalink | Comments (3)

How to Think Big While Managing Small Projects

 

By Kevin Korterud

 

It’s typical for new project managers to be assigned to a small project to build their skills. Why? Small projects have a limited value at risk, a modest budget, a shorter schedule and a smaller team. But project managers early in their career who have successfully led small projects often ask me how they can move on to leading big projects.

 

Small projects, to some degree, can be more difficult to lead than larger ones. You are given much less in the way of reserve budget, schedule and resources. However, big projects are not just smaller projects with larger budgets and longer schedules. They have inherent complexities relative to stakeholders, scheduling, resources and deliverables not found on small projects.

 

My recommendation to project managers wanting to move to larger projects is to “think big” while running smaller projects. Thinking big involves adopting, where possible, practices required for large projects.

 

Here are two ways project managers can think big on projects. My next post will offer two more tips.

 

1. Leverage Support Resources  

Many times, project managers running small projects attempt to perform all of the project operations activities themselves. This can include creating new work plans, calculating progress metrics, scheduling status meetings, and performing a host of supporting activities for the project.

 

While it may be a source of great pride to a project manager to perform these activities, they represent an opportunity cost. In other words, the project manager could instead be working on higher-value activities like stakeholder management or risk management.

 

Employing support resources even on small projects can save valuable time and costs. It also means the project manager doesn’t have to spend time becoming an expert in the tools and internal project operations processes. By having other people assist with the mechanics of building project plans and producing metrics, the project manager will have additional capacity for running the project.

 

 

2. Implement Quality Assurance Processes   

Project managers on small projects tend to become immersed in a level of detail not possible on large projects. The small project also allows for deep interaction with team members that may not be effective on large projects.

 

In addition, a project manager on a small project may be tempted to start serving in roles akin to a business analyst or technology designer. This can distract the project manager from actually running the project.

 

To keep focused on project management activities, quality assurance processes should be implemented. Phase gate reviews, deliverable peer reviews, change control processes, quality performance metrics and the definition of project acceptance criteria are all good examples of quality processes. With the implementation of these processes, project managers can focus on deliverables and outcomes without getting too deeply immersed in the details of the project.

 

Check back for my next post on more ways project managers can develop a big-project mindset while executing small projects.

 

Posted by Kevin Korterud on: May 05, 2016 10:20 AM | Permalink | Comments (2)

Is Your Agile Communications Toolkit Up to Snuff?

By Taralyn Frasqueri-Molina

A lot of things change when moving from traditional project management frameworks to agile ones. But what doesn't change (or shouldn't!) is how much and how often teams communicate. 

Agile frameworks don't actually require daily stand-ups or regular retrospectives. But you should consider adding some new trade tools and a few other staples to your project management toolkit if you’ll be working in an agile context. You may find that they quickly become essential to keeping communication flowing through your team—and your project on track.

Here's a short list of tools I've used on all of my projects.  

Sync-ups/Planning Meetings: This helps me start a project off right by making sure the product owner and execution team are on the same page. We set expectations, talk requirements and the direction for deliverables in areas such as UX, design, marketing.  

Daily Stand-Ups: Quick check-ins with the entire team help gauge project health and bring roadblocks to the forefront sooner rather than later. This is also where we address scope creep, taking note of good ideas that need more exploration before being included in the backlog.

Retrospectives: After each sprint and after each project, a retro helps the team ensure processes are working— and decide if we want to carry over those processes to the next iteration.

Wiki: These often get a bad rap but can act as an excellent centralized location for real-time documentation editing and sharing. In my experience, it can serve as a digital asset management (DAM) system for sharing web copy and design assets. While not a perfect DAM solution, it will do in a pinch.

Instant Messaging: Whether collocated or remote, teams sometimes need quick answers to questions—and a meeting can be overkill as a way to get answers. The challenge with instant messaging, though, is to make sure teams are on the same page about how and when to use an IM tool.

Email: This tool still reigns supreme when it comes to quickly keeping a lot of people in the loop about what's going on. Even if it's an email directing people to a wiki, it's still one of the best tools for mass communication. But maybe not for decision-making!

What tools am I missing? And do you find any of the tools mentioned particularly good or bad for certain kinds of communications? Share your thoughts below.

Posted by Taralyn Frasqueri-Molina on: March 24, 2016 12:30 PM | Permalink | Comments (7)

Project Leaders as Ethical Role Models

 

By Peter Tarhanidis            

This month’s theme at projectmanagement.com is ethics.  Project leaders are in a great position to be role models of ethical behavior. They can apply a system of values to drive the whole team’s ethical behavior.

First: What is ethics, exactly? It’s a branch of knowledge exploring the tension between the values one holds and how one acts in terms of right or wrong. This tension creates a complex system of moral principles that a particular group follows, which defines its culture. The complexity stems from how much value each person places on his or her principles, which can lead to conflict with other individuals.

Professional ethics can come from three sources:

  1. Your organization. It can share its values and conduct compliance training on acceptable company policy.
  2. Regulated industries. These have defined ethical standards to certify organizations.
  3. Certifying organizations. These expect certified individuals to comply with the certifying group’s ethical standards.

In project management, project leaders have a great opportunity to be seen as setting ethical leadership in an organization. Those project leaders who can align an organization’s values and integrate PMI’s ethics into each project will increase the team’s ethical behavior. 

PMI defines ethics as the moral principles that govern a person’s or group’s behavior. The values include honesty, responsibility, respect and fairness.

For example, a project leader who uses the PMI® Code of Ethics to increase a team’s ethical behavior might:

  • Create an environment that reviews ethical standards with the project team
  • Consider that some individuals bring different systems of moral values that project leaders may need to navigate if they conflict with their own ethics. Conflicting values can include professional organizations’ values as well as financial, legislative, religious, cultural and other values.
  • Communicate to the team the approach to be taken to resolve ethical dilemmas.

Please share any other ideas for elevating the ethical standards of project leaders and teams, and/or your own experiences!

Posted by Peter Tarhanidis on: February 22, 2016 09:45 AM | Permalink | Comments (19)

Help! I Have Both Waterfall & Agile Projects in My Program

By Kevin Korterud

As both a project and program manager, I’m always keen to have projects and programs take the right first steps toward success. In the past, this would involve selecting the unified delivery approach used for all of the projects on a program. The idea was to impart consistency to the way projects were managed as well as produce common metrics to indicate progress.

It’s not that easy anymore. Today’s programs have projects with agile, waterfall, supplier, corporate and sometimes regulatory-mandated delivery approaches. In addition, these approaches as well as the different arrangements made with suppliers (e.g., time and materials vs. fixed price with deliverables) have dramatically increased the level of complexity and diversity of delivery approaches within a program.

So as a program manager, how do I keep all of these projects in sync no matter the delivery method? As a project manager, how can I execute my project in concert with the overall program in order to maximize the value that will be delivered, while avoiding schedule and cost overruns resulting from projects not operating in harmony? 

These are emerging challenges for which there are no single easy answers, of course. But I have found a handful of tips useful in getting a program’s projects to operate in a synchronized manner. I’ll share the first few in this post and the final ones in my next post, appearing later this week.

1. Remember: There’s No Such Thing as Agile or Waterfall Programs  

Given the mix of project delivery approaches, the program needs to properly segment work to manage the budget, resources and schedule regardless of the project delivery approach. In addition, the schedule alignment points, budget forecast process and deliverable linkages need to be identified between the various projects.

Typically, I find that while there is effort to plan for these items at the project level, the upfront effort for this harmonization at the program level is underestimated or sometimes left out altogether—program managers think the project teams will figure this out themselves. This sets the program up for schedule and budget overruns as well as overall dilution of the program business case.

Some ways for a program manager to harmonize projects on a program include:

  • Determine which agile sprint cycles will be used for aligning data integration, requirements and deliverables with the other projects.
  • Forecast the number of agile sprint cycles possible given the program schedule and budget parameters.
  • Use an integrated schedule to constantly generate awareness of relative project progress within a program—no matter the delivery approach.
  • Identify key dependencies between projects in the program; this can include event, deliverable and external dependencies.
  • Use active resource management across all projects on the program. 

2.  Make the Correct Delivery Approach Choice Before a Project Begins

The type of delivery approach for a project is determined by the type of work being performed and the end consumer of the project’s deliverable.

For example, a project on a program that is slated to create a consumer portal would be a desirable candidate for an agile delivery method. Another project that involves heavy system integration that a consumer never sees would be a candidate for a waterfall approach. A project to pass data into a government system would likely have its delivery approach set by the governmental body.

So before a project starts, program and project managers should agree on the optimal delivery approach that is the best fit for the project.   

Look for more advice in my next post on synchronizing a program’s projects, regardless of delivery method.

 

Posted by Kevin Korterud on: February 13, 2016 11:40 AM | Permalink | Comments (1)
ADVERTISEMENTS

"Words are the most powerful drug used by mankind."

- Rudyard Kipling

ADVERTISEMENT

Sponsors