Project Management

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
Lynda Bourne
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Wanda Curlee
Christian Bisson
Ramiro Rodrigues
Soma Bhattacharya
Emily Luijbregts
Sree Rao
Yasmina Khelifi
Marat Oyvetsky
Lenka Pincot
Jorge Martin Valdes Garciatorres
cyndee miller

Past Contributors:

Rex Holmlin
Vivek Prakash
Dan Goldfischer
Linda Agyapong
Jim De Piante
Siti Hajar Abdul Hamid
Bernadine Douglas
Michael Hatfield
Deanna Landers
Kelley Hunsberger
Taralyn Frasqueri-Molina
Alfonso Bucero Torres
Marian Haus
Shobhna Raghupathy
Peter Taylor
Joanna Newman
Saira Karim
Jess Tayel
Lung-Hung Chou
Rebecca Braglio
Roberto Toledo
Geoff Mattie

Recent Posts

3 Agile Disconnects We Need to Address

What to Expect: Anticipating and Adapting to Dynamic Economic Trends

Governance Models: The Secret to Successful Agile Projects

3 Valuable PM Lessons I Learned in 2023

The 4 P’s of Successful Modern PMs

Categories

2020, Adult Development, Agile, Agile, Agile, agile, Agile management, Agile management, Agile;Community;Talent management, Artificial Intelligence, Backlog, Basics, Benefits Realization, Best Practices, BIM, Business Analysis, Business Analysis, Business Case, Business Transformation, Calculating Project Value, Canvas, Career Development, Career Development, Categories: Career Help, Change Management, Cloud Computing, Collaboration, Communication, Complexity, Conflict, Conflict Management, Consulting, Continuous Learning, Cost, COVID-19, Crises, Crisis Management, critical success factors, Cultural Awareness, Culture, Decision Making, Design Thinking, Digital Transformation, digital transformation, Digitalisation, Disruption, Diversity, Documentation, Earned Value Management, Education, EEWH, Enterprise Risk Management, Escalation management, Estimating, Ethics, execution, Expectations Management, Facilitation, feasibility studies, Future, Future of Project Management, Generational PM, Governance, Government, green building, Growth, Horizontal Development, Human Aspects of PM, Human Resources, Inclusion, Innovation, Intelligent Building, International, Internet of Things (IOT), Internet of Things (IoT), IOT, IT Project Management, IT Strategy, Knowledge, Leadership, lean construction, LEED, Lessons Learned, Lessons learned;Retrospective, Managing for Stakeholders, managing stakeholders as clients, Mentoring, Methodology, Metrics, Micromanagement, Microsoft Project PPM, Motivation, Negotiation, Neuroscience, neuroscience, New Practitioners, Nontraditional Project Management, OKR, Online Learning, opportunity, Organizational Project Management, Pandemic, People, People management, Planing, planning, PM & the Economy, PM History, PM Think About It, PMBOK Guide, PMI, PMI EMEA 2018, PMI EMEA Congress 2017, PMI EMEA Congress 2019, PMI Global Conference 2017, PMI Global Conference 2018, PMI Global Conference 2019, PMI Global Congress 2010 - North America, PMI Global Congress 2011 - EMEA, PMI Global Congress 2011 - North America, PMI Global Congress 2012 - EMEA, PMI Global Congress 2012 - North America, PMI Global Congress 2013 - EMEA, PMI Global Congress 2013 - North America, PMI Global Congress 2014 - EMEA, PMI Global Congress 2014 - North America, PMI GLobal Congress EMEA 2018, PMI PMO Symposium 2012, PMI PMO Symposium 2013, PMI PMO Symposium 2015, PMI PMO Symposium 2016, PMI PMO Symposium 2017, PMI PMO Symposium 2018, PMI Pulse of the Profession, PMO, pmo, PMO Project Management Office, portfolio, Portfolio Management, portfolio management, Portfolios (PPM), presentations, Priorities, Probability, Problem Structuring Methods, Process, Procurement, profess, Program Management, Programs (PMO), project, Project Delivery, Project Dependencies, Project Failure, project failure, Project Leadership, Project Management, project management, project management office, Project Planning, project planning, Project Requirements, Project Success, Ransomware, Reflections on the PM Life, Remote, Remote Work, Requirements Management, Research Conference 2010, Researching the Value of Project Management, Resiliency, Risk, Risk Management, Risk management, risk management, ROI, Roundtable, Salary Survey, Scheduling, Scope, Scrum, search, SelfLeadership, Servant Leadership, Sharing Knowledge, Social Responsibility, Sponsorship, Stakeholder, Stakeholder Management, stakeholder management, Strategy, swot, Talent Management, Talent Management Leadership SelfLeadership Collaboration Communication, Taskforce, Team Building, Teams, Teams in Agile, Teams in Agile, teamwork, Tech, Technical Debt, Technology, TED Talks, The Project Economy, Time, Timeline, Tools, tools, Transformation, transformation, Transition, Trust, Value, Vertical Development, Volunteering, Volunteering #Leadership #SelfLeadership, Volunteering Sharing Knowledge Leadership SelfLeadership Collaboration Trust, VUCA, Women in PM, Women in Project Management

Date

Do Modern PMs Rely on Charts Too Much?

By Lynda Bourne

Ptolemy's world map (source: Wikipedia)

Do modern project managers and their clients rely on their charts and reports too much? We all know that project schedules, cost reports, risk assessments and other reports are produced by sophisticated computer software, these days increasingly enhanced by artificial intelligence. But does this sophisticated processing mean the charts are completely reliable?

The modern world is increasingly reliant on computer systems to direct and control many aspects of life—from self-driving cars, to autonomous warehouses, to the flight control systems in aircraft. But can this reliance on computer systems be translated to project controls information, or do we need a more ancient mindset?

Modern navigators rely on the accuracy of their GPS to know exactly where they are and where they are going. The autopilots are better than the human, but the data being used is precise and validated.

The same level of reliability and accuracy cannot be applied to project controls data. Every estimate is an assessment of what may occur in the future based on what happened in the past. Even when a sophisticated risk model is built, the P80 or P90 result is based on subjective range estimates taken from past events.

The future may unfold within the expected parameters, and it may not. We simply cannot determine the future in advance. While the quality of the project predictions is based on the quality of the data being used in the modelling processes (and the only guaranteed fact is the model will be incorrect), predictions do not control the future. The key question is: How useful are the models in helping navigate the project through to a successful conclusion? [Remember GIGO (garbage in, garbage out)?!]

In days gone by, navigators did not need accurate charts and satnav systems to reach their destinations. The Viking and Polynesian navigators crossed thousands of miles of open ocean to land on small islands using observations of the natural environment and tacit knowledge passed down from earlier generations. They knew certain seabird species only ventured relatively short distances from land, how clouds formed and changed over land, etc., augmented by primitive technologies.

Fast-forward a few centuries, and the early European navigators (Columbus, Magellan, Drake, Cook and countless others) had steadily improving charts that made navigating easier—but they also knew the best charts available were not accurate. The general shape of the world had been mapped since the time of Ptolemy (circa 150 CE), and as better information became available, better maps and charts were created. But these are still continuing to be improved into the 21st century.

So how did people navigate the globe without accurate maps and charts? I suggest there were four core elements in the approach, all of which can be applied to modern project management:

  1. Recognize the chart is a guide, get the best possible chart available and use it to plan your course—taking into account as much additional information and tacit knowledge you can access.
  2. Then, assume the chart is incorrect. Keep a sharp look out for unexpected issues and dangers, adjust course as needed, and keep collecting information along the way. You only run into the rocks you do not see!
  3. Keep adapting and adjusting your course to make the best of the current circumstances, using both known and emerging information—the destination does not change, but how you get there may.
  4. Then use the new information you have gathered to update the chart to benefit future voyages in the same direction.

To move from assuming controls information is correct, to seeing it as a useful guide that can be improved as better knowledge becomes available, requires a paradigm shift in thinking that sits comfortably alongside many of the concepts of agile.

The future is inherently uncertain and we can learn a lot from the way early navigators used imprecise charts to sail the oceans. Navigating the globe in past centuries and leading a project to a successful conclusion are both risky endeavours; this fact needs to be accepted, and the risks minimized by using the best available charts—while being aware of their limitations.

What do you think?

Posted by Lynda Bourne on: September 14, 2023 09:52 PM | Permalink | Comments (9)

The Differences Between Feasibility Studies and Business Cases

By Mario Trentim

Before any organization undertakes a new project or initiative, it is essential to first assess the feasibility of that venture. This is done through feasibility studies and business cases:

  • A feasibility study looks at the technical feasibility, financial feasibility and operational viability of a proposed project.
  • A business case looks at the financials of a new venture to determine if it is financially viable.

Both are essential for any organization looking to undertake new projects or initiatives. Let’s look at these more in-depth:

Technical Feasibility Studies
The most common type of feasibility study is the technical feasibly study. Technical feasibility looks at whether a proposed project is achievable from a technical standpoint. This includes assessing the skills and knowledge required to execute the project, as well as the availability of resources. Once all this data has been collected, it is analyzed to determine if the project is technically feasible. If it is, then the next step is to develop a detailed plan and budget for how it will be executed.

Financial Feasibility Studies
Financial feasibility studies assess whether a proposed project is financially viable. To create a solid business case, organizations need to identify the problem or opportunity that the project will address and gather data to understand potential impact. This data can come from surveys, focus groups, interviews and other research methods. Once all the data has been collected, it is analyzed to determine if the project is worth pursuing from a financial standpoint. If it is, then the next step is to develop a detailed plan and budget for how it will be executed.

Operational Viability Studies
Operational viability studies assess whether a proposed project is operationally viable. This includes assessing the skills and knowledge required to execute the project, as well as the availability of resources. Once all this data has been collected, it is analyzed to determine if the project is operationally viable. If it is, then the next step is to develop a detailed plan and budget for how it will be executed.

Business Case
The business case is a document that allows decision makers to determine whether the project is worth the investment. It is essential to project selection, prioritization and authorization as part of a portfolio. The business case usually presents a current business problem and suggests alternatives to solve it. The basic purpose of this document is to justify the initiation of a project. 

In summary, here are the key differences:

  • Feasibility Study
    • Is it viable to intake this project?
    • Analyzes whether a project is executable or not.
    • Prevents undertaking projects that are unfeasible or extremely risky.
  • Business Case
    • Why is the project worth the investment?
    • Describes costs and benefits
    • Identifies the current situation (justification)
    • Defines the desired future state (solution)

Conclusion
Feasibility studies and business cases are important tools that organizations use to assess the viability of new projects or initiatives. Conducting these studies helps organizations make informed decisions about whether or not to pursue new ventures and allows them to plan accordingly so that they can set themselves up for success.

Posted by Mario Trentim on: December 01, 2022 10:08 AM | Permalink | Comments (4)

The Planning Paradox

By Lynda Bourne

How much detail is too much? Traditional views tend to favour a management approach built on the assumption more detail is better, and to a point this is undoubtedly correct, insufficient detail in a plan of any type is a sure way to fail – ‘just-do-it’ at the overall project level does not help.

But looking at the ‘Coastline Paradox’ and using the length of a coastline as a synonym for the duration of a project suggests there is a point where too much detail is counterproductive.

The coastline paradox states that as you increase the detail by using smaller units of measure, the measured length of the coastline increases. If you use a small enough unit of measure, the length becomes infinite. For a more detailed explanation see: The Coastline Paradox Explained  https://en.wikipedia.org/wiki/Coastline_paradox

So, what does this mean for project controls and project management?  No one navigating a ship into a UK port would be happy using a map where the smallest measurement was 50 km, significantly more detail is needed, but they do not need absolutely everything about their intended destination. What’s needed is useful information at an appropriate level of detail, the same goes for you, when navigating your car in a strange city[1]:

Finessing project plans to present useful information at the right level of detail is not easy, decisions have to be made! 

Take a typical risk register, if you tried listing every conceivable risk, the document would emulate the ‘coastline paradox’, and be of almost infinite length, which means the register is never finished and the project does not start.  Conversely, miss one or two significant risks and the project team may have a very unpleasant experience, possibly causing the project to fail. Pragmatic guidelines about the risks to be considered are needed and these have to be tailored to the project.  Similar guidelines are needed for the schedule, cost plan and all of the other sub-plans needed for a project.

How much detail do you feel is appropriate for your projects?

[1]  Image source: Understanding Design, The challenge of informed consent. Dr. Lynda Bourne, 27th November 2014; maps of North Sydney

Posted by Lynda Bourne on: September 06, 2021 01:04 AM | Permalink | Comments (10)

How To Succeed At Deliverable Scheduling

By Kevin Korterud

 

When I first started as a technology project manager, it was not uncommon for a project to have just one deliverable. All of the tasks in the project created the path that led to the single deliverable, which in many cases was a program, report or screen. Life used to be so easy!

As projects became more complex, the need grew for multiple project deliverables that lead to a complete solution. Deliverables now represent the “building blocks” that form a key foundational element of any project.

Whereas scheduling tasks is a fairly straightforward process that involves capturing durations, resources and successor/predecessor networks, scheduling deliverables comes with its own set of complexities. Deliverables don’t always behave in a linear manner like tasks­—so special considerations come into play with their scheduling. In addition, there are typically people and expectation factors that need to be part of a deliverable scheduling model.

Here are three essential reminders for properly scheduling deliverables:   

  1. Deliverables Involve a Package of Tasks

Whereas tasks are singular items that stand alone in a work plan, deliverables have a few extra packaging steps in their path to completion.

One of the most dangerous scheduling mistakes to make with deliverables is to have a single task in a work plan that represents the deliverable. This is because of the variation in duration and effort that it takes to complete a deliverable.

Deliverables have a natural path to completion that involves a package of tasks, whose dynamics differ from normal tasks in a work plan. Project managers need to include these extra tasks that chart the lifecycle of a deliverable from initiation to completion.

For example, a sample set of deliverable task packaging would appear as follows:

 

Deliverable Task

Duration

Resource(s)

Build

Estimated effort and duration required to design and construct the deliverable

Team members assigned to construct the deliverable

Review

Based on a fixed number of reviewers sufficient to validate the quality of the deliverable; this can vary by deliverable type 

Finite set of reviews with a reviewer lead

Revisions

Expected effort and duration for revisions, based on the level of new content not yet seen by reviewers

Team members assigned to construct the deliverable who work with the reviewer lead on refinements

Approval

1-2 hour overview of deliverable content

Presented by the deliverable reviewer lead

 

You can tell from the above table that prior to scheduling deliverable task packages, project managers need to have a deliverable governance process in place. A deliverable governance process that identifies specific deliverable reviewers and a single approver are key to the effective scheduling of deliverables.

 

2. Deliverables May Require Task-like Linkages

We are all familiar with creating predecessor or successor linkages between tasks to form a linear series of work needed to achieve an outcome. Those linkages serve to drive schedule changes as prevailing project conditions occur.

Deliverables can require the same sort of linkages found in tasks. For example, if you have deliverables that lead to the creation of a marketing web page that involves multiple supplier deliverables, selected tasks in the deliverable package can contain task linkages. These linkages impose conditions which determine the pace at which related deliverables can be completed.

Let’s say there are three design documents from different suppliers required to create an overall design document. The build of the overall design document cannot finish before those three supplier design documents are all approved. So in the work plan, delays and schedule movements in the supplier design deliverables will drive the true completion date of the overall design document.

 

  1. Resource Availability Impacts Deliverables

In addition to the scenario of having deliverables with dependencies, it is just as likely to have a set of deliverables that do not have any dependencies at all. These deliverables need to be completed by the end of the project but do not directly figure into the final outcome of the project. These are often process improvement deliverables that are needed for future projects that are not ready for execution.

When a project manager has a slate of unrelated deliverables, the optimal approach is to bundle them into agile-like sprints. The content of each deliverable sprint is determined by a balance of resource availability for the people who build, review and approve deliverables, as well as any form of relative priority. For example, if deliverable reviewers have low availability during a scheduled deliverable sprint, those deliverables can be pushed to a subsequent deliverable sprint.

Priority can also determine the content of deliverable sprints. Higher priority deliverables would displace lower priority deliverables to future sprints, even if work has begun on those deliverables. For example, if there is a strong need for a certain tool to be used by multiple projects, those deliverables would move into the current deliverable sprint. The deliverable sprint process allows for agility, while balancing value created from the deliverables.

 

As I shared earlier, life was so much easier when projects created one deliverable. Different times demand different approaches to managing deliverable schedules—especially on large transformations where there could be hundreds of dependent and independent deliverables. The last thing anyone wants to do is insufficiently manage deliverables: Leaving out one of those “building blocks” might cause the house to fall over.

What tips do you have for deliverable scheduling in today’s project ecosystem? Share your thoughts in the comments below.

 

Posted by Kevin Korterud on: March 03, 2020 03:09 PM | Permalink | Comments (4)

Predicting the Future in Project Management

By Ramiro Rodrigues

 

In the 2009 film Knowing, a boy finds a time capsule filled with documents from decades ago. His father, an astrophysics professor, then discovers that the messages list some recent and impending major disasters, and even predict a global calamity in the near future.

 

Apocalyptic visions of an imminent end to the world have always brought joy to the film industry—but they bump into the same logical limitations that are still impossible to overcome. As far as we know, we do not have an effective technology capable of predicting the future. Whether it is related to weather forecasting, economics or sociology, we are not able to tell, at present, precisely what will happen at a specific moment in the future.

 

What we have always had is a great will to take a chance and get it right. Since the beginning of time, man has ventured to predict the future and, during these attempts, we’ve come up with an ocean of predictions that have been proven wrong. But we don't give up.

 

A New Model of Scheduling

 

In today’s organizations, modern project management has to meet the need for schedule development that seeks, in a deterministic fashion, to set the estimated dates of future events related to people, project deliveries and work that will be executed. This usually is a great Achilles' heel in the field of project management. The organizational frustration that results from estimated scheduled activities that turn out to be incorrect is very common.

 

Why don’t they happen as expected? There are different reasons, usually related to people and intrinsic characteristics of the expected activities. But in essence, they happen because it still is impossible to predict the future. Of course, there are some strategies that can help mitigate the risks of the deterministic forecast, but in the end, they are only predictions.

 

However, we must understand that organizations need to estimate when the returns on their investments will be accessible for use. Some executives will say that there is no progress without clear and foreseen goals.

 

That’s right. But how do we get out of this complex scenario in which future dates are determined but do not happen as planned?

 

One trend that has been applied by industries such as consulting, engineering and research & development is the probabilistic forecast of schedules. In this case, with the assistance of simple statistical concepts, the forecasts of the activities and of the project are viewed as a whole, with probability ranges to conclude them.

 

It is not solely a mathematical solution; the change is conceptual. The idea is no longer to set, within the organization, the delivery estimates at certain dates grounded on the expectation that they will come true. Rather, the goal is to present length ranges that provide the company with a perspective that there is, for instance, a 68 percent, 95 percent or 99.7 percent chance that the project delivery will take place during the expected dates.

 

This change in principle allows for the understanding that one can never be 100 percent sure of what will happen in the future but, at the same time, enables the management of the risks involved with reasonable control.

 

This planning model can bring, in the near future, more maturity and quality to the management of schedules and deliveries.

 

Do you use this model in your organization? Share your thoughts below. 

Posted by Ramiro Rodrigues on: February 26, 2020 12:14 PM | Permalink | Comments (3)
ADVERTISEMENTS

"I never thought much of the courage of a lion-tamer. Inside the cage he is at least safe from people."

- George Bernard Shaw

ADVERTISEMENT

Sponsors