Last night on Saturday Night Live there was a skit in which three engineers demonstrated their invention, a machine that can translate a dog’s thoughts into words, to two investors. This is a project with complexity and uncertainty, and adaptive project management is appropriate. Did they use adaptive project management and if not, would it have improved their demonstration?
I just want to let my readers know that even though my blog has been quiet lately it’s not because I’ve stopped writing, but that I’ve been working on a book. The goal of the book, like many of my blog posts, is to provide insights on how to manage projects that have both complexity (so agile is a poor fit) and uncertainty (so waterfall is a bad fit). It should be coming out in March 2017.
My second blog post for LiquidPlanner, Why Product Development Needs Project Management, relating my experience trying to do product development with no project management process. It does not go well (though it was better than the company with too much product development process).
Any freshly minted MBA will tell you “What gets measured gets managed” a quote often misattributed to management consultant Peter Drucker. Everyone is obsessed with metrics, measuring every element of a business and making decisions based on this data. In the era of “Big Data”, this is even truer. And I’m not here to say otherwise, exactly. I’m a big fan of calculating, tracking, and listening to metrics. But I’ve seen them misused often enough that I want to throw a cup of skepticism on the fire of metrics: not enough to put out the fire, but enough to create a smoky cloud of uncertainty. The fire will keep you warm and scare the wild beasts that roam the forest, but it won’t pitch your tent or clean up after dinner.
Yesterday I volunteered at the Seattle/King County clinic, a four-day event at Key Arena where about 750 volunteers provided over a thousand people per day medical services for free. You could have dentures made, get eyeglasses, and receive vaccinations. There are also people to help navigate the health insurance system, which is no easy task.
Everyone who attended was entitled to a free pair of shoes donated by Brooks (thanks to Chris Clark from Brooks for arranging the donation and running the team for 4 days, 12 hours a day). I spent an 8-hour shift helping hand out these shoes.
In my experience working as product development consultant, I’ve learned a few things that I wish every client knew. Misunderstanding of the relationship between the client and the consultants was a common issue. Ideally it is similar to a marriage, which requires trust and communication. The better each side understands the other, the more likely the relationship will be blissful.
LiquidPlanner has published a blog post I wrote on how to create an environment that fosters innovation. I’d love to hear what you think about it.
Today I attended the Seattle Interactive Conference, a gathering of designers, artists, and other creative types. There were also a few of us left brain folks. I spent the day participating in the Design Swarm, where six teams put together proposals to speed deployment of the MSR SE200, a device that can make enough chlorine out of salt water to provide clean drinking water for an entire village. To understand the importance of this, all you need to know is that there are four billion cases of diarrhea world wide leading to 2.2 million deaths per year—mostly of children under the age of five. Even if the ideas that came out of the swarm only helped a little, this could still have an enormous impact, given the size of the problem. Continue reading “Seattle Interactive Conference”
This post was originally published at the web site of Product Creation Studio.
Last month I was invited to attend the SolidThinking Converge 2016 Conference in Los Angeles hosted by Altair. The topics sounded fascinating, and the speakers included the head of design for Fiat Chrysler, a thought leader on Biomicry, architects, artists, academics, and engineers. I went with high hopes to learn something and get a glimpse of the future. My expectations were greatly exceeded.
A version of this post originally appeared on Product Creation Studio’s web site.
This post is the last in a series of three that explores the shortcomings of common project management approaches for hardware product development and proposes an alternative.
In my first blog post, I wrote about waterfall project management. The structure of this approach allows one to effectively manage complex projects, but deals very poorly with unknowns.
In my second post, I looked into agile project management, which is a method predominantly used in software development. This minimally structured approach works well on these projects because the cost of making a mistake is low and the tasks have simple interactions. However, it works poorly on projects with long lead-times and complex interaction between elements.
In both posts I discussed how these approaches worked well for the types of projects they were designed for, but poorly for the types of projects we do here at Product Creation Studio: designing new hardware products. Most importantly, while a strict adherence to these paradigms will lead to agony and pain when designing hardware, there is still much of value in both approaches. Waterfall and agile can be combined into an effective project management paradigm for hardware development.