Voices on Project Management

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.

By Mario Trentim

A project is a planned and coordinated piece of work that requires considerable effort to deliver a specific result.

According to PMI’s A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), a project is a temporary endeavor to create a unique result. And it is performed by people, constrained by limited resources, planned, executed and controlled.

Project management is an interdisciplinary approach to balance the conflicting interests and constraints of a project: well done (scope), fast (time) and cheap (cost).

Although there are other important aspects of managing a project that will be covered in subsequent posts here, the triple constraint (scope, time and cost) implies that a project, large or small, addresses at least the following areas:

• Specific outcomes and results: requirements and deliverables (scope);
• Definite tasks, start and end dates: schedule (time);
• Established resources: people, materials and budget (cost)

Project managers perform four primary management functions:

1. Planning: This encompasses project initiation and detailed planning, involving processes to identify needs and requirements, define deliverables and tasks, estimate resources and develop the project management plan.

2. Organizing: This function prepares for execution, it is a supporting and administrative function to provide project structure and governance. Most of the time, organizing involves staffing and procurement, but other preparation activities might be included here.

3. Directing: This is the management function of getting the work done, managing execution according to the plan. It encompasses stakeholder engagement, team management and communications management.

4. Controlling: This function takes care of project performance monitoring, preventive and corrective actions and the integrated change control.

These functions might be performed in parallel and should not be understood as sequential.

Outside of these functions, project managers should also focus on managerial aspects of the project, including leadership. Although it is desirable that the project manager possess some knowledge in general business management, business analysis and the technical aspects of the project, they are usually supported by other experts in a number of project management related disciplines including systems engineering, requirements engineering and specialist engineering disciplines, quality assurance, integrated logistic support and more depending on the project and industry.

But, are these best practices really universal given all these factors? Please leave your comments below. We’ll be looking further into this question in subsequent posts.