Over the past couple of years we’ve been involved with a lot of projects and spent time developing quite a few new ideas. In other words, while it’s been a long time since I’ve posted to this blog, I think I have some good excuses. But it’s time to start up again.

Our biggest new development, created over the past year and a half, has been a set of concepts we call The Project Manifesto. My partner at ProChain, Bill Lynch, and I have written a book about them. It is a novel that describes a new way to look at critical chain and project management: through values, rather than scheduling techniques. The book should be available through various distributors, including amazon, by mid-March. Stay tuned, we do plan to do some promotions. You can also view a preview if you go to www.prochain.com/about/prochain-press/.

There are two basic ideas behind the book, and both of them come back to the primary message: Values Matter. First, most project organizations value responsiveness, getting things started, hitting deadlines, and meeting individual goals. These values are extremely common in the corporate world; chances are you and organizations you work with follow them. They also lead to many problems. In order to really improve, you’ll need to reconsider what you value. For example, is it more valuable to get started on things, or to finish them? What are the ramifications of starting more work than you can finish?

Second, if you start with an effective set of values, you can derive the need for critical chain scheduling. On the other hand, if you start with critical chain scheduling, you won’t necessary come to the conclusion that you need to re-examine your values. We often see critical chain implementations that under-perform, because they address scheduling techniques rather than the values and behaviors those techniques were designed to support.

I’ll continue the discussion of values in subsequent posts. But first, to get a sense of what it means to be focused on scheduling techniques, let’s consider the definition of the project buffer, as given in the TOCICO dictionary (James Cox, Boyd, Sullivan, Reid, and Cartier, 2012):

This is the standard definition of the project buffer, which is a central concept behind critical chain scheduling. The project buffer is protection time that we put at the end of a project (or project endpoint) to protect the project delivery (or customer) against task variation along the critical chain. You can certainly argue the details; for example, the project buffer can and should protect against other things besides critical chain task variation. But in challenging this definition, I’d go a different direction: what behaviors does the project buffer help address? If you don’t address those behaviors, how important is the project buffer? Does this definition address those behaviors?

I’ll dive into the answers, and talk about the Project Manifesto values, in subsequent posts.