Last weekend I wanted to read “The Goal: A Process of Ongoing Improvement” by Eliyahu M. Goldratt again. It’s been a few years since I had, and it was one of the first books that really helped me to internalize many of the concepts I take for granted today.
I was delighted to find it on Audible.com, especially because I’m already a Platinum member and get a few audio books per month as a part of my subscription.
I listened to the sample, and it sounded good so I grabbed it.
It was even better this time around. The production was great, and it was great to get re-acquainted with Alex and his crew in this wonderful novel. I’d like to share some of my thoughts on the book with you today.
- Perspective is Everything
- Common Practice is not Necessarily Good Common Sense
- Local Optimums are Not Optimal
Perspective is Everything
In the book, there are many occasions where the team is faced with a major problem and it turns out the solution was right there in front of them, staring them in the face.
They had to change their perspective. Ingrained assumptions were blocking everyone from making the shift in thinking necessary to find the solution.
Once they had made the paradigm shift, it seemed plain silly they hadn’t seen the solution earlier.
I have had similar revelations over the past few years, including limiting work in process (WIP) and multitasking on my projects as much as possible. Many of the strides I’ve made in terms of resource and release planning, time-boxed agile methods of working, and kanban have been a direct result of my own paradigm changes. Now that my thinking has shifted, it’s almost painful for me to remember how I used to manage my projects and lead my teams.
Common Practice is not Necessarily Good Common Sense
Many of the measures common in our professional lives do not really move us towards The Goal. In the book, a major example was efficiency. Parts of the system would be run at high efficiency in order to look productive, but in reality they were just creating large amounts of WIP that clogged the system and tied up material.
An example in my world of software development is the case where many people and organizations value a highly detailed plan over just about everything else. Isn’t a better goal to produce a quality product that perfectly meets the customer needs, on time and within budget? Isn’t everything else just window-dressing? I won’t spoil it for you, but zooming out just a bit more gets you to the goal of the organization, which is the true Goal that should be kept in mind.
Most standard waterfall-ish teams end up putting tons of effort into design and documentation up front, code like crazy, and then try to update and create new documentation at the end. The design WIP builds and builds, and by the time you start implementing you have to re-work your design anyway. And when you save documentation updates for last, you end up having to go back to the code and remember what you did in order to update the documentation appropriately. Then you release it to the customer and find out you are meeting requirements, but it isn’t really what they want or need.
WIP in software and many other domains can be thought of a perishable to an extent. The longer it sits there as WIP, the more value you waste due to rework and time to re-familiarize yourself with the WIP. If you put a set of functionality into play, you’d better be working on it, getting feedback on it (testing, customer reviews), or documenting it. Every moment you are not doing one of these things ends up as waste on your project “factory floor”.
This is a major reason I’ve been driven towards mapping the value stream of each of my teams in a visual manner using kanban as our vehicle. Minimizing WIP by focusing on one item and taking it through the entire value stream before moving to the next is a critical piece for my teams to achieve our Goal.
Local Optimums are Not Optimal
This is another critical point this book drives home again and again. It is very easy to only look at your own little piece of the system. Stove pipes rise up everywhere, with individuals, teams, and departments trying to achieve local optimums for themselves.
The only way to increase quality throughput on your projects is to look at the whole system, not just pieces of it. The broader your scope for applying systems thinking, lean concepts and others, the better chance you have at making a real improvement to the bottom line.
Daily stand-ups and a shared, visual representation of the entire project team’s work and focus is a perfect example of this principle in action. In this way (again I love my kanban!) everyone’s perspective is broadened to the team as a whole, and not just local optimums for individuals. Several times each week, my teams and I discover opportunities to enhance throughput by working together in specific ways. In fact, this week we discovered that for a portion of one system, we should actually stop work for a short time until a constrained resource (team member from another team) is freed up to work on it with us. Without the shared vision we now have, part of the team would have started work on it and created rework. Not only that, but the rework would have been pushed towards a constrained resource with a specific and unique skill set.
We may have felt productive locally getting “our part” done, but overall it would have taken more time (duration) and effort (work hours). The local optimum would have decreased overall throughput of the system (our project).
Have you read “The Goal” yet? If not, you can get it in audio format for free by trying out Audible.com
today.
What’s The Goal? is a post from: pmStudent
I love to help new project managers and working project managers further their careers.
I also offer online project management training for you!
Leave a Reply
You must be logged in to post a comment.