Voices on Project Management

As a project manager, there’s perhaps nothing better than starting a new project. With it comes a fresh start and the promise of a successful conclusion. To me, it’s akin to starting a new year in school with new notebooks, where nothing has been written to spoil the fresh sheets of paper.

However, as we become more experienced as project managers, we’re called on more and more to assume control of a project already in motion. This might be triggered by a happy event, such as a promotion for the existing project manager, or a less-than-happy situation, such as a lack of progress on the project.

Assuming responsibility for a project that has already launched is a lot different than starting from the beginning. You won’t have the benefit of starting with a clean sheet of paper, and there will be things you need to do—and undo.

Here are three tips I always follow when assuming control of an existing project:

1. Assume Nothing    

When starting a new project, you have the opportunity to perform mobilization and initiation activities to effectively set the project on a path to success. In addition, there are some early checkpoints where you can perform structured control actions to further assure the proper trajectory of the project.  

While the existing project status reports can show the assumed disposition of a project, they may not reveal essential missing activities needed for project success. For example, an existing project might not have had the benefit of a thorough mobilization and initiation effort to properly set its course. In addition, there may be hidden or under-mitigated risks, emerging issues, stakeholder challenges and hidden dependencies that have not yet come to light. 

When taking over an existing project, the first thing I do is review it in the same way I would a new project. Introducing a pause in project activities to perform a “soft reset” allows both confirmation of assumptions and validation of project progress.

In addition, this activity can reveal unseen factors that put the current project position in doubt. This is a good time to reforecast the remaining work. By assuming nothing about the project, the “soft reset” serves as a basis to properly transition the project towards success.

2. Match the Team to the Realistic Remaining Work  

One of the most important facets of a soft reset is reforecasting the amount of remaining work. Use the existing forecast as a foundation for considering other factors that may influence the future progress of the project. These may include effort, scheduling conflicts (e.g., year-end holidays), upcoming business process changes and technology-readiness dependencies. 

From the reforecast, compare these factors against the capacity and capabilities of the existing project team. Review whether you have the requisite skills and team members available for each phase of the project. In addition, consider the availability of key resources who cannot be readily substituted in case they are not able to work on the project. This examination of project resources by phase should include not only individual team members, but also team leads and third-party suppliers.

3. Engage More Frequently With the Most Accountable Stakeholder

While there are many inorganic components of a project, such as deliverables and status reports, often the most critical components revolve around the organic nature of people. Having strong executive sponsorship, a structured governance engagement model and open communication all enable project success.

When you are introduced as the new project manager on an existing effort, some change management work will need to be done to ensure a smooth transition.

Given the myriad stakeholders involved in a project, who should you start with? The typical consideration is to start with the most senior leadership stakeholder, who is typically also the project sponsor.

I think, however, a better place to start is with the most accountable stakeholder. This would be the person who after the project is implemented would manage the new solution to achieve the project objectives. In addition, this person would likely have the greatest knowledge of requirements and implementation considerations, which would be valuable to your soft reset.

Set Your Team Up for Success
When airline pilots transfer control of an aircraft to another pilot, they go through a structured process. Before control is transferred, the flying pilot does a check of instruments, course and speed. The pilot currently flying and the pilot taking over the controls exchange a distinct exchange of commands to ensure a precise transition and a safe flight.  

Assuming control of an existing project should have that same level of attention to detail and precision. Now that you are leading this existing project, be sure to consider the factors shared above that confidently allow you to say, “I have the controls.”

When assuming existing projects, what sort of activities do you perform as part of a transition? I’d welcome other thoughts to help make us all better project managers.

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!”

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?

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.

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 20^th 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.