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
Joanna Newman
Christian Bisson
Linda Agyapong
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

4 Tips for Project Closing Parties

Project Planning Using Canvas

What Do the Great Thinkers Say About Change Management?

Combat Pushback—and Protect Your Portfolio

Free Your Team With Liberating Structures

Project Management for Business Transformation

Make it or break it!

In the world of Business Transformation (BT), project management plays a critical part in the successful delivery of the business transformation programs to an extend where I can say it is a “Make it or Break it”

And why is that?

Imagine a school music play and the effort required to coordinate everything to get it done successfully. Of course, there is a lot of planning, coordination and execution that goes into it to produce a high quality school play

Now imagine an orchestra and the effort required to get this done successfully. In essence and to the inexperienced eye, the tasks may be similar but the effort and complexity are just a different ball game altogether

This is the same thing when it comes to managing a non-BT project and a BT project. The main tasks of initiation, planning, execution, monitoring and closing may look the same on the surface but underneath the skeleton,  is a different level of complexity

Having said that, BT project management requires a different calibre of project managers to help get the beast out of the door while achieving business outcomes

To be on the same page, let’s define what business transformation is. Business transformation is a significant change that an organization goes through impacting its people, process and/or technology. The change is usually a complex one with long term business outcomes to be achieved   

Project management becomes the core part of delivering the business transformation and ensure that business outcomes are achieved. The calibre of the BT project manager is therefore a lot more complex and at a higher level of maturity. Below are the key characteristics for a successful business transformation project manager  

Exceptional Business Acumen

  • Ability to lose the jargon and speak to the business in their own language
  • Come from a place of wanting to understand what the business wants and needs
  • Makes no assumptions about what success looks like but instead co-create with it with the business
  • Understands the business vision and direction and how to best position the project to fulfil the business outcomes
  • Keep everyone accountable to achieving measurable business outcomes  

Visionary and can see beyond the short term goals

  • Able to mentally fast forward the current events to predict issues and resolve them early on
  • Proactively seek guidance and collaboration to ensure alignment
  • Understand the art of the unspoken word and the goal behind the goal
  • Able to manoeuvre and venture into the political landscape of the organization and foster relationship building

Can see different angles and prospective

  • Understand the business interdependencies, people impact and technology constraints
  • Able to see the logic in the various stakeholder groups’ points of view and make sense of them all to come to a well-rounded conclusion
  • Understand the different motives of the various levels in the organization i.e. executives, management and front liners

Diversified skill set

  • Having a diverse skill set is key in the success of BT project management. This allows the project manager to properly articulate what is required and most importantly see the missing links
  • Able to work better with the project team members coming from a land of similar experiences (not necessarily at the same level of depth)

Knows and understands failure

  • A project manager who have seen this, done that would have a higher level of exposure to different setups and problems which enriches their ability to problem solving
  • Have seen the good, the bad and the ugly means they can smell failure from a mile away and able to take action to set proper direction to avoid it or have the proper contingencies in place

Knows the job and acts beyond it

  • In the world of BT, project managers hardly have a job description to follow. For hiring purposes, yes they might have one but when doing the doing and working day-in day-out; they work on ensuring that the BT project is delivered successfully. This will take them beyond the scope of works to understand the wider environment of the project and resolve problems and issues that may “technically” be out of the project scope “the agreed baseline scope”
  • BT project manager does not say “Sorry, this is not my job!”

 

Posted by Jess Tayel on: January 31, 2019 06:44 AM | Permalink | Comments (13)

Debunking 4 Misconceptions About Story Points

Categories: Agile

by Christian Bisson, PMP


Story points, while an essential component of agile, are often misintrepeted.
And that’s a problem, as story points are are a vital unit of measure to help
estimate user stories. And stories, in turn, help teams plan their next sprint.
When they’re misinterpreted, story points lose their effectiveness, and they
can even hurt teams because of how they are used.

For the sake of my examples below, I assume teams use the Fibonacci sequence.
Let’s run through a few common misconceptions:


1. It’s about the complexity.

Some teams will mistakenly focus only on the complexity of the user story,
as measured by the required level of training it takes to complete a given
task. If a task is simple but time-consuming, they will assign it a “1.”
This is misguided because in addition to complexity, story points also take
into account effort and risks.

It’s important to factor in all three of these aspects of user stories to make a
proper estimate.

2. It’s about the business value.

Simply put: no.
When prioritizing their backlogs or even deciding to move forward with a
user story, it’s important for product owners to understand that story points
have nothing to do with business value.


A “13” could bring no value while being costly, and a “1” could be a golden
opportunity (a.k.a. a “quick win”).


Some Product Owners assign a “Business Value” to user stories (for example: A, B, C), although not mandatory, it can be used along with story points to help make key
decisions about priorities.

3. One point is one day of work.

Story points are not days, nor hours—they are a separate unit of measure. If
using “days” to estimate user stories works well for your team, then by all
means keep going, but call them days as opposed to story points to avoid
confusion.


4. Story points can be used to compare teams.

This one is a dangerous trap, especially if used by someone who can
influence people below him or her. It’s important to understand that story
points are relative to each person. Even within a team, it can be a challenge
to align initially until they have a few user stories to compare with.

A “5” can mean something different for Team A than for Team B, so
comparing each team’s velocity gives absolutely no value whatsoever. In
fact, it can mislead you into thinking one team is more efficient than
another, which in turn might result in unjustified negative feedback or
pressure to “have high velocity.”


In Summary

Story points are a tool, and like all tools, they’re only as good as how we use
them. If we fall into common trap, using our story points to plan our sprints
will lead us to disaster. It’s important that every member of the team
understands the concept, and that you also take the time to educate anyone
outside the team who has influence over your work, such as upper
management or customers.


Do you know of any other misconceptions around story points?

Posted by Christian Bisson on: January 26, 2019 01:44 PM | Permalink | Comments (12)

Do You Know The 3 Drivers Of Project Success?

by Dave Wakeman

I recently came across some of management guru Peter Drucker’s thoughts on project management. 

As often happens with Drucker’s writing, the lessons he wrote about many years ago are still applicable today. 

In his thinking about project management, Drucker came up with the idea that it really came down to three ideas: objectives, measurements and results. 

Let’s take each of these areas and think about how we should approach them today. 

Objectives: Many projects get stuck before they even begin, due to a poor framing of the project’s objectives. We should be undertaking our projects only when we have moved through the project-planning phase to such an extent that we have a strong grasp of what we are hoping to achieve. 

These objectives shouldn’t be fuzzy or wishy-washy. They should be solid and rooted in the overall strategy of the organization you are performing the project for. 

This means you have to ask the question: “Does this project move us toward our goals?”

If the answer is “yes,” it’s likely a project that should be launched.

If the answer is “no,” it’s likely a project that needs to be fleshed out more, rethought or not undertaken at all.          

Measurements: Drucker is famous for this adage: What gets measured gets managed. 

In thinking about project management, measurements aren’t just about being able to improve project delivery. They’re also essential to ensure the project is headed in the right direction. 

To effectively measure our projects, we need to have laid out key measurements alongside the project’s objectives. 

The measurements should be specific, with expected outputs and completion dates, so you can affirm whether you are on schedule, behind schedule or ahead of schedule. 

At the same time, the measurements should inform you of your progress as it compares to your strategic goals. 

Results: Ultimately, projects are about results. 

To paraphrase another great thinker, Nick Saban: If you focus on doing your job right on each play, you’ll put yourself in a position to be successful at achieving your goals.

Saban coaches U.S. football, but this works just as well for all of us in project management. 

If we are focusing our energy on tying our projects to our organization’s strategy, through this strategy we focus our project efforts on the correct objectives in line with our strategy. Then we use those objectives to measure our progress against the strategy. We should be putting ourselves in a position to get the results that we need from our projects. 

These results should be measured as positive outcomes. In Saban’s case, that’s wins. In your case, it might be a new technology solution, a successful new ad campaign or a profitable fundraising effort. 

To me, reviewing Drucker’s thoughts on project management is a reminder: Even though there is a constant pull of new technologies, never-ending demands on our attention and a world where change feels accelerated, sometimes the best course of action is to step back, slow down and get back to the basics.

 

Posted by David Wakeman on: January 18, 2019 10:02 AM | Permalink | Comments (13)

It’s Time for a Long, Hard Look at Processes

Categories: PMBOK Guide

by Lynda Bourne

Project managers and processes go hand in hand. But are the processes of the past the right ones to guide future projects? And if project management is evolving beyond today’s generally accepted 40 or 50 processes, what should the next version of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) look like?

 

The Evolution of Process as a Concept

To consider these questions, let’s start by looking at the way processes have evolved. The concept of describing the process needed to accomplish a task emerged as part of the development of scientific management in the early 20th century. Scientific study and careful analysis defined the “one best way” of doing the work and the time it needed. Shortly after, the application of learned experience entered into the equation as a way to improve the current “best method.”

By the 1950s the concept of a process with defined inputs, transformed by the application of defined tools and techniques to produce outputs, was firmly established in quality control and management. Process improvement was central to the rapid development of post-war industry.

During the development of the 1996 version of the PMBOK® Guide, PMI adopted processes as the best way to organize and explain the complex flow of information through the life of a typical project. The PMBOK® Guide came to embody “generally accepted good practices that apply to most projects, most of the time.” Over the years, the 37 processes in the 1996 version of the PMBOK® Guide expanded to 49 in the Sixth Edition (released in 2017). Through the editions, PMI has progressively increased the emphasis on the need to customize and tailor processes to meet the needs of each individual project. But is this enough?

 

Looking Ahead

The questions I want to ask in this post are:

  • Can a practice as diverse as project management still be adequately described in some 50 processes?
  • If not, how can the PMBOK® Guide be structured in the future?
  • Is a four-year cycle appropriate, or given the rate of change in the profession, should “the Guide” be updated more frequently?

In the past, processes were developed around the concept of transforming specific inputs in a defined way to create consistent outputs. Business processes define how the how work is done within an organization, to meet the needs of its customers. PMI’s approach to generalizing processes across a management discipline adapted this basic concept. 

The idea was powerfully successful when most projects, most of the time, had similar characteristics. They were approved, planned, built and closed. The same approach was used in construction, engineering and most other industries that did projects in the 1990s—and the concept remained largely true for the next 20 years or so.

However, does this generality still apply in the current environment, where some projects still follow the traditional approach (e.g., construction/engineering), others use various iterative approaches, while others take a fully adaptive and agile approach?

Some core objectives are consistent across of all of these approaches. For example, they all use some form of schedule management to get the right people into the right place at the right time, adequately resourced to do the right work. However, the processes applied to accomplish this objective have very little in common. For example, resources are allocated to logically constrained activities by the planner in traditional critical path method scheduling, in agile resources choose which activities to include in their next “sprint.” Similar challenges exist across most, if not all, of the knowledge areas. Has creating processes that can work across all of the different delivery strategies become impossible?

 

Focusing on the next edition

This brings me to the second question. What should the next edition of the PMBOK® Guide look like?

  • One option would be to significantly increase its size to include many of the alternative approaches as discrete processes.
  • Another may be to produce different versions of the PMBOK® Guide for different approaches to managing projects, expanding on the concept of “industry extensions” that already exist. This may result in a smaller “core document” people could complement by adding on the appropriate extension, or a series of books with a common frame but different processes.
  • A radically different approach would be to create some form of intelligent web-based tool that offers viable combinations of processes across different knowledge areas based on previous decisions.

As our profession rapidly changes and diversifies, it remains central to the development of the world’s economy. So how do you think the PMBOK® Guide can best evolve to maintain its preeminent position as the global reference defining the management of projects?

Your answers will help inform my next post looking at managing the accelerating rate of change in our profession. 

Posted by Lynda Bourne on: January 15, 2019 04:08 PM | Permalink | Comments (17)

Trust: The Secret Ingredient to Project Success

By Marian Haus, PMP

Trust is defined as a “firm belief in the reliability, truth, ability or strength of someone or something.”

Isn’t that what we all want in our professional and private lives?

Imagine a project with little or no trust between the project manager, team members and stakeholders. In such an environment, communication is opaque and piecemeal, and what’s communicated to you depends on your position in the organization. Silos are built to protect individuals, positions and knowledge. As for assignments, they’re meticulously planned and controlled, and work is delegated and rigorously followed up on.

I could go on and on.

Without trust, companies won’t survive for long in today’s world of VUCA (volatility, uncertainty, complexity and ambiguity). Without trust, for example, how can you as a project manager quickly respond to constantly changing customer expectations and environmental conditions?

The absence of trust is at the basis of the pyramid of The Five Dysfunctions of a Team by business consultant and speaker Patrick Lencioni. According to this model, conflicts cannot be solved creatively without trust. The lack of trust erodes people’s commitment, engagement and accountability—and therefore makes it difficult to attain goals and results.

I believe the evolution of project management over the past two decades is due in large part to the way trust is now valued in projects and in business. It’s an enabler for individual and organizational success. People are more empowered than ever to work independently (i.e., with no micromanagement) and to collaborate in trustworthy environments.

Companies that understand this have trust as a core value of their corporate culture and part of their corporate DNA. Leaders, project managers and employees of these organizations are not struggling to gain the trust of their peers. They are benefitting from and supporting the implementation of cultural changes based on trust, openness and fair collaboration.

How can project managers lead by example and work to create a trustworthy project environment? Here are some tips:

  • Take time for giving and building trust, instead of expecting it unconditionally.
  • Treat yourself and others with respect. People will notice this—and follow suit.
  • Communicate clearly and openly, without a hidden agenda.
  • Be direct, fair and predictable.
  • Stay in front of your team and protect them when facing adversities. This will show them they can rely on you.
  • Delegate not only work and responsibility, but also accountability. This increases engagement and trust.
  • Stay behind your team and back it when mistakes occur. Tolerate and admit mistakes. This strengthens trust and promotes learning and innovation.
  • Empower your team with the right tools to increase collaboration and share knowledge. This will break silos and improve the work climate.
  • If possible, get the team collocated (i.e., located in the same physical space). This will increase direct interactions between individuals and keep people from hiding behind processes or tools. Ultimately this will increase the team’s efficiency.

By behaving in a trustworthy manner and leading by example, you’ll gain your team’s confidence. People will rely and count on you in any circumstance.

How do you drive trust in your projects and organization?

 

Posted by Marian Haus on: December 24, 2018 03:47 AM | Permalink | Comments (24)
ADVERTISEMENTS

"Few things are harder to put up with than the annoyance of a good example."

- Mark Twain

ADVERTISEMENT

Sponsors