IPM Day 2019
November 7, 2019 | Online Conference
Viewing Posts by David Maynard
#PMICon18 Ask the Experts
Categories:
Agile,
Best Practices,
Calculating Project Value,
Communication,
Complexity,
Earned Value,
Education and Training,
Government,
Human Aspects of PM,
Innovation,
Leadership,
Lessons Learned,
New to Project Management,
Nontraditional Project Management,
Procurement,
Program Management,
Project Delivery,
Project Failure,
Project Planning,
Project Requirements,
Risk Management,
Scheduling,
Strategy,
Talent Management,
Teams,
test,
Tools
Categories: Agile, Best Practices, Calculating Project Value, Communication, Complexity, Earned Value, Education and Training, Government, Human Aspects of PM, Innovation, Leadership, Lessons Learned, New to Project Management, Nontraditional Project Management, Procurement, Program Management, Project Delivery, Project Failure, Project Planning, Project Requirements, Risk Management, Scheduling, Strategy, Talent Management, Teams, test, Tools
| 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
|
Troubled Project? #PMICON18 Ask the Experts!
|
#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:
What’s common in these stories? (there are many, many more)
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.
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)
|
Backward Expert
Categories:
Benefits Realization,
Best Practices,
Calculating Project Value,
Change Management,
Communication,
Communication,
Complexity,
Education and Training,
Generational PM,
Government,
Human Aspects of PM,
Human Resources,
Innovation,
Leadership,
Lessons Learned,
New to Project Management,
Nontraditional Project Management,
Project Failure,
Project Planning,
Project Requirements,
Reflections on the PM Life,
Risk Management,
ROI
Categories: Benefits Realization, Best Practices, Calculating Project Value, Change Management, Communication, Communication, Complexity, Education and Training, Generational PM, Government, Human Aspects of PM, Human Resources, Innovation, Leadership, Lessons Learned, New to Project Management, Nontraditional Project Management, Project Failure, Project Planning, Project Requirements, Reflections on the PM Life, Risk Management, ROI
| |
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
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 DeliveriesWith 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 InteractionWith 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 ChangeThe 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 |
Answering Dave Davis' Risk Question
| 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.” 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 |