Voices on Project Management

by Kevin Korterud

The technology found in today’s automobiles is simply amazing. Front and side traffic radar units, anti-dozing head movement detectors, driving timers that alert drivers when they should stop for a break­ — all good examples of accident prevention mechanisms.

Projects to some degree are like automobiles: They are on a journey to deliver passengers (the project team and stakeholders) to a pre-determined destination. However, despite the introduction of many modern project management technologies, research shows that we continue to experience project accidents. These accidents result in extensive and costly rework to get a project back on track. 

I think part of the solution to avoid these potential problems is to borrow from recent automobile technologies as a way to detect troublesome signals. These signals are not readily perceivable from traditional project management methods.

Here are a few examples of anticipatory signals that portend the onset of a skid that often leads to a project accident.

1. Forecast Volatility

A core competency of a project manager is to determine the schedule, budget and progress trajectory of a project. The project forecast is essential to determine where the project will finish for these measurements. Schedule, budget and progress forecasts from team members that exhibit great degrees of change over prior reporting periods are indicative of trending to an accident. This downward spiral is exacerbated when the forecast measurements come with great uncertainty; e.g., “I don’t know what this will take to finish.”

Several techniques can be employed to reduce the volatility of forecasting. Some of these techniques include initiating a peer review of the forecast with another project manager or supplier subject matter expert, as well as pausing the project to recalibrate the forecast in a dedicated working session. Taking time to implement these and other techniques to mitigate forecast volatility will get the project back on track before an accident.

2. Static Project Status

Project status reports can offer a tremendous amount of value to a project manager. They accumulate both qualitative and quantitative data that sheds light on the current project state. But, despite the visibility status reports provide, they’re just a snapshot. That limits their ability to show progress trends. In addition, a project status report that does not show content changes week over week indicates that the project is likely stalled and headed toward an accident.

To increase the anticipatory value of a project status report, introduce trending and predictive data for risks, issues, deliverables and milestones. This allows the project team to determine what level of progress has been achieved, as well as what progress to expect. It also better positions the project manager to escalate mitigations to avoid an impending project accident.

3. Diminishing Stakeholder Engagement

At the beginning of a project, stakeholder engagement and enthusiasm is typically high. This is not unlike the start of a road trip. But, as time passes on a project, the level of enthusiasm and engagement can begin to wane. Stakeholder engagement over time will face tough tests from project risks to resource challenges to dependency conflicts. Each can sap the energy levels of stakeholders. This leads to passive engagement at best and complete disengagement and absenteeism at worst.

To keep stakeholder engagement at the proper level, stakeholders need to be treated like any other resource on a project. Their time needs to be managed in work plans to avoid oversubscribing their capacity. In addition, their work should be focused on higher value activities that promote project progress. Providing the team access to project support staff to maximize productivity also helps further stakeholder engagement and leads to persistent engagement.

Perhaps one day in the future there will be technology solutions that provide anticipatory signals for projects headed for an accident. Until that day comes, however, project managers still need to think organically and look for hidden signals of dangers to project budgets, schedules and progress.  

What do you see as the leading indicators that a project is trending toward disaster?

by Dave Wakeman

Where do you stand on the value vs. benefits debate? 

As someone who spends most of my time managing projects in marketing and revenue-generating roles, I likely see the idea in a much different way. 

To me, value is the most important thing that you can sell to your sponsors, stakeholders and your team.

Why? 

I think it’s pretty simple: If you are selling benefits, you have allowed yourself to slip into the world of commodity. 

As the need increases for project managers to advocate for resources and execution in projects, it’s important that we don’t give weight to commodity thinking. If we allow ourselves to become a commodity, it becomes much easier to ignore our project, cancel the project or not give the project the resources it needs to be successful. 

Value, on the other hand, allows you to explain your project in terms of impact. And if your stakeholders, sponsors and team see the impact and the improvement of what your project will mean to the organization, community or stakeholders, it becomes much easier to sell the importance of the project, the need for resources and the benefits. 

Here are a couple ideas on how you can prioritize value in your projects.

Lead with impact. Think about how the work you are doing is going to improve people’s lives, the success of an organization or some other high impact measure that will get people excited. 

Here’s an example: In working on the New Year’s Eve ball drop in New York’s Times Square for several years, I could have easily said my main job was to make sure that I expedited people’s access to the restricted areas, hastened the process of getting people in and out of Times Square and ensured that the primary entertainment events went off in a timely manner. 

That would be missing the point. The impact that I created was that I ensured that the logistics of the ball drop didn’t stand in the way of people having a safe, enjoyable New Year’s Eve experience. 

In the first example, those are just commodity activities. 

But if I do the job of selling the value the right way, it’s much more likely that the project is going to go through in a way that I hope for. 

Don’t just think of the tangible benefits; think of the intangible benefits too. The core of the benefits argument is that tasks are the only thing people value in business or project management. 

As someone that started out my career working in entertainment exclusively, I recognized pretty early on that what people view as a benefit often is independent of what they are actually getting from physical goods. 

For all of you thinking about value over benefits, this boils down to tangible versus intangible value.

If you are selling the value of your projects, and you want to increase the impact of your conversation, focus on impact. Think about it from both the tangible and intangible angles. 

The tangible value in your project might be how much more money they are going to earn, how much money they are going to save or how much more efficient something will be. 
Intangible values shouldn’t be discounted — they often carry a higher impact than tangible values. And the fulfillment of intangible needs often is the reason that people buy into the tangible values as goals. 

Your sponsor or stakeholders might really be much more excited by less stress from commuting, in the case of a mass transit or road project. They might find that the reduction in time allows them to spend more time at home with their family. 

Or, the intangible might be something else entirely. 

The key is to not allow your project to just become a checklist of activities. If you do, you are likely dealing with commodity status and no project team does their best work in that situation. 

By Peter Tarhanidis, Ph.D., M.B.A.

Program teams should collaborate like a world-class orchestra.

This ideal state of team engagement and performance requires the presence of several key elements, including an engaged sponsor, a governance committee, a project manager and a status dashboard to communicate performance.

However, maximizing this level of performance is especially challenging when working with cross-functional groups, external stakeholders and shareholders. This increases the complexity of the human performance aspects of team management.

I recall one assignment I worked on that required the team to design and build a new centralized model to bring together three different operations. The team was given two additional challenges. The first challenge was to consolidate disparate teams into two geographic centers. They also had to reduce the overall timeline from 18 months to 10 months.

These challenges exacerbated how teams were not working well with their counterparts. They quickly became dysfunctional and lost their purpose. The project was crashing.

Stepping into this situation I decided to conduct a stakeholder analysis. I used this approach as an intervention method to understand the underlying themes. The analysis revealed the team:

1. Lacked shared values: Members did not have a sense of purpose on the intent of the program.
2. Were not being heard: Members felt they had no control over the program’s major activities or tasks.
3. Lacked trust: Members felt they could not rely or confide in their fellow team members, sponsors or peers to accomplish tasks on the program.

After reflecting on the team’s feedback, I realized that most members wanted to find meaning in their work. It seemed no one was developing their sense of shared purpose and putting their strengths to work toward this program.

I decided I needed to re-invest them as members of the team. To get the team back to performing well, I:

1. Built rapport with various team members
2. Gained their trust by delivering on my commitments
3. Integrated their perspectives into decision making
4. Recruited new members to build up gaps in team capabilities
5. Focused the conversation on our individual purposes and aligned them to a shared value

This approach strengthened the program and delivered on the challenges.  

The lesson learned is, do not simply apply methods and approaches in complex program delivery. Manage the team’s purpose and establish shared values as an important driver of overall delivery.

How do you manage that purpose and invest in high-performing teams?

By Christian Bisson, PMP

As most of you know, scrum works in iterations called “sprints” that can vary in duration depending on the product. However, there is some debate about what people call a “Sprint 0”: a sprint used for planning or prework deliverables that will help launch Sprint 1.

There are no one-size-fits-all ways to work, but personally I believe Sprint 0 is necessary in many cases. Here’s why:

A Minimum of Planning

One big difference between waterfall and agile is how planning works. Waterfall tends to focus a lot (sometimes too much) on planning, while agile tends to be the opposite. For most projects with lots of unknowns, planning too much will be a waste of time because the project will evolve and most of the work done in advance will be wasted. That’s why you plan as you go in agile.

However, when you start a product from scratch (e.g., a website, software, etc.), there are many decisions that will affect the entire product development — some of which can block developers from coding on day one. For example, what is the best programming language/framework to use? Teams need development environments amongst several other tools. This setup can use up a lot of time and prevents work from gettting done if nothing is available. Sprint 0 becomes crucial to give the team time to prepare so they can code properly from the start.

Sprint 0 helps with that by providing a first iteration that allows the team to plan enough for Sprint 1, whether with analysis, wireframes, designs, etc.

Team Orientation 

Chances are, the team has never worked together before. The Sprint 0 approach can help the team set up and get to know each other, which will help them at the sprint planning of Sprint 1.

Other factors to consider are estimating tasks, timing of ceremonies, understanding everyone’s role and so on — all important elements that make or break a team’s efficiency.

It’s also a perfect opportunity for the scrum master to get the lay of the land and identify where to focus first to help the team.

Many would argue that value should be delivered at the end of a sprint.  And Sprint 0 does not offer that to the stakeholders, which is true. However, not much real value will be delivered from a Sprint 1 that is wasted by the complete lack of preparation!

What are your thoughts on Sprint 0?

By Mario Trentim

A successful project requires a combination of technical and managerial activities at every stage to jointly deliver the final result and its benefits.

If you have high levels of maturity in project management without the equivalent technical knowledge, your project is doomed to deliver a poor solution. On the other hand, when you have best-in-class technical knowledge without project management maturity, your project is also doomed to be inefficient and maybe even inefficacious.

Many organizations have already developed competency models to encompass technical and managerial aspects of projects, describing overlapping areas and highlighting essential project management and systems engineering foundations of successful projects.

Consider the U.S.’ National Aeronautics and Space Administration’s (NASA) competency model, which “outlines distinct competency areas for project managers and systems engineers, as well as shared competencies that encompass both disciplines.”

Examples of defined project management competencies include:

• Stakeholder management
• Safety and mission assurance
• Cost estimating
• Risk management
• Project control

Examples of defined system engineer competencies include:

• Technical requirements definition
• Product verification
• Configuration management
• Technical data management
• Interface management

Examples of shared competencies include:

• Workplace safety
• Communication
• Team dynamics and management
• Safety and mission assurance
• Knowledge capture and transfer

You might be asking yourself what does NASA have to do with your own daily projects? Most of us are working in projects and programs far simpler than building space systems. However, my objective here is to call attention to the best in class so that we can contextualize and tailor their model to our own reality.

Of course, in order to achieve a proper balance in your projects, thoughtful tailoring is essential. Take the International Council on Systems Engineering’s handbook, A Guide for System Life Cycle Processes and Activities:

“On smaller projects, where the span of required communications is small (few people and short project life cycle) and the cost of rework is low, Systems Engineering activities can be conducted very informally (and thus at low cost). On larger projects, where the cost of failure or rework is high, increased formality can significantly help in achieving project opportunities and in mitigating project risk.”

Even small and medium projects can benefit a lot from the proper combination of project management and systems engineering. Systems engineering is helpful not only in developing complex products and services, such as a spaceship or an air traffic control system, but also in less sophisticated products such as a bicycle or an alarm system. In fact, systems engineering is even helpful when you are designing your new house.

What product development approaches are you using today? Please share your thoughts in the comments below.