Project Management

PMI Global Insights

by ,
Whether it’s in-person or virtual, PMI events give you the right skills to complete amazing projects. In this blog, whether it be our Virtual Experience Series, PMI Training (formerly Seminars World) or PMI® Global Summit, experienced event presenters past, present and future from the entire PMI event family share their knowledge on a wide range of issues important to project managers.

About this Blog

RSS

View Posts By:

Cameron McGaughy
James Turchick

Past Contributors:

Kimberly Whitby
Johanna Rusly
April Birchmeier
Nikki Evans
Dalibor Ninkovic
Dr. Deepa Bhide
Tao Chun Liu
Jonathan Spiteri
Chris DiBella
Nic Jain
Tyler Norman
Nicholas Sonnenberg
Tam Abaku
Klaus Nielsen, MBA, PMI-ACP, PMP
Karen Chovan
Jack Duggal
Catalin Dogaru
Priya Patra
Josh Parrott
Scott Lesnick-CSP
Antonio Nieto
Dimitrios Zaires
Ahmed Zouhair
Carmine Paragano
Te Wu
Scott Bain
Katie Mcconochie
Fabiola Maisonnier
Erik Agudelo
Paul A Capello
Kiron Bondale
Jamie Champagne
Esra Tepeli
Renaldi Gondosubroto
Joseph Musiitwa
Mel Ross
Laura Lazzerini
Kim Essendrup
Geetha Gopal
David Summers
Carol Martinez
Lisa DiTullio
Tai Cochran
Fabio Rigamonti
Archana Shetty
Geneviève Bouchard
Teresa Lawrence, PhD, PMP, CSM
Randall Englund
Kristy Tan Neckowicz
Moritz Sprenger
Mike Frenette
O. Chima Okereke
David Maynard
Nancie Celini
Brantlee Underhill
Claudia Alcelay
Sandra MacGillivray
Vibha Tripathi
Sharmila Das
Michelle Brown
Gina Abudi
Greg Githens
Joy Beatty
Sarah Mersereau
Lawrence Cooper
Donna Gregorio
Seth Greenwald
Bruce Gay
Michele Mattera
Wael Ramadan
Fiona Lin
Somnath Ghosh
Yasmina Khelifi
Erik Rueter
Joe Shi
Michel Thiry
Erika Kiely
Heather van Wyk
Jennifer Donahue
Barbara Trautlein
Julie Ho
Steve Salisbury
Jill Diffendal
Yves Cavarec
Rose James
Drew Craig
Vinay Babu Tarala
Stephanie Jaeger
Diana Robertson
Zahid Khan
Benjamin C. Anyacho
Nadia Vincent
Carlos Javier Pampliega García
Norma Lynch
Heather McLarnon, CSPO
Emily Luijbregts
Susan Coleman
Aneliya Chervenova
Michelle Stronach
Sydni Neptune
Louise Fournier
Quincy Wright
Peace Opuruiche Echeonwu
Nesrin Christine Aykac
Ming Yeung
Laura Samsó
Lily Woi
Jill Almaguer
Mayte Mata Sivera
Prof. Éamonn Kelly
Marcos Arias
Karthik Ramamurthy
Michelle Venezia
Yoram Solomon
Cheryl Lee
Kelly George
Dan Furlong
Kristin Jones
Jeannette Cabanis-Brewin
Olivia Montgomery
Carlene Szostak
Hilary Kinney
Annmarie Curley
Dave Davis

Recent Posts

Presentation Recap: Navigating Multicultural Dynamics in High-Performing Research Teams

Presentation Recap: From Adversity to Innovation

Presentation Recap: Public Sector Digital Projects as Social Impact Engines

Presentation Recap: How PMOs Can Drive Customer-Centric Transformations

Presentation Recap: From Projects to Products – Redefining Roles in the Modern Workplace

Categories

Agile, Agility, alignment, Ask the Expert, Benefits Realization, Best Practices, Bonding, Business Analysis, Calculating Project Value, Capital Projects, Career Development, Change Management, Cloud Computing, Collaboration, collaboration, Communication, Complexity, Congress 2016 Ask an Expert, Construction, Curiosity, Digital Transformation, digital transformation, Documentation, Earned Value Management, Education, EMEA, EMEA Congress Reflections, Engagement, engagement, Ethics, Events, Extra Info, Facilitation, forecasting, future, Generational PM, Global Congress 2016, Global Congress 2016 - North America, Global Summit, Global Summit 2023, Good News, Government, Healthcare, Human Aspects of PM, Human Resources, Identity, Innovation, IT Project Management, Kickoff, Leadership, Lessons Learned, Mentoring, Metrics, Networking, New Practitioners, Nontraditional Project Management, organisations, Organizational Risk, PM & the Economy, PM Think About It, PMI, PMI Congress, PMI Congress NA 2016, PMI EMEA Congress 2018, PMI Global Conference, PMI Global Conference 2017, PMI Global Conference 2019, PMI Global Congress - 2016, PMI Global Congress 2012 - North America, PMI Global Congress 2013 - EMEA, PMI Global Congress 2014 - North America, Pmi global congress 2014 - North America, PMI Global Congress 2015, PMI Global Congress 2015 - Ask the Expert, PMI Global Congress 2016 - EMEA, PMI Hours for Impact, PMI PMO Symposium 2013, PMI Pulse of the Profession, PMI Training, PMI Virtual Experience Series, PMIEMEA17, PMIEMEA19, PMO, PMXPO, Portfolio Management, Procurement, Professional Development, Program Management, Programs (PMO), Project Delivery, Project Failure, project kickoff, Project Planning, Project Requirements, Reflections on the PM Life, Risk, Risk Management, ROI, Roundtable, Scheduling, SeminarsWorld, Social Impact, Social Responsibility, SoftSkills, Stakeholder, Strategy, Sustainability, Talent Management, Teams, Techniques, test, The Moon, Tools, Training, Translations, Videos, Virtual Experience Series, Virtual Teams, Volunteering, war

Date

Viewing Posts by David Maynard

Ask The Experts -- at the global conference

ProjectManagement.com has again pulled together a group of experts to help answer any questions you may have about Project Management and Projects in general.  I'm proud to be one of them!  

It's pretty easy to ask us stuff.  You walk up to the desk, a friendly PMI person will talk to you, figure out who can help you the most and make an appointment.   What can you ask us?  Just about anything.  Our group has a very wide range of knowledge and experience.

Here's a small mind map of who we are and what we can help with.  

Please stop by and visit with us!  We're all proud to have been selected as experts and we're even more proud to offer help to anyone that asks.   

I'm the Dave with "trouble" by his name.  :) 

Posted by David Maynard on: September 26, 2019 11:43 AM | Permalink | Comments (18)

#PMICon18 Ask the Experts

Several of the experts have created graphics that illustrate areas they can help with.  I didn't want to be left out, so here's mine!   Think about making a reservation (online here) to talk to one of us or just stop by and see if there's a slot open.  

We'd love to talk to you. 

-- Dave

Posted by David Maynard on: October 01, 2018 01:00 PM | Permalink | Comments (8)

Troubled Project? #PMICON18 Ask the Experts!

Ask the Experts - #PMICON18

#PMICON18 is just a week away now!   I’d like to encourage all of you to visit “Ask the experts” either by skipping a session or during a break.  You can pre-schedule time online

-----------------------------

Life after NASA

I’ve rambled on about NASA and the great things I learned while growing up there in other writings.  But, I’ve had a life after NASA too.  A group of us decided we could help troubled projects, programs and operations turn-around their troubles. So, we left NASA-Houston (and other places) and moved to Orlando, Florida (why not?) to start a company. 

Most of our work came from companies both large and small that had won US Government contracts and weren’t able to perform.  Why them?   Because there are very strict Federal procurement laws in-play that pretty much insist (legally) that for a fixed price contract, you MUST finish what you started.  It doesn’t matter what it takes, it must be finished and meet the customer’s needs.

At first, that was our niche.  We’d swoop in, understand the problems, give the poor company a bid for our services, put some of our key people in place and do our best to recover the project.  We never had one fail!  It was clear that after a few years of doing this, we saw the same reasons for failure over and over.  There were a few creative ways in which companies crashed while performing a project but not many. 

Well, word spread.  We started taking on commercial contracts (a different world from Federal contracts).  Surprise!  Commercial companies made nearly the same mistakes in their projects and programs as Government-suppliers.  There’s a continuity there, that would be an interesting study to do.  

Mistakes that stick out in my mind:

  • A software company decided that no existing database application would fit their needs, so they decided they needed to write their own database system
  • A systems integrator decided to save money off the final sale price by NOT conducting inspections of custom items that were ordered from vendors.  They just bolted things together and *knew* it would work.
  • A large supplier to the project was “bankrupt and didn’t know it.”  Neither did the people that had the contract to include their product in the final deliverable.  They just couldn’t believe it when I told them.  We ended up buying the bits and pieces and hiring key employees. 

What’s common in these stories? (there are many, many  more)

  1. Where is the boss?  Where is the Project Manger?  Where are the executives?  “Oh, we never talk to them except during our every 6-week review cycles. “
  1. The executive desire to never hear bad news.  Or, “Don’t tell me what your problem is, tell me what your problem was.”  This is totally wrong-headed approach.  Executives exist to knock down the problems workers are having, not to shove them back at them. 
  • This created a saying on our team “Bad news is good; Good news is Great" (the subject of a PMI paper I wrote years ago)
  • You as the PM – NEED to hear bad news, all the bad news there is!  If you don’t hear it, you can’t do anything about it. 
  1. Poor / no status tracking Many of these companies had a very high-level Gantt chart that they met once a month about and everyone said it was fine.  Risks were not discussed, budget was not discussed.  (see item one above).

The flip side of this was companies that had people planning down to the minute every action the project team should take.  Bathroom breaks, lunch… whatever.  That’s just plain silly and won’t work.

  1. No or poor communication between groups working on the project.   It was common on troubled projects that one group had no idea what another group was doing.  Yet, both groups had components that needed to work together for the product of the project to work.
  1. No WBS:  This used to get me very hot under the collar.  It clearly points to nearly zero project planning.
  1. No cost accounting: No idea what was spent for what or when.  Overrun?  Maybe.  Funds remaining to help a failing area?  Maybe…

These are all true.  I could get a group of people on the phone to explain these and much, much more. 

I’d better stop now – I want to create a nice chart like my best buddy EM THE PM did.

-- Dave  (or DAM PM [my initials are DAM] not to be outdone by EM the PM) 

 

Posted by David Maynard on: September 30, 2018 01:01 PM | Permalink | Comments (7)

Backward Expert

backward

This is a backward blog posting!

This will be my final post before leaving for Chicago tomorrow morning.  So, I wanted to do this one more like the way I think about things – BACKWARDS.  Instead of telling what areas I can help with, I thought I’d ramble about what areas I like to talk about!  I guarantee it would be an entertaining discussion.  Just make select an open appointment here:  then wander over, say hello and lets just talk about one of MY favorite things.

1.  Project failure.   I know more than I ever wanted to know about this.  There was a group of us that Left NASA at the same time and moved to Orlando to start a company dedicated to turning around troubled projects, programs and operations.  When we started, we thought we’d seen just about all the problems that project can get into.  WRONG.  For the next 5 or 6 years we only worked on turning around projects that were at least 100% over budget, perhaps 3 or 4 years late, had irate customers… or simply failed to deliver anything of value. 

It’s not easy to judge project failure!  EVA won’t do it.  It’s a very subjective thing.  “Could anyone have done better in the same situation?” is a basic test, but there are many more. 

So, we fired, hired, replaced, improved… bought contracts, had contracts “novated” to us, and were very successful ending up with a stand-along building and 70 employees.  There’s a lot of trouble out there!   There were project mistakes made that I didn’t think cold be made.   We worked on Casino projects, entertainment projects, airline projects, and many other types.  

Our group learned a lot!  I love to talk about a failed project and how it can be recovered.  Number 1: be ready for stress.  We called being personally ready “the full wax job.”  Exercise, diet, mental toughness, how you dress…  no kidding!  But you need to be prepared.

2.  Working with a team that has widely diverse skills.  If the team gets diverse enough, sometimes you can’t understand what the other people are saying.  I’ve managed teams with theoretical physicists, mathematicians, brilliant engineers and more – of course, they were totally convinced they were ALL CORRECT, don’t even think about doubting their work.  This was great fun.  I loved it and learned a whale of a lot about things they didn’t teach me (a humble engineer) in school.

3. Project risk.  How to think about it, how to predict it, how to anticipate it, how to communicate it, how to budget for it, how to look for the often-neglected positive risk.  It’s CRITCAL that project managers and their teams master this skill.   I’ve had friends die a horrible death  because we (in a larger sense) didn’t manage risk well.

4.  Have the courage of your convictions.  Tell people what you believe, tell the bosses what your project team believes.  Don’t fall into the trap of “drinking your own bath water” or the “echo chamber.” 

Well, I feel better!   Wander over and chat with me!

-- Dave Maynard

GOING TO THE 2017 PMI GLOBAL CONFERENCE IN CHICAGO?  

Don’t forget about ASK THE EXPERTS!

Stop by and talk to Dave Maynard or one of the other experts.  There’s more information about it at https://tinyurl.com/y7ff8f3g

Sign Up Now

Posted by David Maynard on: October 26, 2017 01:47 PM | Permalink | Comments (4)

Agile NASA software? Are you Crazy?


Going to the 2017 PMI Global Conference in Chicago?  

Don’t forget about ASK THE EXPERTS!

Stop by and talk to Dave Maynard or one of the other experts.  There’s more information about it at https://tinyurl.com/y7ff8f3g

Sign Up Now


NASA JSC Engineering

Isn't NASA the epitome of the double-cursed WATERFALL technique?

Wrong NASA was agile before agile was a common term.  As a matter of fact, One of the 17 original authors of the agile manifesto -- Jim Highsmith used to work at NASA.   The question that NASA asked itself was: “How can we, the space ops community, adopt state-of-the-art software development practices, achieve greater productivity and lower cost, and maintain safe and effective flight operations?”

NASA Ames, together with my old “home” JSC (Houston) and JPL are developing “Mission Control Technologies (MCT) software in an integrated agile environment --- with modifications necessary because of human life and safety factors (in a *very* harsh environment).

Traditional requirements processes and documentation was replaced with a team design process which included the customer, design experts and paper prototypes. (Sorry Systems Engineering).  Iterations were delivered to the customers every three weeks with a full release every three month (Sound like NASA-Agile now?) 

Nightly builds were made available to facilitate customer feedback on the team’s progress.  This effort replaces the traditional intensive NASA documentation and reviews with ongoing interactions.  Technical documentation is maintained on a team Wiki which everyone has access to and can contribute to.

Why do this? 

To shorten the delivery cycle, break large software development efforts into smaller more easily manageable pieces. To facilitate direct interaction between the developers and the users.  And to produce a download daily so users always have the means to access the latest version of the code.

Replaced Predictions with Actuals.

Progress is measured by the state of the code, rather than estimations and presentations.  For the MCT this takes three forms.  First, the nightly build, second are the iterations (every three weeks) typically installed in a Mission Control test facility.  And after four iterations the software is released for operational mission control certification.

Manageable Deliveries

With a longer delivery cycle, the more the code, the greater the complexity and the larger number of tests that must be conducted.  A longer cycle means more time from specification of function to delivery.  The greater the time from specification to use, the greater the room for error between user expectation and the software product.  Using a shorter cycle reduces the number of new features and possible regressions.  Agile may not reduce the total number of tests, but it distributes them over time, making it a more manageable effort.

Development Team / Customer Interaction

With a short delivery cycle, the availability of working code for evaluation and feedback, makes it possible to have closely coupled interactions between the development team and the customer.  The developer-customer interaction is very useful to verify new features as they are rolled out.

Fast Response to Change

The shorter development cycle allows the team to better respond to changes.  The software is rolled out in stages, the users respond then the development team can act on this feedback. 

 

Next time: NASA Agile: Delivery Cycles. 

Reference: American Inst. of Aeronautics and Astronautics; Reston, VA, United States; Agile Development Methods for Space Operations Jay Trimble Nasa Ames Research Center Mountain View CA and Chris Webster University of California Santa Cruz, Nasa Ames Research Center, Mountain View, CA

Posted by David Maynard on: October 18, 2017 02:00 PM | Permalink | Comments (14)
ADVERTISEMENTS

"It is one of the blessings of old friends that you can afford to be stupid with them."

- Ralph Waldo Emerson

ADVERTISEMENT

Sponsors