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
Conrado Morlan
Kevin Korterud
Peter Tarhanidis
Vivek Prakash
Cyndee Miller
David Wakeman
Jen Skrabak
Mario Trentim
Shobhna Raghupathy
Roberto Toledo
Joanna Newman
Christian Bisson
Linda Agyapong
Soma Bhattacharya
Jess Tayel
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

Viewing Posts by Lynda Bourne

Follow These 3 Steps to Validate a Variance

By Lynda Bourne

As you may know, any monitoring and control process has three components. The first is establishing a baseline that you plan to achieve, the second is comparing actual progress to the plan to see if there are any differences, and the third is taking corrective or preventative action. Corrective actions fix existing problems, while preventative actions stop problems from occurring in the future.

This post looks at the middle phase. Before taking action to bring performance into alignment with the plan, make sure the variance you are seeing in the control systems is real. Corrective and preventative actions take time and usually involve costs, and there is no point in expending effort where it is not needed. 

The variance is the difference between two imprecise elements: the planned state and the actual situation. The plan is based on estimates and assumptions made some time ago about what may occur in the future. All plans and estimates have a degree of error built in; it is impossible to precisely predict the future of a complex system such as a project. Similarly, the measurement of the actual situation is prone to observational errors; key data may be missing or the situation misinterpreted.

So how do you decide if the measured variance is real and significant enough to warrant corrective action? I suggest considering the following:

1. Does the reported variance line up with your expectations?

2. Is the variance significant?

3. Is a solution viable?

Let’s explore these in depth.

 

Does the reported variance line up with your expectations?
If a cost report says there is a profit of US$10,000 in a work package where you expected to see a loss, there’s a high probability some of the actual costs have been missed. It’s likely either your expectations were misplaced or the measurements contain data errors. You need to resolve this question before moving on. When the variance and your expectations agree, you can be reasonably confident the information as measured is correct.

Try looking at a couple of different monitoring systems, such as cost and time. Do the two systems correlate, or are they giving you very different information on the same group of activities? If they correlate, perhaps your expectations are misplaced. If they are giving you different information, there may be data errors.

Is the variance significant?
Next, look at the significance of the difference. Point measurements are prone to error simply because you have to assume a lot. For example, you may be sure a 10-day activity has started, and equally sure it has not been completed. But if the work is about half done should you record it 40%, 50% or 60% compete?   

If the predicted slippage on the completion date for a key milestone over a series of reports is bouncing around, any single measurement within the noise factor is likely to be insignificant.

Trends, on the other hand, highlight issues. Sensible control systems have range statements that indicate the variance is too small to worry about if it is inside the allowed range. This general rule is modified to take trends seriously and to require action to correct negative variances close to a milestone or completion.

Is a solution viable?
This third question looks at viability. Can you take action to resolve the variance for a sensible cost? Some issues are simply outside your control, such as changes in the exchange rate. Risk planning and mitigation may have been able to minimize the issue in the past, but if you need the import this month, for example, you have no option but to pay the current price. 

Other situations are simply not worth the cost. There is no point in spending US$10,000 to correct a -US$5,000 variance. However, this decision has to take into account any effect on the client and your organization’s reputation. Cost overruns are generally internal, whereas late delivery and quality issues may have a significant reputational cost, affecting stakeholder perceptions.

Where a viable option exists to correct negative variances, corrective and preventative actions need to be planned, prioritized and implemented.  There is no point wasting time on a controls system that does not generate effective controlling actions.  

Closing Thoughts
I’ll leave you with two final thoughts. First, don’t forget about positive variances. Similar questions need to be asked in order to amend the plan to lock in gains. If your supplier is going to deliver some equipment three weeks ahead of schedule, can you reorganize the plan to make sure the installers are available three weeks sooner? If this is viable, make sure it happens in order to lock in a three-week gain. If you fail to take action, the installers will turn up on schedule and the gain generated by your supplier will be lost.

Second, implementing corrective and preventative actions requires the resources working on the project to do something different. Variances don’t correct themselves, and simply telling someone to catch up is unlikely to have any effect. Sensible management action, decisions and leadership are needed to physically change the situation so there is a correction in the way work is performed. This is a core skill of every effective manager.

I’d love to know: How do you deal with variances in your projects? Please share below.

Posted by Lynda Bourne on: August 23, 2019 04:55 PM | Permalink | Comments (9)

Beware the Dangers of Technical Debt

By Lynda Bourne

Have you ever experienced technical debt on a project? As the debt builds up, everything looks good from the outside. However, when the crunch comes and that debt has to be repaid, a major reversal in fortune can occur.

Technical debt refers to the costs of having to go back and resolve problems that arise because an earlier decision was made to take the easy route, instead of the best one. By taking the easy option, the team incurs a debt to the project that will have to be repaid later. While the concept comes from software development, this insidious effect can be seen across industries.

The Crossrail project in London offers a current, extreme example. In July 2018, it was reported that on-time and on-budget completion of the £14.8 billon rail project would occur in December 2018. By August 2018, completion had slipped by a year. Currently, the delay extends to the end of 2020, with a cost overrun of 20 percent.

What’s the main driver of this delay and associated costs?

It appears to be decisions made to ignore problems in the signaling system development. According to Construction Manager magazine, while giving evidence to a government inquiry, Crossrail’s new chief executive Simon Wright said, “We were testing on incomplete systems. Productivity was under stress, but we fought hard to maintain the schedule and thought all along that we could find a solution to bring it back, just like we have done on countless other problems that occurred during the construction program.”

This is a classic example of management decisions building up a technical debt. 

In 2015, The Independent newspaper reported that rail experts and engineers were having difficulty creating interfaces for the signaling systems. At the same inquiry, Crossrail’s new chairman Terry Morgan said “problems that emerged were mostly due to difficulties with developing software to allow Crossrail trains to travel safely at speed through three separate signalling systems,” according to Construction Manager magazine. The problem was identified in 2015 and hadn’t been resolved by 2019, despite time and money wasted testing incomplete systems. In fact, the irrelevant testing probably added to the delay and costs by distracting people from the real challenge.

Fixing the problem properly the first time would surely have caused a delay and cost blowout between 2016 and 2018. But in all likelihood, the costs would have been lower, the delay would have been shorter, and the current furor surrounding the project would have been minimized.  

The problem with technical debt is that often, the people who need to know about a problem aren’t informed. We will never know what the chair and CEO of Crossrail (both sacked) really knew in the 2016 to 2018 period, or what their senior managers knew about the build-up of the technical debt in the Crossrail signalling systems. But the problem could have been avoided, or at least minimized, if the technical debt had been acknowledged. If people are unaware of technical debt, then they’ll be more likely to identify paths that will result in it being created.

To avoid this lack of insight, everyone in the project group, especially team members, must be in a position to offer insight into technical debt.

The project manager can then choose to act, or not. Aware teams bring up the subject of technical debt in planning meetings, and they keep focused on it. Aware managers pose questions such as, “If this proposed shortcut is the right choice, what is there to gain, and what are the challenges and future implications?”

As with financial debt, there are times when going into debt can be beneficial, but only if you can pay back the accrued debt and interest at the right time.

How much technical debt is your project running? Please share your experiences below.

Posted by Lynda Bourne on: July 19, 2019 07:52 PM | Permalink | Comments (20)

6 Steps for Improving Organizational Maturity

Categories: Best Practices

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.

Posted by Lynda Bourne on: May 30, 2019 06:58 PM | Permalink | Comments (11)

Separating Standards and Knowledge Management

by Lynda Bourne

In my last post—It’s Time for a Long, Hard Look at Processes—I questioned if A Guide to the Project Management Body of Knowledge (PMBOK® Guide) should be updated every four years, or if it should become a dynamic knowledge management system similar to Wikipedia. The post generated a number of comments, which I’m going to try to address now.

The fundamental purpose of a standard is to offer standardized advice organizations can rely on. Standards are frequently referenced in contracts and other formal documentation, and they form the basis for certifications. The PMBOK® Guide fulfills all of these purposes. In this situation, stability is essential. Globally, standards are reviewed and updated every four to five years to balance the need for currency against the need for consistency. 

The PMI Registered Education Provider (R.E.P.) community has a busy few months each time the PMBOK® Guide is updated, requiring them to go through their training materials to bring them all up to date. This is magnified many times over as organizations around the world update their documentation to align with the new standard.

But the American National Standards Institute (ANSI) standard is only one part of the PMBOK® Guide. The guidance part is the larger aspect of the book and also, in my opinion, the most useful. This element is a knowledge repository and if access to validated information is readily available, knowledge management systems should seek to be as up to date as possible. To achieve this, most knowledge management systems are web-based and assume that once information is printed, it is no longer current. Managing a knowledge management system needs skill and knowledge but should be a real-time, full-time function.

Given this, I suggest that PMI separate the standard part of the document from the knowledge element. The standard section would consist of the ANSI Standard (part two of the current PMBOK® Guide) and the supporting core knowledge that does not change much. This standard and supporting information would remain on the four- to five-year update cycle. The resulting document would be much thinner than the current PMBOK® Guide.

The knowledge element builds onto this as a cloud-based resource and should be the subject of continual improvement and updating. Allowing PMI members to contribute their knowledge on a continuous basis, subject to review and edit, would allow the body of knowledge to grow and adapt as project management grows and adapts.

A careful design of the knowledge structure based on the PMBOK® Guide—augmented with information from the other standards published by PMI and enhanced with current developments from industry—would create a very useful and dynamic source of knowledge for the global project management community.

If access to this project management knowledge bank is free to members and available for a fee to commercial users and non-members, the value of membership would be enhanced and PMI would be positioned to maintain its position as a global leader in the development of project management.

It’s an interesting challenge. What do you think?

Posted by Lynda Bourne on: April 25, 2019 07:00 PM | Permalink | Comments (11)

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 (19)
ADVERTISEMENTS

"Forgive your enemies, but never forget their names."

- John F. Kennedy

ADVERTISEMENT

Sponsors