Calculating Project Value,
Education and Training,
Human Aspects of PM,
New to Project Management,
Nontraditional Project Management,
Reflections on the PM Life,
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
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.
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
Who's coming to Chicago?
Education and Training,
Human Aspects of PM,
Nontraditional Project Management,
Categories: Agile, Career Help, Communication, Complexity, Education and Training, Facilitation, Generational PM, Government, Human Aspects of PM, Human Resources, Innovation, Leadership, Mentoring, Nontraditional Project Management, Portfolio Management, Procurement, Program Management, Project Delivery, Social Responsibility, Stakeholder, Strategy, Talent Management, Teams
I can’t believe it’s been a year since I had the privilege of attending PMI Global Congress 2016 in San Diego as part of the Ask the Experts cadre. I once again have been afforded the privilege of attending, this time in Chicago from October 28-30, 2017!
The Ask the Experts sessions are designed for attendees like you to have access to your peers in the profession who may have been there, done that, but also more than likely have a few scars to show for it. The point to scars is that while they may hurt at the time of the injury, you tend not to forget their lessons, well most of them anyway.
In the lead up to this year’s event I thought I’d provide a little insight for attendees for who I am (besides the scars side of it), where I came from, where I’ve been, where I’m going, and what drives me. In so doing, I’m hoping that it will resonate with a few of you who will be attending, and that’ll cause you to want to come share a bit about yourself with me. And while doing that, feel free to off-load some of your challenges with me and I’ll see if I can offer some insights that you might find helpful.
So who is Larry anyway?
I was born on a dark and stormy night in the middle of the north Atlantic (closer to reality than you may believe as my house was less than 50 feet from the ocean) on March 5, 1958, in a very small town in Newfoundland, Canada. I graduated with a B.Sc. in Computer Science in 1977. I started university at 16 and graduated at 19 – it wasn’t because I was that smart, it’s because we only went to grade 11 back then. Another factoid – the year I started my B.Sc., 1974, was also the year the first graduating class in Computer Science were finishing their degrees at my university! When I turned fifty, my then 5-year old looked up and said (instead of Happy Birthday) “daddy, you’re old!” So I just saved you the trouble – I’ve been told that already.
I did my entire B.Sc. on punched cards – the PC did not come along until a couple of years after I finished my degree. What’s interesting is that in my first job with the provincial government I did everything – requirements, analysis, design (such as it was), developing, testing and deployments. Sounds a lot like the self-organizing, cross-functional teams in Scrum, doesn’t it? (if one person can be a team, but you get the idea – you had to have multiple competencies).
Starting in the late 1980’s and 1990’s and into the 2000’s I watched the IT industry turn these competencies into roles, and eventually into entire org structures – honestly I never got that, so I mostly ignored It. I was lucky enough to be in small enough size places to get away with ignoring the trend.
Along the way I also picked up an M.A in Public Administration and 20+ industry certifications on project management, Agile and ITIL. That degree is when I had to learn how to write – I was a lousy English student. Then again, I was a lousy software developer too, so lucky for me I learned how to write. So I was clearly not a NASA scientist calibre fellow like David Maynard, another of our gang of experts. But I do have talents – we all do.
We all have those moments that we feel define us in some way. Mine was a little more than a moment – more like three years to be exact.
In the early 1990’s I worked as the Operations Manager for Ice Forecasting Services at Environment Canada in Ottawa as we faced an enormous challenge.
The gist of it is that we would be replacing aircraft that flew around the Arctic and “iceberg alley” off my childhood home of Newfoundland, taking radar images of the ice floes and bergs, with a satellite that would provide full imagery for all of Canada in a single day – 7.5 GB of new data/day in an era when our largest disc drive was 424mb. That was a lotta data!
This meant a wire-up replacement – networks, all hardware (mini computes, the workstations, etc.), and all of our software. Oh, and we had roughly three years in which to do all of it.
Some things that were pretty obvious pretty quickly:
Necessity as they say is the mother of invention. We went to see the vendors for hardware and some of the software options that might fit. For example, we wanted four-foot wide screens to display the imagery. The response was, “you guys are about ten years too early” (we heard that a lot).
We decided to go object-oriented for any software we had to build – and none of us knew not an iota of how to code in it. We decided to assemble two small development teams that would remain intact with all the tools they needed. We set targets for having useful things delivered every three to four months.
We decided to look at what capabilities were common across our applications and build those before we did any application development - we called them Global Services; This was 1992 and a good ten years before Service-Oriented Architecture was a thing. Eighteen months after we had made the decision, the Object Management Group came out with the CORBA Specification and called some of what we had done Common Facilities. Who knew? Once the services were built, we able to rebuild our applications at a rate one per team every 3-5 months.
And in the midst of all that, we also managed to implement automated event and incident management, as well as automated capacity management – also ten years or so before ITIL really became a thing on this side of the pond. We had to – we only had three system administrators and over 30 servers and a dozen high-end workstations to manage that had limited capacity in a 24x7 operation.
It was the most influential three years in my professional career.
Near the end of the projects we had started, I was asked by Auerbach Publishers in NY to write a couple of chapters for the 1996 edition of their Manager’s Handbook of Local Area Networks (the book talked about almost everything but!) on the design approaches we had used (never did find out how they found me). That was my introduction to writing beyond project documents.
I left the government after nearly eighteen years in 1995 and went over the private sector as a consultant which I have mostly done since (except for a two year stint as an employee at a telcom company 1999-2001)
My time at Ice had a tremendous influence on everything I did afterwards, especially in how I viewed the project and the software development worlds:
(My new friend David from the 2016 congress used a similar approach at NASA before we did it).
As a result of what I learned during that period, I ended up leading teams that applied the same design principles to business process as we did for software design, taking an outcomes-based approach to figure out what we needed to do based on where we wanted to go, creating an incremental release strategy for what became the world’s largest web-enabled supply chain, and fell almost naturally into an agile way of working before the Manifesto for Agile Software Development was released in 2001 (truth be told, I never came across the Manifesto until 2009).
All of that led me to doing more writing as part of a book series I have labeled The Agility Series (www.TheAgilitySeries.com). You can read more about the series here. The newest book I am working on is called Cultural Agility: Changing our Stories . In fact I’ll be meeting one of my contributing authors to this book for the first time during the conference. Can’t wait!
Besides writing, I am a strategic portfolio executive and trainer, with a decided emphasis on organizational adaptability and agility in all its forms. I am also involved with www.NFPPC.org where we are trying to distill all of the industry frameworks, standards, and methodologies down to their essential WHATs. Why would we do that? Because so many of them overlap with one another and at times create as much confusion as they do clarity. And with all the talk about Agile it would be kind of nice to know which parts of what we already know still has value in helping us do things in a more agile way.
Why do I still work? Besides the obvious reason of having a 15-year old who won’t be leaving home for a while and then has university ahead, it’s because I genuinely like what I do. It’s fun. I have changed careers multiple times within the IT/PM profession over the years. Sometimes out of necessity. Sometimes for fun. I find the more I know, the more I realize how much I really don’t know. It’s fun learning new things and meeting new people and feeling like I am still making a difference.
The feeling of making a difference is a very human emotion. Everyone wants to make a difference and everyone does so in their own way. There also no one way to do that successfully.
If you’d like to talk strategic intent, adaptive strategy, back-casting over forecasting, outcomes over outputs, any of the agilities, or pretty much anything you think I may be able to help you with in making a difference in your world, here is my availability during the conference:
Oh, and as much as you think we may be able to help you make a difference, I am guessing that by the end of the conference some of you will help us see things differently and change how we make a difference.
So, let’s meet up in Chicago and make a difference together!
How Digital Transformation Leaders will Transform Employee Disengagement Into Individual Happiness and Business Success
The first success variable in The Digital Transformation Success Formula is individual transformation. Countless sources are predicting the disappearance and / or displacement of jobs. But for as long as we exist as humans, we will still need each other's. What if losing jobs was the way we could resolve disengagement and be transformed to a greater state of authenticity that leads to better innovations and happiness?
We have developed a professional mindset in conformance with a few stereotypes of the professional life. It is a mindset that often separates who we really are to show just a small part of us that the business world expects to see. We were programmed this way from our earliest upbringing and later through the corporate world-structure and mindset even more. However, the truth is that the motor that powers our professional life is our individuality, our authenticity.
While our individual programming allows us to reproduce the professional pattern without much effort, this restrained professional mindset limits our potential. For many of us, key personal values like aspiration and dreams are often well outside of this professional patterns, which is an identity that we spend most of our awake time at work. Have you ever noticed how some boldly authentic posts may attract attention on LinkedIn while a few people suggest that Facebook should be used for such posts instead?
Our individual values, passions, interests, and aspirations are the regulators of our energy. When we stay close to or within their influence, we experience the greatest level of energy, positivity, and happiness. The more we move away from them, the less positive energy and consciousness we experience. As a result, the person lacks authenticity and is operating like a robot on autopilot and barely using his / her brain. This is the complete opposite of someone that is mindful and alert.
Our organizations are filled with these robot-like individuals, conditioned to repeat procedures mindlessly. When a change is announced, these are the individuals who resist the changes the most, all while being disengaged. Double the issues!
Employee disengagement is the biggest challenge that organizations around the world face today. But, these organizations created or contributed to such situations as well. Starting at recruitment, many HR departments already have their restrained criteria established, like a box to fit employees, and then the employees do their best to fit in the box to get the job. While this is a way to standardize an organization, it is an approach that restrains creativity and authenticity.
Can an individual be that great without authenticity? Brain science and neuroplasticity reveals otherwise. The statistics about global employee engagement, which is down to 13% according to Gallup, proves this. With digital transformation, we have the opportunity to empower our people to release their fears, find their inner values and passions so they can embrace them. As a result, they will become mission-driven and innovate in their professions. Creativity and authenticity are much needed today to increase innovation in our businesses and organizations. Losing jobs but gaining mission can be a great solution to disengagement.
I encourage every leader to embrace their authenticity by engaging in self-transformation so that they inspire their organizations to do so as well. This is the best way we can turn around disengagement and create organizations with individuals on missions, who are energized, happier and productive in the digital age. Many disengaged individuals will at this point release themselves from jobs that they are tied to but dislike, and are wasting both their resources and that of their organizations, to embrace their individual missions, which may be another position, another view of their contribution, or else, with great enthusiasm. As a result, the mission-driven workforce will transform our organizations to experience more business innovation and success. Everyone will experience greater individual happiness.
If you are a digital transformation leader, I invite you to join my mastermind coaching program, Leaders on a Digital Mission here.
Find out more about my book The Digital Transformation Success Formula here.
Your coach in transformation,
TIP #5 FOR MANAGING A CROSS-FUNCTIONAL TEAM
(How to herd a group of cats, cows, sheep, goats, dogs and llamas….)
Meetings Don’t Waste Money, If They’re Done Right
Often in a meeting someone will count the number of people there, multiply by some number and come up with a cost then declare the amount of money ‘being wasted.’ It’s certainly possible to waste money (salaries) having people in a non-product meeting. It’s easy! Meetings are sometimes called “the practical alternative to work.” AVOID THIS. Don’t do this. Have well-run meetings.
How? With Team Rules
Create a set of team rules! The rules don’t have to be detailed, they shouldn’t come close to resembling a “Roberts Rules of Order.” Our teams typically had about 8 or 10 rules. We would post them on the wall of the meeting room. Again, if you are meeting virtually, the same thing can be done. Everyone can print out the meeting rules tape it someplace, or put it on their desk. Whatever. But actually seeing the rules written down in front of everyone is important.
Here’s a photograph of a set of rules from a very stressful turn-around project. If you can see it, the last rule was a fine. We’d fine people $1.00 if they were late for meetings – these funds were later converted to liquid and consumed by all.
A slightly edited version of our rules are
Shout Them Out
We shout these out if someone violates a rule. For instance, our mathematician might say: “Whatever… I can do what you want, if you really want to do it that way.” Everyone will shout out “RULE 6 VIOLATION!” as loud as possible. I must admit, I’ve been called out for “rule 8 violation” several times…
Rule number 4 sounds odd. “The truth is permitted.” This means that team members can say things you wouldn’t normally hear in meetings. “I’m late getting that done.” Or, “This is never going to work.” “Our solution is awful!” The only correct answer from the team for someone speaking to Rule 4 is “THANK YOU.” Then, the team starts working on solving whatever issue just came up.
There’s harmless humor in every situation
In any project, epically difficult ones – humor helps. I’d like to refine this a bit to say “harmless humor.” One fellow on our team was late for a meeting and arrived sweaty. He promptly took off his tie and threw it on the floor. “What’s wrong with you?” It turned out he was shredding papers and got his tie caught in the shredder – while he reached everywhere to find an off switch. From that day on, we awarded the tie to people for “lack of attention to detail.” Later, the goat tie tack was added for an extra honor. Everyone loves it. Except perhaps the prize winner.
Mindreading doesn’t work
This one is pretty simple. If you think the rest of the team should hear it – SAY IT. It’s surprising how often teammates (who speak a different technical language) assume the rest of the team knows what they’re thinking.
Part of the project leader’s job is to dig in to find problems. The problems are then scheduled for “demolition.” To find problems, we always, always ask the following questions
Whatever it that makes the Project team cry must be dealt with. The worse it the problem is – the better we like it, so “bad news is good.”
Another favorite question, after all is settled and we’re ready to move onto doing “work” as opposed to “meeting” is “are we fooling ourselves?” “Are we drinking our own bathwater?” This is a conscious effort to avoid the DEADLY enemy of group think. Nearly nothing is worse for a team than “group think.” There are many examples, many documents, many books on the topic. But, from personal experience I can tell you – it can KILL.
MEET ME IN SAN DIEGO NEAR THE PROJECTMANAGEMENT.COM BOOTH.