I'm writing from the frozen northeast USA, where we've had more than the usual amount of snow packed into two weeks.
The CIO's Guide to Breakthrough Project Portfolio Performance: Applying the Best of Critical Chain, Agile, and Lean by Michael Hannan, Wolfram Muller, and Hilbert Robinson is a good, short description of how to take ideas from several disciplines and apply them to an overall portfolio management approach. (Disclaimer I know two of the authors, though I did buy the book.)
The authors start out describing the three most important objectives of portfolio management:
- Selecting the right projects
- Maximizing the portfolio's throughput of project completions
- Optimizing the portfolio's reliability of project completions
And the rest of the book clarifies what they mean by each of these objectives.
How to help selecting the right project? The authors discuss the TOC Throughput Accounting idea of "throughput per constraint unit" - basically reviewing how much time projects consume on the system's constraint compared to the value of the project. They also add in a consideration of the investment required to deliver the project, which they calculate as an "effective ROI". Interestingly, there is a similar concept in the Factory Physics approach (I'm reading Factory Physics for Managers).
I also like that they talk about analyzing potential projects from the TOC perspective of how the project will impact the constraint of the overall system. There might be a project portfolio constraint - the resource that limits the ability of the portfolio to flow more and more projects. And there will be a constraint at the business system level - these are not always the same thing. When they are the same resource, care must be taken in deciding on projects: will the operational needs of the finished project reduce or increase the demand on the system constraint? Are projects that require significant capacity from such a resource the best projects to run? If it is unavoidable that the constraint must also be on projects, there are a few strategies: make sure those resources in particular are focused (no multitasking!); make sure all other resources do what they can to support the constraint; and finally, if necessary, develop more of that constraint resource (training, hiring, etc).
So once you have selected the right projects, the focus becomes on ensuring they complete quickly and reliably. The more of the right projects that finish, the more value the portfolio will deliver to the organization. The focus here is has to be on ensuring projects are released to take advantage of the capacity of the constraint of the whole portfolio of projects: don't release more work than the resource can safely handle. Don't force your most precious resource into the situation where they are forced to switch from project to project to project without finishing the work of the moment. (This doesn't mean that they should have only one project - they should have only one TASK at a time.)
The authors describe a series of changes in planning and execution of projects that will create more and more benefit to the flow of work. In the conversation, they suggest an original portfolio that finishes just three projects in 17 weeks could be rethought into finishing sixteen projects in those same 17 weeks. People familiar with CCPM will find the discussion quite familiar: staggered release based on the constraint; reduce multitasking; elimination of internal task promise dates (change to finish as quickly as possible). There are also ideas in the Agile community that can help speed the throughput of projects.
Not only do they use familiar CCPM methods, but they also suggest bringing in the idea of Value Stream Analysis to the project design: particularly for information technology projects, it is often the case that the IT organization is asked to automate an existing business process. Rather than strictly automate it, a VSA would suggest places where the process could be improved to eliminate or reduce the number of steps. Not only does this make the business process better, but the resulting technical component is often simpler and much more in alignment with the needs of the business. And the project can be faster.
Finally, many of these concepts have to do with planning. Execution is just as critical. CCPM project execution techniques and tools help people focus on the key work required to bring projects in on time. In addition, one of the authors of the book, Wolfram Muller, also wrote Taming the Flow, which talks a lot about how to turn these ideas into "ultimate Scrum" to maximize the flow in software development.
And it is in execution where the third objective comes into play: reliable project completion. Again, from CCPM comes the idea of project buffers and using buffer status as a primary mechanism for providing status and focus. There are also scope buffers (backlog management) and budget buffers to help direct money to the places that need it.
And these buffers and the resulting information help at another level. Collecting information over time as to what most often causes significant buffer consumption is a great way to look for longer-term improvement opportunities.
The book isn't going to answer all the questions on how to make this happen, but it is a great introduction to the concepts and gives a good starting path. I particularly like that it shifts the conversation away from project management - implications on managing projects. In a portfolio, it is just as important to be flowing the right work in the right way for overall success.
Finally, they have a nice analogy in talking about "local efficiencies" and task-level promises. They extend the familiar (to me) idea of a project as a relay race. Everyone wants to do their best in the environment they are in. But what does that mean for the leg that the individual runner is on?
No runners are asked to commit to a specific time or speed - and if you did ask them, they would likely look at you like you're nuts, because all athletes know that performance will vary from one race to the next.
Just like in knowledge work. And most project work is knowledge work these days.
I haven't completely forgotten knowledge management. My life happens to be tied up in the process side of things these days, but KM hides under the covers of many conversations I have with people. How do we make sure the right people know how to operate?
As such, Arthur Shelley posted his 12 Principles of Knowledge Leadership to a KM mailing list - turns out he wrote this a year and a half ago. Good reference material!
12 Principles of Knowledge Leadership is a great place to start you practice of becoming more successful:
- Enhance performance
- Be the (knowledge) leader you want to serve - Channelling Gandhi there!
As usual, go to his website for more details on each of these. I could argue several of these apply well beyond knowledge management.
Henry Camp has created a nice two-page summary of Theory of Constraints and made it available for all to use. I've posted a copy here (with permission): TOC Reference Sheet. His idea behind creating it was something that people could print and laminate for quick reference.
This covers TOC topics that Henry cares about, which is most of them. He covers the 5 Focusing Steps, the Pillars (he counts 5 instead of 4), Constraints, Layers of Resistance / Buy-In, and easily half of the content is related to the Thinking Processes. Interestingly, he doesn't explicitly include the supply chain or manufacturing applications, which is a bit surprising given his background and success with supply chain implementations.
Henry has been involved in Theory of Constraints for at least 10 years. I met him through his colleagues from IDEA LLC and then at a couple TOC ICO conferences.
Pascal-Emmanuel Gobry has some nice praise for Theory of Constraints and The Goal in This simple theory from an Israeli genius will revolutionize the way you think about business (November 2014, The Week).
TOC is the brainchild of an eccentric Israeli physicist, Eli Goldratt (now deceased), who produced the business novel The Goal, which became an underground bestseller and allowed him to devote himself fulltime to consulting and elaborating on his theory. Once I understood TOC's power, it came as no surprise to find out that Jeff Bezos, the greatest CEO alive today, makes all his senior executives read The Goal.
The brief article is a familiar statement that Bezos has his senior executives read The Goal. The rest of the article does a nice job of describing TOC to people who may not be familiar with it.
What I would love to see is someone dig into HOW Amazon is using the ideas of Theory of Constraints within their operations. Given that they are primarily a sales and distribution organization, I would imagine that the supply chain application is where they would focus. But they have a lot of moving parts. The Thinking Processes, Critical Chain Project Management, Strategy and Tactics, and more could all be valuable techniques within the organization.
Has anyone written that article?
What is the goal of a company? In the Theory of Constraints approach, this is one of the first questions to ask - even before you start down the path of the Five Focusing Steps (5FS).
The first of the 5FS guides one to "identify the constraint of the system," which means you need to understand the system. And the "constraint" is the thing which is preventing the system from achieving more of its goal. Ah, the goal.
Again, in the TOC community, the goal has usually been generalized to "Make more money, now and in the future." This generates a lot of conversation and discussion, as the terms are unclear and people react strongly to thinking that the only goal of a company is to make money. Isn't there some kind of higher purpose? To see how much discussion this generates, have a visit to LinkedIn to see the conversation Is "making money now and in the future" the real goal of a company? It started 11 days ago and already has over 150 comments. This isn't the first time I've seen a conversation like this - and it probably won't be the last.
I happen to like Kelvyn Youngman's discussion of the Japanese Perspective on this kind of goal. Not all cultures see this question the same way. And outside of Theory of Constraints, the question of the purpose/goal of a company is an ever-popular conversation. Steve Denning talks about it in his thinking about Radical Management and in Is the Goal of a Corporation to Make Money? on Forbes. There are many other discussions on the topic as well.
In the last ten years or so, Goldratt and the TOC community developed the Viable Vision concept and modified the goal to become an "ever-flourishing company." (There are two nice videos of Eli Goldratt talking through this topic: Part One and Part Two.)
I've been pretty quiet here lately, though I often wake up thinking of an idea that I would like to get out into the public eye here. My participation on newsgroups and mailing lists has similarly dropped off. And I continue reading business books for which I will write my reviews.
Unfortunately, life intervenes. I have been traveling a lot with client projects, and that often leaves me short of energy. The happy thing there is that I have client projects - and they keep me engaged and challenged.
I hope your 2014 has been exciting and challenging. And I hope that your 2015 brings new adventure and new learnings.
Happy New Year!
A couple recent articles in the India press related to Theory of Constraints. (Disclaimer: I have been working with Goldratt Consulting, which features in these articles.)
Capitalising on the after-market by Chandrashekhar Chaudhari in The Financial Express talks about the TOC approach to replenishment and distribution. I like the emphasis that the replenishment policies should be defined by their consumption rate. Recent TOC approaches have divided products into the fast-moving "head," the middle "belly," and the slow-moving "tail."
Companies resort to Theory of Constraints to stay ahead in the game in The Economic Times talks about several companies that have used Theory of Constraints: Doctor Reddy's Laboratories, Bajaj Electricals, Tata Steel, Godrej & Boyce, Kurlon, and Liberty Shoes. It's a nice sampling of the different applications of TOC in a wide variety of businesses. My only question is why they use the phrase "resort to" in the title - at least in my interpretation this suggests that TOC is a method "of last resort," rather than something you go to first.
And this interview with Rami Goldratt in The Economic Times reminds everyone that TOC is primarily about focus: both what not to do and what to do. The article seems to be disjointed pieces of a conversation, but it gives a quick introduction to many of the ideas that appear in Theory of Constraints: focus, constraints, projects, innovation.
How do you feel about your work place? Are you excited about the people and the work? Or have the well-meaning policies and ineffective "improvements" grown wearying? Even worse, have you started dreading going to work because of all the chaos? Depending where you are, reading a story about such a situation could be painful or it could be very engaging.
Linda Seed finds herself thrust into the leadership of a hospital that seems to be stuck in perpetual chaos in Pride and Joy by Alex Knight (book website). And for me, I found the book quite engaging - I didn't even take time out to write many marginal notes.
Pride and Joy is a business novel written by a long-time Theory of Constraints consultant. The characters in the story do not talk about TOC directly. Of course, they use TOC principles and concepts, but the focus is on telling the story and showing how those various principles might fit into a larger whole. Of course, since this is a TOC novel there is a business that is failing (the hospital), a guru character (Linda Seed's graduate school friend - who works for free!?!), and some minor outside-of-business life plot elements.
Knight does an interesting job of showing the high level process of describing What to Change, What to Change To, and How to Cause the Change which is a core way of thinking within the TOC community. This is also connected to how people react to proposed changed: if they don't understand the "what to change" or the direction of the change, the specific steps to get there are going to look suspect. Not only at the overall view of the organization, but as people or departments come into the picture, Knight shows what happens if you skip steps here (people resist change). And how those same people can become true believers, if you take them through the thinking and incorporate their perspective on building the solution. "Treat people like adults" is a theme that Knight repeats a few times.
While Knight didn't mention Theory of Constraints in this book, he clearly articulated some of the more recent concepts that have come out of the TOC community: flow and core TOC beliefs. He talked about flow - in this case the flow of patients through the hospital - and throughout the story, I picked out several ways in which the Four Concepts of Flow apply (more detail on these in an early blog post).
- Improving flow (or equivalently lead time) is a primary objective of operations. - Shorten the time people are in the hospital (usually waiting for someone) to ideally what is only clinically required.
- This primary objective should be translated into a practical mechanism that guides the operation when not to produce (prevents overproduction). - Difficult to do directly, as the incoming flow to the hospital is not in their control. But they still described a few actions to help this.
- Local efficiencies must be abolished. - There were many examples of local optimizations that significantly damaged the overall flow of patients: batching, blanket budget cuts, etc.
- A focusing process to balance flow must be in place. - They designed a buffer management system designed around the flow time for each patient and used it to drive priorities everywhere.
The other aspect is the TOC core beliefs. The guru character in the story articulates a number of these explicitly as he is talking to other characters, and others of them come out in the story. I'm not sure what these are called exactly, but they largely come out of thinking around "inherent simplicity" of systems. This is best articulated in one of Goldratt's last books, The Choice (my re-review from earlier this year)
- Reality is exceedingly simple
- People are good
- Every conflict can be removed
- There is always a win-win (solution)
- Every situation can be substantially improved
One aspect of the story that didn't get emphasized was a clarity of thinking that came as the characters started describing the problem. Specifically around the goal of the system: why does the system exist? Why do we do the things that we do? The characters in the story went from all the measures and rules to becoming laser-focused on the patient and the policies/practices that get in the way of that focus. I would have been interested in some discussion of how they clarified the goal. Maybe for hospital personnel this is already clear, but I suspect not. Having a well-articulated, shared understanding of the goal of the system helps start the discussion of what to change, what to change to, and how to cause the change. It is often listed as "step 0" of the TOC five focusing steps.
Why Pride and Joy? By the end of the story, Linda Seed and her colleagues are once again excited about the work they are doing. Characters who were considering retirement or career changes are reenergized in their work at the hospital. The place is becoming a point of pride for the characters.
This book is similar to a previous hospital-focused TOC novel, We All Fall Down (my review from 2008). In that story, the TOC elements were much more in the fore. And the specific solution developed in the story went in a different direction because the problem they were solving was different. I kept thinking of that solution in the context of this book, because I suspect it could have been a small part of the larger effort described here as well - but diving into those specifics would have detracted from the story presented in Pride and Joy.
An interesting crowdsourced challenge came across my screen the other day. InnoCentive is hosting this particular challenge on Capturing Institutional Memory and Knowledge:
The Seeker desires suggestions and best practices for knowledge management in a corporate setting. As employees age and retire, valuable knowledge is often lost. In addition, with the realities of today’s workplace, employee turnover needs to be expected. How can a company proactively capture institutional memory and knowledge, and make sure that it is not lost?
The due date is 14th of October, and the website is showing over 300 active solvers to this point.
I originally heard about Freek Vermeulen's Business Exposed: The naked truth about what really goes on in the world of business from the HBR Ideacast with him - go there for a nice summary of the book and his take on the world.
Vermeulen casts his skeptical eye across many familiar practices to debunk our beliefs in the value of those practices. I particularly like that he largely uses published research from a wide variety of business school researchers to show these things. It also helps that the tone of the writing makes me think Vermeulen was smiling as he wrote, which makes it enjoyable to read as well.
Vermeulen takes an extreme angle at times, just to get the reader to tilt their head with a quizzical look on their face. He even touches on some topics relevant to my work, including knowledge management.
On knowledge management, he repeats some of what he wrote in a 2009 blog at HBR, When KM Hurts. My take is the same thing many people in KM have been saying for years, gathering "knowledge" (mostly documents) for the sake of having a massive database doesn't particularly help anyone. It is the context, the situation, the experiential knowledge that are so important to the ability of a knowledge management effort to add value to an organization. His recommendation in this makes perfect sense: stop spending so much time and energy on collecting stuff. Rather, setup "systems that help people identify and contact experts in your firm, because that can sometimes be helpful." In the research he cited, KM-like systems were most helpful for people new to the firm. He also cited research that suggested experienced people who hop from one company to another are at a significant disadvantage in terms of performance until they develop their networks within the new company.
Me-too-ism is not a term that Vermeulen uses in the book, but it seems to be connected to a number of ideas he exposes as not quite right. Many companies adopt the latest management fads just because other companies are doing it because they don't want to appear to be behind the times - even if the approach isn't appropriate for their circumstances. For more fun, Vermeulen points to research that shows companies who adopt the latest trends do well on the "Most Admired Companies" lists - regardless of the actual performance impact of the trends. Or other research that showed merely announcing you were going to do something with corporate social responsibility had a positive impact on analyst coverage and the stock price.
A similar idea that struck me is that companies tend to pay close attention to what industry analysts say about them, largely because there is a strong correlation between analyst coverage and stock price - if an analyst covers your business, your stock price goes up. This means that if the analysts don't understand your business, they won't cover you or they will give you poor ratings. This applies even when the business is well-run and doing sensible things for the business. As a result, companies find themselves reorganizing to follow trends that analysts understand.
In the world of product development and software development, customers often come to you with a request for specific things. "It should be green with four wheels." or "Build me a web site to sell my origami." or "It should work just like Google." The thing is, these are specifications or requirements. They could describe just about anything, and often the result doesn't quite do what the customer was thinking of. Why is that?
Partially, this is due to the very familiar problem that people don't know what they want until they have it. One of the reasons that Agile development methodologies have taken hold is to try to solve some of this. Work with the customer directly, create prototypes and iterate, iterate, iterate.
Another direction, inspired for me by Theory of Constraints, is to develop an understanding of why they want these features. Rather than describe the solution - a description that is always going to be lacking - understand what problem they are trying to solve. What limitation or barrier do they need to overcome? And why do they want to do that? Knowing this, it is much easier for everyone in the process to understand what features / capabilities are truly needed to solve the problem and which might be nice-to-have. This doesn't eliminate the need for iteration - it helps people focus on the customer's needs.
[Photo: "scope" by ben dalton]
Clarke Ching has been working in public on his book, Rolling Rocks Downhill, for quite a while. I've read at least one version of it. Last week, he posted an update of one of the chapters where one of the ideas of the book come together: That (software) developers are creating recipes for a cake, rather than baking the same cake over and over. This implies one should be careful about applying manufacturing concepts in such a world.
Here is a quote from Where it all went wrong:
'Okay. Here's the bit that puzzled me. Development teams in other industries start iterating - and therefore testing, since testing is an intrinsic part of iterating - very early in their development processes. They cook version 1 of the cake, test it, tweak the recipe, then cook version 2, and so on. They test throughout the entire development process, but you computer people don't start testing - or iterating - until mid way through a project. Why is that?'
Why do (software) developers act as if the recipe is fixed, when it clearly is not?
Dave Snowden has written and talked about a parallel to this problem many times in the context of knowledge management. Are we asking people to simply pick up an item from a knowledge repository and re-use it (like we might see from someone following a recipe)? Or do we want people to develop enough expertise and understanding to be able to see the key bits of many recipes and create their own (the chef)?