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

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

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

Hi Mr. Davis!

First, you’ve asked an excellent question.   I think there’s really two parts to it.   Some of the ones you list could affect the project only (resignation) but some of them are corporate level risks (cyber-attack). 

There should be good risk-stewards at the corporate level, working with the accounting and general management folks to forecast and protect against hurricane, tornados, zombies, whatever.   These risks are out of the project manager’s hands and are part of the overall business risk assessment.  You *could* say these are “organizationally accepted risks.” 

That’s all “C-Suite” stuff.   Sure, your project may get washed away in a hurricane, but the PM isn’t really held responsible for insurance, or claims, or set-asides for that.  Perhaps, a PM may get involved in planning for data safe-backups (offsite) but even that is not common.

But!  As a top-notch Project Manager, when you think of these ORGANIZATIONAL types of things, I believe it’s your duty to ensure that the general business folks have considered them.   So, for instance, I had the sprinkler system come on over a weekend (no fire) and it stayed on until Monday.  I never imagined that would happen.  If I was just a bit smarter I would have, and would have politely asked the folks upstairs in the corner office if they had set aside funding to take care 2 feet of water from sprinklers.   I don’t consider this to be a project risk, but an Organizational level risk

So, if you can imagine a business risk and it has some likelihood of occurring you have an honor-bound duty to inform the business risk people about it.    If they don’t take care of it, then you must handle it on the project. 

If it’s a commonly accepted risk taken at the project level (a late deliverable) then it should be in your project’s risk register and you’ll be the grass and the executives will be the lawnmower.

-- Dave

Chalk Talk - A Valuable Problem Solving Tool

For some strange reason, I find myself blogging about chalk and chalkboards for a second time.  No, I’m not hung up on them. But, yes, I *do* enjoy good old-fashioned slate and the smell of dusty chalk.  But – that’s not the purpose of the blog.

To make things even more confusing they’ve started painting the inside walls of classrooms where I often show up at - with “whiteboard” paint.  Now that bugs me.   A student walked right up to the wall and started drawing on it with a marker!  It looked pretty much like any other wall.   I kept yelling it was just a wall!   Some of her quicker witted fellow students whipped out their phones and announced, “This is going on Facebook!”  But of course, they were all having a fine time with my old-man ignorance and it was a “white wall.” 

OK.  Back to Chalk-talk. 

Sometimes at NASA, working as a team we’d come across a problem that just seemed impossible.  We’d work for days, sometimes weeks trying to solve a single problem.  I remember multiple times staying up for 30 hours in a row trying to solve one problem – not recommended!  This sort of effort required third-shift coffee, cherry pies from the vending machines and lots of second-hand smoke.  

What’s Third shift coffee?  Each preceding shift was honor bound to have a pot of coffee waiting for the next arriving shift.  So, the guys on second shift, at around 11PM would make an extra strong pot for the third shifters arriving at 11:30 PM.  The first thing a real third shifter would do is to add a tablespoon of instant coffee to each cup.  Everyone knew what third-shift coffee was like.  A hard (not necessarily big) problem required around-the clock third-shift coffee. 

None of this is healthy, smart or conducive to solving complex technical or mathematical problems.  But… we did it.  Our (very good) branch chief would drop in from time to time, ask a few questions and then wander off.  At some point, based upon his instincts, he would call for a “CHALK-TALK.”  This meant we’d have to leave wherever we were working, go to a new / different conference room.  And take turns standing up in front of a chalkboard explaining what the problem was and how we thought it could be fixed.  We each took turns doing this.   

I can’t remember a single time when this method didn’t get us to a solution. We were all tired, grumpy, short-tempered and wired with caffeine, but it worked. Sometimes someone would be talking at the board and the solution would hit us all at-the-same-time like a hammer.  Other times, parts of the group needed to explain it to the others.  A few times only one person would see the solution and explain it to everyone else.   Again, no rules and not much of a pattern fell out.  But I can think of a few guidelines...

Guidelines:

1. Research the problem until you know all about it.  Exhaust all possibilities.
2. Have a “judge” call for “chalk talk” time.
3. Remove the group from the area of the problem – the more different the environment is, the better
4. Have a blackboard, chalk and eraser (OK, whiteboard markers….)
5. Let one of the group play “teacher” first.  If the solution doesn’t come, someone else takes a turn.  They can restart or build on whatever is on the board
6. Participants don’t have to be quiet.  I remember them being QUITE vocal.  This involved name-calling, whistling, foot-stamping, whatever… But those sitting couldn’t stop the person with the chalk from expressing what they thought the problem or the path to the solution was.  The chalk was the power.
7. The person with the chalk could give up at any time.  Someone would have to pick up the chalk, but hopefully not someone who just was “up.”

When a solution is arrived at – everyone knew it.  It was like the room filled with water.  Quiet.  People looked at each other.  Eyebrows went up.  Some people went home to sleep right then!  Other’s went back to (regular) work to try the arrived-at solution

Who is an Expert?  What makes them an expert? 

I don’t pretend to be a cognitive scientist, nor have I done much research on the topic – but it is a fascinating field.  And there is a *lot* of literature, books, theses, and studies on the topic to choose from all the way back to Plato and perhaps before.  This blog entry is based upon what I’ve read plus personal opinions and thoughts.  The question “What is an Expert” was planted in my brain by the good folks at ProjectManagement.com who have asked me (and others) to participate in “Ask the Experts.”  

Please let me know if you disagree or feel I need to add something!   

An expert is generally considered to be a person with extensive knowledge or ability based on a combination of personal research, experience and occupation and in a discipline.  In our case, Project Management and related topics.

I found a  scale by which experts can be judged within a specific field (Germain's scale 2006) that  gives some interesting hints…

• Specific education, training, and knowledge
• Required qualifications
• Ability to assess importance in work-related situations
• Capability to improve themselves
• Intuition
• Self-assurance and confidence in their knowledge

More down to earth definitions exist.  Mark Twain defined an expert as "an ordinary fellow from another town." Will Rogers described an expert as "A man fifty miles from home with a briefcase."

Application to Project Management

I’d going to tailor this write-up for Project Management as well as drift away from academic studies and simply express my own views.

1. Has experience: There is clearly a level of experience required to be an PM expert.  My guess is that 10+ years as a full-time PM are required.  This experience can be either specific to a field or it could be spread across many different fields that have projects.  I don’t think that makes much difference.

2. Survived failures: I also believe that an expert has had a lot of failures, and made a lot of mistakes; big and small.  I don’t mean to say that an expert always fails, or only fails, but that their projects stumble and recover or may even fail outright. That’s the hard learning that occurs during the years of experience in number 1 above.   Perhaps if a project manager had never had a failure, they could not be an expert… 

3. Is observational:  A PM is always observing what works, what doesn’t what almost worked and is thinking about what to do next time.  So, combined with item 2, It’s not just about recovering from mistakes, it’s about recovering the project in the smartest, best way and learning what *not* to do next time and how to avoid getting into that mess again.   They also observe small details in the project’s operation that don’t appear to be important.  These are all signs that can be read and parsed out to see how things are going and what the general health of the project is. 

4. Highly Confident: An expert PM has confidence in what they say and do.  Of course, this combined with number 2 makes for a wild ride.  We’re letting loose people that, with confidence – make mistakes and then recover, which leads me to point number 5.

5. Story Teller:  I’d like to substitute the often-quoted top-job of a PM is communication with the most important skill a PM has is 'Story Telling'.  I’m not talking about making up stories, I mean explaining what has happened, or what is expected to happen in an easy-to-follow cogent fashion.  *They don’t lose the listener*.  How story telling is learned is something I’m still struggling with.  I have a few ideas, but of course practice helps!

6. Strong Sense of Mission: The expert Project Manager carries within them a “sense of mission” in other words, a sense of the value of the project.   It’s the answer to “Why are we doing this anyway?   Every action, decision and communication is made with the internalized, overriding strong sense of mission of the project.  It’s expressed in meetings, to people working on the project, to stakeholders – everyone and, the PM believes it… strongly.

7. Feels the Flow of the Project:  Once all the above are in-place, confident, has failed (and recovered) many times can tell the story of the failure, and can sense the smallest details of a project and how they inter-relate, they’ve arrived.  I’d declare them to be an expert. 

OH!  They’d have to have at least one PMI certification as well!