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
Joanna Newman
Christian Bisson
Linda Agyapong
Soma Bhattacharya
Cyndee Miller
Jess Tayel
Shobhna Raghupathy
Rex Holmlin
Ramiro Rodrigues
Taralyn Frasqueri-Molina
Wanda Curlee

Past Contributers:

Jorge Valdés Garciatorres
Hajar Hamid
Dan Goldfischer
Saira Karim
Jim De Piante
sanjay saini
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Alfonso Bucero
Kelley Hunsberger
William Krebs
Peter Taylor
Rebecca Braglio
Geoff Mattie
Dmitri Ivanenko PMP ITIL

Recent Posts

Lessons Learned From an Inspiring AI Project

The Project Initiatives That Influenced My Career

Seek Better Questions, Not Answers

A Home for Transformation: Lessons From Fannie Mae’s PMO

Indulge Your Audacious Curiosity—Even if It Means Failing

Lessons Learned From an Inspiring AI Project

By Christian Bisson

When I was asked to write about a project that inspired me in the last 50 years, I didn’t have to look back further than last year. That’s when I had the chance to act as scrum master for a newly formed team.

The Challenge

We had seven weeks to build software from scratch that would be demonstrated at a conference and used by hundreds of people. Since the conference was centered on artificial intelligence, it was mandatory that our demo used AI. Our idea was a game where the player spelled words using real sign language. The game was displayed on a television hooked up to a camera, which filmed the player’s hand.

The hand’s position was then recognized and matched to a letter of the alphabet. The player received points based on the speed at which he was spelling the words displayed on the screen.

The Team

We had a great team composed of two developers, a designer, two AI researchers, a product owner and me (scrum master). Our small, dedicated team would empower us to deliver the software we needed to build from A to Z.

Although concerned about the short time available, everyone was motivated and excited to build this amazing software, knowing the visibility it would get.

How We Would Work

Since the scope wasn’t fully defined and the user experience was key, we needed to deliver usable increments to test. We needed a framework that would allow us to deliver quickly and adjust to the requirements as they were refined. Scrum was the obvious choice, even though most of the team was completely new to it. The majority of the team came from a software background, so they knew what it was on paper. However, for the AI researchers, it was completely unknown.

Where it All Came Together

Many start off with the team they need, but then obstacles come their way and prevent them from moving forward. These could be anything from unavailable stakeholders to people being pulled off the team to poor requirements.

However, in this case, it was everything you would want from agility/scrum:

  • A team collaborating together without anyone coordinating them
  • Busy stakeholders making themselves available for us to collaborate
  • Everyone following scrum, even though it was new to them
  • The team working at a sustainable pace
  • A usable increment of the game delivered every sprint
  • Continuous improvement through the retrospectives
  • A healthy backlog that was properly refined by the team

It was amazing to see the collaboration when we needed users to test; after a quick Slack message to everyone in the company, we would suddenly have a lineup of people available to play the game.

 

What Inspired Me

When I think back on our success, all I remember are the people working together to create something great. It wasn’t even about being “agile.” For the team it was, “Let’s get this done!” and for everyone who supported us, it was “Let’s help our colleagues!” There was nothing more, nothing less—exactly how it should be.

 

I’d love to hear about the most inspiring project you’ve worked on in your career. Please share below!

Posted by Christian Bisson on: November 13, 2019 03:13 PM | Permalink | Comments (1)

Unlock the Value of Artificial Intelligence

By Peter Tarhanidis

Artificial intelligence is no longer a tool we’ll use on projects in the future. Right now, many organizations are formalizing the use of advanced data analytics from innovative technologies, algorithms and AI visualization techniques into strategic projects.

The maturity of advanced data analytics is creating an opportunity for organizations to unlock value. The McKinsey Global Institute estimates AI’s global economic impact could climb to US$13 trillion by 2030.

As an example, in the healthcare industry, Allied Market Research reports rising demand for data analytics solutions due to the growth in data from electronic health records, among other factors. The global healthcare analytics market was valued at US$16.9 billion in 2017, and the report forecasts it to reach US$67.8 billion by 2025.

The Evolution of AI Maturity
Gartner describes four growth stages of analytics and value activities. The first is descriptive analytics, which gains insight from historical data on what occurred in the firm or a project. This includes key performance measure reports and dashboards. Second, diagnostics analytics allow you to learn why something happened and the relationship between events. Third, is the use of predictive analytics to develop viewpoints into potential future outcomes. Finally, prescriptive analytics allow you to provide users with advice on what actions to take.

Everyday examples of these solutions range from simple automated dashboards, remote check deposit, Siri-like assistants, ride-sharing apps, Facebook, Instagram, autopilot and autonomous cars.  

Tips on Successful Transformation
Leaders must consider advanced data analytics as a transformational journey—not a complex project. Without thoughtful consideration of the implications of managing AI projects, one may create chaos in adopting these new services.

As a project leader, take these steps to avoid key pitfalls:

  1. Develop your understanding of data science tool kits and technologies and identify any centers of excellence. Start with basics such as descriptive statistics, regression and optimization techniques. You’ll also want to familiarize yourself with technology such as machine learning and natural language processing.
  2. Determine how these AI initiatives integrate into the organization’s mission and vision. This may require a new strategic business plan, optimizing an organization, culture change and change management.
  3. Establish a data governance body and framework to ensure accountability, roles, security, legislative and ethical management of consumer, patient, customer and government data.
  4. Develop strong multiyear business cases that clearly indicate cost versus revenue or savings.
  5. Maintain an agile mindset and leverage design thinking methods to co-create the pilots into products alongside stakeholders.

Please comment below on what approaches you have taken to enable advanced data analytics in your role or in your organization.

Posted by Peter Tarhanidis on: August 12, 2019 01:25 PM | Permalink | Comments (13)

Put Your Users First—Here’s How

by Christian Bisson, PMP, PSPO, PSM

In agile, users are everything. So it only makes sense that users—anyone who will use or interact with your product—should be a team’s main focus. In order for the product to be viable, whatever is produced must bring them value.

But it’s perhaps too easy to forget users when you build your backlog. We often jump too quickly to features, assuming “the users will use this.” But what if we took a step back? Consider taking the following steps:

Identify Your Target Audience

First, for whom is this product intended? Identifying a target audience will help you determine who you’re building for.

For example, if you expect users who aren’t tech-savvy, then you need to be mindful of how complex the interface or even the wording are throughout.

It’s important to describe these users. One common practice is to create “personas,” which are fictional characters that represent the users. These will help you better understand your audience.

Understand Their Goals

Now that we know our audience, what are they trying to achieve? Instead of jumping from personas to features, stop and think about their goals.

Are they trying to purchase something online? Are they trying to fetch information? Are they trying to plan a trip? The answers to these questions will shape your direction.

Predict Their Path Forward

We know who is trying to achieve what. The next key step is to define “how” the users are going to achieve their goals.

Let’s assume the user wants to purchase a toy. That user will most likely need to:

  • Search to find toys
  • Be able to view the toys
  • Add a toy to a cart
  • Make the official purchase

Let’s keep it simple. We can extrapolate that this user might be interested in items related to this item, or many other scenarios, but for now, the above is our user’s steps.

Once this is clearly defined, it is much simpler for:

  • Our product owner to create user stories clearly stating what the user needs and for what: “As a customer, I want to search for products by categories so I can more easily find what I am looking for.”
  • Our development team to understand why this (these) features matter, and how we’ll architect them, because we understand why we are doing it.

Keep Users Top of Mind

I’ve seen too many teams skip these important steps. Often, people are so quick to execute what is instructed by managers, or by assumptions from the team, that they forget to think about who they are building the product for. The user, of course, will ultimately decide the product’s success. That’s why it’s so important that our product brings value to users.

What do you do to focus on users? How do you verify if you are bringing value to them? Share!

Posted by Christian Bisson on: June 19, 2019 09:36 PM | Permalink | Comments (6)

3 Ways to Balance The Delivery Ecosystem

 

 

 

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.  

 

  1. 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?

 

Posted by Kevin Korterud on: June 08, 2019 04:20 PM | Permalink | Comments (7)

Debunking Six Misconceptions About Agile

Categories: Agile

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. 

 

  1. 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.

 

  1. 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.  

 

  1. 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.   

 

  1. 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. 

 

  1. 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?

Posted by Soma Bhattacharya on: May 24, 2019 12:48 PM | Permalink | Comments (11)
ADVERTISEMENTS

ADVERTISEMENT

Sponsors