I’m feeling guilty for being a little late on this post. Went to a class last week and I’m getting ready to go on vacation. Hang in there with me during June as I will be travelling.
I took a great class on being a Scrum Product Owner from SolutionsIQ in Redmond last week. I want to share my class experience because it provided a great example of how agile is important to project managers who want to find the other side of risk. Agile structures your work so you are constantly challenging uncertainty to drive out opportunities.
The class content was great, the instructors were engaging and knowledgeable, and the class was run in a way that allowed students to learn from one another. At the end of the class, I was happy with what I learned. But, I paged through my class notebook and saw lots of pages we didn’t cover. They all looked like really interesting ideas. Was the class a success from a project management perspective? This is the project manager’s dilemma with agile. How do we commit to scope, schedule, and budget to meet our client’s expectations? Let’s look closer.
The class was run as an “agile” class. We used the agile Scrum process to understand and decide on what we wanted to learn within the curriculum; and how we learned it.
Time and cost were fixed constraints. We finished on time and the class cost exactly what it was supposed to cost. We got a book of slides and articles at the start of class – the potential scope, but we didn’t cover all of them. But, everything in the book seemed important. Shouldn’t I expect everything in the curriculum to be covered? Would we be successful if we didn’t cover all the slides made available? How much scope we could complete within fixed time and budget constraints was an uncertainty. Sound familiar? Continue reading →
On Tuesday, I presented on “The Other Side of Risk” to my friends at PMI Olympia – our local chapter of the Project Management Institute. Lots of familiar faces – well, not lots, but enough – showed up to hear what I had to say. I told them that a perfect outcome for me would be if they left with some new ideas and I learned something. So, I think it went perfectly.
I rambled on a bit trying to cover too much ground. As I worked on my presentation over the couple of weeks preceding the big night, I kept refining it so it had a clearer theme. Since it was about “The Other Side of Risk” an obvious theme would be to find opportunities during risk management. I probably could have filled a comfortable 50 minute presentation with just that topic. That was part of the presentation, but I seem to always go for more. I got into different ways to present the idea of perfect outcomes and a perfect journey to get there. I added ways to understand perfection in a useful way, define perfect outcomes, turn risks into opportunities for perfect outcomes, and define perfect journeys to perfect outcomes so that the scope of the project includes all the stuff you need to do to get to perfect outcomes, not just deliver a product. Continue reading →
I’ve been thinking a lot this week about how organizations change. The bottom line seems to be that successful change comes from people pulling it in. You can’t push change in. Do our projects focus on push or pull?
I’m part of planning for a project where thousands of people will have to change how they do their work. The old system is about 30 years old. The change will require thousands of people to redo 30 years of process and system connections to unplug the old and plug in the new. How will they get ready to do this?
For the past several years I’ve encouraged all my clients, and now my co-workers, to adopt agile methods on their projects. I also encourage it for any work, like software maintenance work, that can be organized as well-defined sets of tasks that are completed in a time period. In my experience, all work groups that use a good agile methodology as it’s meant to be used end up more productive and happier, too. My inspiration to write about agile today, though, comes from a different place that further proves what a good practice it is.
A new book by Bruce Feiler, “The Secrets of Happy Families,” encourages families to adopt an Agile Family Strategy. Bruce got this idea talking with a software engineer in Idaho, David Starr, who moved his family from dysfunctional to functional by bringing home his agile software development practices. Bruce tried the same agile techniques as well as lots of other good ideas for happy families and also had great success. Both Bruce and David found that what worked for software developers and their clients worked for families with kids, too. Agile’s simple consistent practices focused the family members on helping each other, being accountable, planning things to do in realistic chunks and getting them done, and involving everyone in setting rules and making decisions. Everyone was happier, more productive, and appreciated one another. This is what we want at home and at work.
The first chapter of Bruce’s book is the Agile Family Strategy. Bruce thoughtfully cited a paper published by David and Eleanor Starr – “Agile Practices for Families” – which I found on the Internet. I read the preview chapters of Bruce’s book on Amazon and ordered it for my son’s family. Russ and Kellie do a great job with their three young daughters. I saw this book as affirming and expanding their family practices. Being a software development person, I especially liked the Starr’s paper. It clearly linked agile methods (derived from the Toyota Production System or “lean”) to a realistic set of practices to engage family members in a fun way to make the pressures of everyday life with kids a little less stressful.
Reading “Leadership Freak” on Monday was reaffirming. Dan Rockwell wrote about leaders who achieve great success by setting a vision, bringing in good people, and getting out of the way. His primary example was Tony Hsieh at Zappos. My ideas about imagining perfect outcomes and defining the perfect journey to get there are in line with this advice.
I use “perfect” on purpose even though people are uncomfortable about it. The audio clip on Dan’s post brings out the importance of this in how Zappos decides how to “wow” their customers. On projects, we have to decide what it will be like to “wow” ourselves (everyone involved) with our results, and then define the project around that. Those who have to get it done and will live with the results are the best ones to do it. This is a way to find what can go right about a project before we focus on what to do and what can go wrong.
Thanks for the reaffirming post, Dan. Readers, be sure to listen to the audio clip on this post; and check out Dan’s preceding post on how to establish a culture that enables “Wow.”
In my new role I feel a sense of urgency to get things moving. I think this is common for project managers. We are brought in to make a difference and we are excited about that. But patience is important, too.
I’ve blogged about patience before in June and December. In those posts I advised project managers to be patient so that they build partnerships; and understand and build the capacity and commitment of their team. Then, I was still a crusty consultant advising others on their projects. Shortly after the second post, I accepted a job that requires me to help a very large organization come together in support of organization-wide business and systems transformation. Can I take my own advice? I’m trying.
To reinforce my patience, I looked for updates from my consulting guru, Peter Block, on the Internet. Peter’s books and classes have shaped my approach to what I do. Peter recently posted a video that helped.
Projects are more successful when all the participants – project managers, builders, and clients – find ways to understand and learn from one another. But, that’s not easy. Why is that? Don’t we want to understand and support one another? We probably do. But, our different perspectives can get in the way.
Most people on a project are looking for different things when they look at the project. The project manager is looking to define and manage objectives, scope, schedule, budget, and risks. The other people on the project are looking at what they will be creating or what they will have when the project is completed. They see what interests them. And, they see what they are directed to look for. Science backs up my assertion.
Listening to NPR earlier in the week, I heard a story about the invisible gorilla. It wasn’t about the 900 pound gorilla that comes to most of our project meetings that we all see but don’t talk about. (Or, maybe it was…). It was about a gorilla in plain sight that we don’t see because we are looking for something else.
Dr. Mae Jemison, Principal of the 100 Year Starship project (and former astronaut), was asked by New York Times columnist, Dennis Overbye, if she would go on a lifetime voyage to the stars. She said “Yeah” adding that “It makes a difference who goes with you.” To make the long voyage, she says that “We will bring our culture along with us.”
The 100 Year Starship project (www.100yss.org) was established recently by a group of stellar people to imagine and plan a real trip to the stars. After all, imagining, planning, and completing our trip to the moon triggered research and implementation of television, the Internet, satellite communication, revolutionary medical procedures, and even cultural movements that have changed our lives. Once started, the trip to the moon and back was completed in a matter of days. The 100 Year Starship project is imagining a trip that will take a generation or more. Reading about it, the thing that jumped out at me was not that the project has to find amazing technological breakthroughs; it’s that they have to figure out how people on such a trip can live and work together productively. They have to think about (from www.100yss.org): Continue reading →
Dan’s post provides a guiding principle for finding what can go right on your project: you have to ask. Too often projects start off with the scope, schedule, and budget predefined. The charge is “We can do this!” Then we don’t or pretend we did. A project starting this way spends it’s time and energy protecting itself with risk mitigation, change orders, and blame shifting. Starting, as Dan suggests, with “Can we do this?” gets the team to explore the challenge, it’s strengths, and opportunities for needs to be met in a realistic way that improves the organization and its people. Thanks, Dan!
Toddlers who stumble and fall aren’t broken; they need practice. Fixing is a backward-facing activity that centers on mistakes and weaknesses. Move forward; don’t fix.
Leaders grow leaders. Developing isn’t fixing. Growth suggests they aren’t there, yet. Can you live with people who haven’t arrived? Can you accept people who aren’t as skilled as you? Damn, they’re frustrating. (Sarcasm intended)
Start fresh; don’t fix.
How would you handle this relationship if this was its beginning point?
How can you address this situation as if you just stepped in?
If this moment was the beginning point, what would you do?
Is it possible to move forward without bringing up the past?
What’s the next step regardless of the past?
Imagine you were hired today. What would you do?
Baggage from the past distracts, drains, and invites defensiveness. Leave baggage at the station if: