What Does God Think About Project Management?
This is a good post by Mike Anderson at the Resurgence.
Government Health Care and Project Management
In a recent column on health care, Thomas Sowell writes:
It is not uncommon for patients in those countries to have to wait for months before getting operations that Americans get within weeks, or even days, after being diagnosed with a condition that requires surgery. You can always “bring down the cost of medical care” by having a lower level of quality or availability.
That last sentence is very illuminating. You will notice the same pattern that I blogged on in regard to project management a few weeks ago. In that post, I noted that there are three constraints on anything — cost, quality, and time — and you can have two but not all three. If you need something cheap, then you will either have lower quality or a longer schedule. If you want something fast, you will either have lower quality or higher cost. And so forth.
This reality exists in health care as well as project management; it exists anywhere that you have to utilize resources. So, in regard to health care, Sowell notes that many schemes to “bring down the cost of medical care” do so by decreasing quality or increasing the time it takes to get scheduled for important surgery and care. Yet, these schemes often talk as if there is no trade off.
We ought not talk about these things as though we are operating in an unconstrained world, as though having the government step in will magically result in cheaper health care, with the same standard of quality and the same speediness of implementation.
Now, I do think it is possible for health care to get cheaper while preserving excellent quality and timeliness. We have seen this happen, for example, with computers (and technology in general) — costs have gone down, while quality and performance has gone up, and you don’t have to wait in a breadline to get one.
But how did that happen? Through innovation. The cost of health care can come down — while preserving quality and timeliness — through innovation. The question then becomes: what environment is most conducive to motivating the innovation necessary to do this?
It doesn’t come from the government. Notice, again, the tech industry — it is not governmental controls that led to the creative and risk-taking entrepreneurship behind the creation of Apple, Google, and the thousands of other companies (even Microsoft) that have transformed our lives through technological improvements. Rather, it was the opposite — letting them be free to create, pursue, fail, regroup, and make things happen.
I don’t know why it is so hard to learn this lesson. We see it every day, and now the Internet itself is one of the best examples of it — it is through decentralization that society advances, not centralization of government power over an industry.
The greatest irony is that many of the people who get this when it comes to the tech industry, the Internet, and entrepreneurship fail to see the connection when it comes to every other area — such as taxation and, the main issue here, health care.
The Four Categories of Information You Need to Pay Attention To
There are four categories of information you need to pay attention to when embarking on any significant endeavor:
- Things you know and know that you know.
- Things you know but don’t know that you know.
- Things you don’t know and know that you don’t know.
- Things you don’t know and don’t know that you don’t know.
Category four is what can be the real curve ball. The early space program is often given as an example of this: before we went into space, there were certain things we knew and could plan for (radiation, re-entry, etc.). But what were the things that we didn’t know that we wouldn’t even know were factors until encountering them? That was the challenge.
Which is why experimentation and trying things, sometimes in small steps, is so crucial. Since you can’t discover the things you don’t know that you don’t know any other way than by experience, taking action and embarking on paths of experimentation are essential to learning, for individuals and organizations.
This means that, to a certain extent, we need to be willing to tolerate risk and we need to be willing to tolerate failure.
The 3 Constraints on Every Project
Every project — every endeavor in organizations, society, and life — operates within three constraints:
- Quality
- Schedule
- Resources
Quality means how well it is done. Schedule means time — how long it takes. And resources means people and financial cost.
Here’s the meaning of this: these constraints are interdependent. And so you can hit it out of the park on any two of these areas, but not all three.
For example, if you want the end result to be very high in quality and done very quickly, it’s going to cost you a lot. Or if you want to use as little resources as possible, it’s either going to take you a very long time or you are going to have to sacrifice on quality.
You have to choose your priorities.
Reasons Projects Fail
Here are some main reasons projects fail, from To Do Doing Done:
- Unclear goals or objectives
- Changing scope
- Insufficient resources
- Conflicting priorities
- Lack of knowledge
- Poor communications
- Lack of leadership
- Lack of management support
- Lack of teamwork
- Poor planning
- Political issues
The Value of Being Able to Execute Projects
From To Do Doing Done:
“In our increasingly demanding world, the people who succeed will be the ones who can initiate and complete challenging projects. They will be the ones who know how to create a vision that engages everyone involved in the project.”
Key Notes from the Art of Project Management
Scott Berkun’s book The Art of Project Management (now issued in a new edition and renamed Making Things Happen: Mastering Project Management (Theory in Practice)) is the best book I’ve read on project management. It is fantastically helpful.
The other day I came across these brief notes I had jotted down a while ago from the book. They are very incomplete, hitting on just a few of the key things that stood out to me.
But sometimes, that’s what can be most helpful. So here they are, in case they might be timely for you as well:
- Requirements vs. specifications. Requirements are the what, and specifications the how.
- The three perspectives: Business (including marketing), technology, and user. User is most important but also most often neglected.
- The importance of planning: “Plans provide an opportunity to review decisions, expose assumptions, and clarify agreements between people and organizations. Plans act as a forcing function against all kinds of stupidity because they demand the important issues be resolved while there is time to consider other options. As Abraham Lincoln said, ‘If I had six hours to cut down a tree, I’d spend four hours sharpening the axe,’ which I take to mean that smart preparation minimizes work.” (p. 41)
- On thinking outside the box. It’s not always best to say “think outside the box.” Eliminating boxes is not necessarily the hard part—it’s knowing which boxes to use and when to use them. Constraints are ever present. Art of Project Management, 93. “Do whatever you want with the box. Think in the box, out of the box, on the box, under the box, tear apart and make a fire out of the box, whatever, as long as you manage to solve the problems identified as the goals for the project” (p. 94).
- Where good ideas come from. To generate good ideas, ask good questions.
- Open issues list: “An open issue is anything that needs to be decided or figured out but hasn’t happened yet. It’s essentially a list of questions, and it should encompass anything that needs to be done, prioritized by its potential impact on engineering” (123).
- Different types of requirements and specs: Requirements, feature spec, technical specs, work-item list (the description of each programming assignment needed to fulfill the feature spec), and test criteria and milestone exit criteria (prioritized cases for the new functionality, along with goals for how well the code needs to perform on those cases to meet the quality goals for the milestone).

