Voices on Project Management

by Kevin Korterud

Once upon a time, projects were just projects. They were simple, had small teams and quite often finished on time. Projects were viewed as a path to operational improvements that reduce manual labor and free up people for other tasks.

As time marched on, the notion of a project began to increase in scale and complexity. Technology projects, for example, began as modest hardware and software initiatives. Over time, the technology project landscape has changed to include network, servers and cloud infrastructure. Software projects began growing into systems, software packages and complete end-to-end solutions.

As the quantity and business focus of project work increased, they became packaged into programs. Programs were created to help orchestrate myriad projects into cohesive outcomes. These were governed by an expanding slate of waterfall methods designed to both enable and oversee delivery.

With the advent of agile, a different form and pace emerged. Product delivery moved toward quicker and more frequent outputs, with delivery cadence driven by what an organization believed was best for customers and consumers.  

Today, organizations have a delivery ecosystem of project, program and product delivery work based on internal and external dynamics. As the ecosystem changes over time, the balance of projects, programs and products does as well.

With project, program and product delivery all moving in different directions and at different speeds, how can an organization prevent these efforts from crashing into each other? Here is an approach I follow to help define, oversee and enhance the natural delivery ecosystem:

1. Define the Ecosystem   

First, ensure that definitions are in place. These should be clear and concise portrayals of the work to be performed. Having these definitions commonly understood will go a long way in matching the correct policies, processes, controls and people to the form of work.

Here are some sample definitions:

• Projects are work efforts that reflect process and system interactions with fixed durations to complete. They contain teams that form and disband, have a budget under $10 million and last under a calendar year.

• Programs are packages of projects intended to contribute to a common business with a budget of over $10 million and that last longer than a calendar year.

• Products reflect process/system-to-consumer interactions with delivery cadence based on dynamic market needs. They have a mutually agreed-upon spend, typically employ agile methods and employ a continuous team that improves delivery efficiency over time.

These definitions also serve to identify the portfolio proportion of these different types of work, which helps determine the right people and supporting structures for success.

The ecosystem can change and flow to meet the needs of organizations, market forces, suppliers and people. Given this ebb and flow, one practical reality of this ecosystem is that any one form of project, program and product work cannot exist as 100% of the work.

2. Govern the Ecosystem  

Any delivery ecosystem left to its own resorts will result in chaos with teams having different perceptions of how project, program and product delivery  should be executed. This chaos will result in delays, additional costs and sometimes stalemates as teams negotiate over the execution of work efforts.

There needs to be balancing forces in place that help direct delivery. A delivery ecosystem governance model sets the boundaries for delivery work from ideation into formation and through execution. The governance model implements policies, processes and enabling artifacts that create predictable and repeatable attainment of desired results. This governance model is typically overseen by an enterprise delivery management office.

For example, one process within this model sets the venue to identify, confirm and release for execution the proper delivery process for a type of work. A portfolio review board based on input from the sponsor would analyze the characteristics of the work and determine whether it is a project, program or product. The outcomes from this portfolio review board promote consistency, ensure impartiality and avoid costly re-work due to poor decision-making.  

3. Harmonize and Improve the Ecosystem

Even an effective delivery ecosystem needs to have a “tune-up” every once in a while. As changes in business strategy, support for new regulations, market expansions and technical innovations come into play, the delivery ecosystem needs to change accordingly. These drive the need for a function to continuously harmonize and improve the delivery ecosystem. An EDMO will be the primary vehicle to both harmonize and improve the delivery ecosystem within an organization.

Improvements can include initiatives to reduce mobilization time, avoid resource contention and improve supplier integration. These initiatives are universal in nature and can be consistently applied to improve project, program and product delivery.   

With the increased complexity of work and differing approaches for projects, programs and products, you need a means of harmonization to prevent misalignments, conflicts and collisions between work efforts. Harmonization processes can include release, dependency, data integration and test environment management.  

Embrace the New Normal

Organizations need to recognize and embrace the different forms of delivery that are now the new normal. By adopting a structured approach to the definition, oversight and enablement of projects, programs and products, they can be delivered in a synergistic manner to lower costs while improving time to market and quality. 

How do you balance the project, program and product initiatives at your company to avoid weather problems?

By Lynda Bourne

After more than 40 years in project management, project controls and project governance, I’ve learned that every successful organization has its own unique culture and structure. Nothing works “out of the box.”

Each organization needs to identify the aspects of its existing culture and the parts of its management systems that offer the best opportunities for improvement, define options that may work (there are no guarantees), and decide on the steps needed to deliver the desired improvements.

This process is a journey, and the measure of success is achieving the level of maturity where continuous improvement is organic and internal.

Here are my tips for getting there:

1. Set the right objectives. Projects and programs should support the organization’s strategic objectives. Achieving this requires a number of elements:
   • A realistic and achievable strategic plan
   • A portfolio management function designed to optimize the selection of the “right” projects and programs to undertake to maximize the delivery of strategy
   • A robust and reliable process to develop and test the business cases used in the portfolio management processes, as underestimating the cost or difficulty in delivering a project guarantees failure before it starts
   • A sound appreciation of risk and uncertainty to ensure adequate contingencies are in place by applying techniques such as reference class risk assessments
2. Understand the objective and value proposition for each project and program. The outputs from a project enable the organization to undertake new or improved activities that are intended to create value. Decision-making needs to be based on a clear understanding of:
   • The critical success factors for each project—what really matters from an organizational perspective
   • The project’s overall value proposition, which involves more than simple cost accounting
   • The organizational changes needed to implement the project’s deliverables and realize the intended value
3. Establish organizational capabilities to manage the work of a project or program. Select contractors and suppliers based on the three Ps:
   • The promise, ensuring the promised performance in terms of time, cost and scope is realistic, achievable, understood by all involved
   • The performance of the work based on a robust and accurate assessment of current performance against the promise, identifying all significant variances and determining the reason why they have occurred
   • The prediction of future outcomes based on current performance. The most reliable predictor of future performance is the performance to date. This will not change unless something in the performance space is done differently. Changing performance requires planning, takes time, usually involves cost and there are no guarantees of success.
4. Optimize and manage risk. There is no such thing as a risk-free project. Mature organizations proactively manage all aspects of risk and opportunity ranging from safety and the environment to the achievement of the project’s objectives and value proposition.
5. Prepare the organization to effectively manage change. Change is inevitable! Mature organizations have systems in place to assess and manage change requests in a proactive and time-efficient way based on the project’s overall value proposition.
6. Document robust governance procedures. These should be focused on ensuring the organization’s systems and management structures are “fit for purpose” and continually improving.

Rely on These Resources for Help Along the Way

PMI has a range of resources to assist you on this journey. The newly created Standard for Organizational Project Management (OPM) provides a framework to align project, program and portfolio management practices with organizational strategy and objectives. This standard is supported by the Organizational Project Management Maturity Model (OPM3^®), which defines a framework to measure progress toward maturity. These are assisted by Implementing Organizational Project Management: A Practice Guide. Finally, the Governance of Portfolios, Programs and Projects: A Practice Guide takes a closer look at the different types of governance and how you can implement or enhance governance on your portfolios, programs and projects. All of these standards are free downloads for PMI members.

This may not be the area many project managers focus on, but maybe it’s time for a change. After all, we cannot deliver successful projects when the project is set up to fail. Influencing senior management to focus on improving organizational maturity so that most projects have a fighting chance of being successful is good for everyone.

Have you created a culture of continuous improvement at your organization? I’d love to hear from you—please share below.

For those of us in the project management community, agile is a familiar term. But despite its prominence, it’s often misunderstood. 

All too often, teams and organizations focus on the wrong things or are misinformed. And eventually, agile takes the blame. 

Here are six common misconceptions that can lead to an anti-agile mindset:

1. It is all about the tool. Any tool that’s hailed as what makes agile works is still just a tool. Yes, with distributed teams it helps to have a tool where everyone has access to project details and data. However, when introducing your team to agile, your training shouldn’t be tool-centric. I prefer teams to see and understand how agile really works—the simple use of sticky notes or a whiteboard does the trick. The move to a tool can and will happen eventually, and when it occurs, you don’t have to send multiple follow-ups to ensure the team is populating the data. 

2. Agile is changing requirements in the middle of the sprint. While agile is known for inspecting and adapting, changes can get out of control. I hear teams talking about changes happening so often that they can barely focus on the work, or they are constantly handling changes. When the pressure to change a requirement is happening too often within a sprint and ends up becoming a norm in the team, the product managers or sponsors need to jump in to determine what needs to be built. Otherwise, team members tend not to focus on the work because they know no matter what they do today, everything will change tomorrow.

3. Agile doesn’t use data. The idea that data isn’t tracked is wrong. In fact, there are many ways to look at data. However, we also have to be mindful so data isn’t just being used for the sake of data, leading teams to start bluffing around it.  

4. Agile doesn’t offer predictability. You’ll often hear that there was better predictability before—and now nothing works. Sponsors always need to know the timeline. And yes, this can be done in agile. In fact, using and tracking the right data can bring in the predictability your team needs. The velocity metric will let you know how much a team can handle in a sprint. So, whether it’s a burndown chart, sprint or release planning, there are multiple ways to get the required predictability and commit accordingly.   

5. Agile doesn’t offer time to think. I recently was in a session about thought leadership and someone mentioned agile being the greatest blocker because there was no time to think. Interpretation, I believe, is the biggest problem of all. You can still block a certain percentage of your team’s capacity or yours to try out new ideas, participate in hackathons or learn a new skill that adds advantage to your product or service. If you are not speaking up about the problems, you should. And if flexibility isn’t allowed, that’s because of the team culture, not the process. 

6. Agile is all about micromanagement. One of the funniest misconceptions I’ve heard is that an organization moved to agile because leadership wanted everything to be micromanaged. Individuals didn’t understand that team capacity and complexity (as measured in story points) aren’t ways to track team members. Instead, they are tools to help team members make the right commitments during their sprints, commitments they can actually keep and deliver. In this case, a lack of explanation about why the organization moved toward agile triggered multiple miscommunications. So, the responsibility lies with management and the agile coach to take the time to explain the move to agile. Because instead of micromanagement, agile is really about the opposite. It, in fact, allows teams to be empowered, to be able to self organize, to be vocal and to get the work done. 

These are six misconceptions I’ve seen about agile. What are the common ones you’ve encountered?

By David Wakeman

I’ve got a hypothesis I want to drop on you: Being a project manager is a lot like being a juggler. 

Many of you may be scratching your heads, asking the question: “What is Dave thinking?” 

Hear me out. I’ve got three examples to support my hypothesis. 

1. Project managers, like jugglers, are required to keep a lot of balls in the air. You have to manage your team, communicate to your stakeholders, run changes and a whole host of other things. 

A great juggler, or a crazy one, might be juggling a chainsaw or a dozen balls. Although I never learned to be a good juggler, I do know that the key skill is focusing on one ball at a time.

The same can be said for a project manager. You may have 20 things on your to-do list, but you can’t do all 20 things at once. You can only do one thing at a time. 

This is important because if you’re trying to send an email to a stakeholder at the same time you’re having an in-person conversation with another stakeholder, you probably aren’t giving either of them your full attention. And you could miss the opportunity to make a point, get information or create change. 

Need I say what happens if you take your attention off a chainsaw? 

2. Project managers, like jugglers, are manipulators. I don’t mean this in a negative way, but instead in that they change people’s perceptions of what is happening in front of them. 

Yo-yo-ing is considered a form of juggling with tricks like “sleeping,” “looping” and “walking the dog.” All of these are ways to get the yo-yo to do what the juggler wants it to do. 

How is that different than what project managers do?

As a project manager, your job is to get your team to do what you need them to do to bring your projects in on time, on schedule and within scope. 

You achieve this by using the tools at your disposal to motivate, encourage and guide your stakeholders and team toward your goal. That’s juggling. 

3. It all comes down to results. Finally, a bad juggler gives a bad performance, and a good juggler gives a good performance … and no one knows whether they are just having a bad or good day. Ultimately, the same applies to projects and their leaders. In the end, we are judged on performance.

Did our project meet specifications? Did it come through on schedule? Were we able to get the results we needed out of our team?

For a juggler, if they aren’t entertaining, they are failing. Which I guess means that project managers actually have an easier job than jugglers because we don’t always have to entertain, but we do have to produce results. 

What do you think? Are project managers like jugglers—or have I gone crazy with this metaphor? Let me know below in the comments. 

by Cyndee Miller

There’s something about TED Talks that suck you in. Those big red letters on a stage signal this isn’t just another presentation. And TED’s 18-minute rule is genius. The videos are long enough to provide real substance—while feeling zero guilt about forwarding them on and building a veritable viral sensation—and short enough to keep you from checking your social feed. So I was wildly curious about what to expect walking into the closing session of this year’s EMEA Congress: As part of PMI joining forces with TED, attendees got a specially curated series of five live talks around the power of possibility.

“What’s possible in the world is really bound by two things if you think about it,” said Sally Kohh, a political pundit and TED speaker who hosted the event. “There’s what’s literally possible—what we can actually, tangibly, scientifically, physically do—and then there’s what we think is possible. And often we don’t try things—we don’t even think things—not because we can’t do them, but because we don’t think we can. We circumscribe our own aspirations and sense of the possible, and therefore actually constrict what’s possible before we even start.”

That all sounds lovely. But it also conjures up images of sunshine, kittens and unicorns. Then in walks Mona Chalabi, data editor at The Guardian, with her take on the possibility of information. Aside from my own personal addiction to news and numbers, I spend a lot of time wading through research reports. So I was instantly intrigued by what Ms. Chalabi had to say: “When it comes to numbers, especially now, you should be skeptical.”

Instead of blindly accepting (or rejecting) data, she challenged attendees to ask three questions—our very own sniff test of sorts:

1. Can you see uncertainty?  
2. Can you see yourself in the data?
3. How was the data collected?

Data can be powerful, but it can also be used to drive division. Boston Consulting Group’s Julia Dhar discussed ways to find common ground by reshaping the way we talk to each other. It starts by separating a person’s identity from the idea—letting us ”open up to the idea that we might be wrong.” One tip from Ms. Dhar that project and program managers can immediately put to use: Devote 10 minutes of your meeting to real debate.

Anab Jain tackled another topic familiar to almost anyone in business, including most project professionals: trying to predict the future. Her advice? Stop being so passive.

“Today it can feel like things are happening too fast—so fast that it becomes really difficult to form an understanding of our place in history,” said Ms. Jain, co-founder of design and innovation studio Superflux. It can be so overwhelming that “we let the future just happen to us,” she adds. “We think of our future selves as strangers and the future as a foreign land.”

As you might suspect based on the sunshine, kittens and unicorns comment, I don’t exactly ooze optimism. So my ears perked up once again when human rights lawyer Simone George and Mark Pollock spoke about the dance between optimism and realism—or something else. “The realists have managed to resolve the tension between acceptance and hope by running them in parallel,” he said. Mr. Pollock had lost his vision at age 22, but was still running marathons around the world when he met Ms. George. After an accident left him paralyzed, the now-married couple went on a new quest, exploring the outer edges of spinal cord injury recovery with exoskeletons.

The final talk came from Ingrid Fetell Lee, who dug into the science behind joy. Sure, sometimes it’s just a superfluous extra driven by the inconsequential—ice cream cones, fireworks, bubbles—but Ms. Lee argues it helps create lifetime of happiness. “What we should be doing is embracing joy, and finding ways to put ourselves in the path of it more often.”

Check out more insights and info at PMI @ TEDSummit 2019 on 21-35 July in Edinburgh, Scotland and at the big PMI Global Conference on 5-7 October in Philadelphia, Pennsylvania, USA.

And see you at next year’s EMEA Congress, happening 4-6 May in Prague, Czech Republic. Brzy se uvidíme