Tag: planning

I’m reading Creativity, Inc. by Ed Catmull. One of the reviews I read before starting the book simply said, “When Ed tells a story, you listen.” I’m finding a lot of truth in that sentiment.

The chapter I read today more eloquently put what I’ve tried to express in the past when it comes to managing web development projects. Unlike air travel — the consequence of failure is extremely low and the proposition of failure makes the work better.

Moreover, you cannot plan your way out of problems. While planning is very important, and we do a lot of it, there is only so much you can control in a creative environment. In general, I have found that people who pour their energy into thinking about an approach and insisting that it is too early to act are wrong just as often as people who dive in and work quickly. The overplanners just take longer to be wrong (and, when things inevitably go awry, are more crushed by the feeling that they have failed). There’s a corollary to this, as well: The more time you spend mapping out an approach, the more likely you are to get attached to it. The nonworking idea gets worn into your brain, like a rut in the mud. It can be difficult to get free of it and head in a different direction. Which, more often than not, is exactly what you must do.

TBT – Repost: Why Scrum Makes Planning and Estimating Worse, Not Better

Constraint based planning does not and cannot work in an industry without constraints. So, how do we plan without constraints? You can’t.

Planning is based on what you know prior to embarking on the journey. If I told you to pack a bag tonight because tomorrow we’re going on a trip, what would you pack? Oh, you want to know where we’re going, how long we’ll be gone, and what we’ll be doing? In other-words, you want me to provide the constraints of the trip so that you can plan accordingly?

I don’t know how to plan without constraints; and from what I’ve found so far no one does.

Making Headway – The No Time Solution

Everything is completed by performing a series of tasks. To plan, estimate, forecast, etc. we most often predict the tasks we’ll perform to get the desired outcome, then sequence them, assign resources, and guess at a duration for each. In this model – we’re predicting the future and how we’ll get there. And for anyone who’s done it—or read about it—that’s a terrific way to fail. Why we almost always achieve the desired outcome, how we get there (and how long it takes) is vastly different from what we had planned. Again, this is because we can’t know unknowns (timing), time doesn’t scale, and we can’t control time (it’s an absolute).

TBT – Re-posting: Software Estimation

My debut to the software world was about seven months ago. Prior, the projects I managed had tangible assets: prints, videos, landscapes, structures, etc. Obviously in the software world there are no longer physical structures or tangible assets. This alone has been the most difficult hurdle to deal with… not because you can’t ‘see’ the project; but because the project idea is no longer bound by constraints.

You’re Not Late—You’re Using the Wrong Metric (Yes, Time)

If there’s one metric that used more than any other, it’s time. Time is unique in that we all have a limited and finite amount. You can’t make more time, stockpile it, refund it, or spend it faster. Time is priceless.

Its usefulness as a metric is convenient because it’s constant. One hour today is the same thing as one hour tomorrow. Costs, productivity, effort, etc. are driven from time based metrics and used to forecast spans of time (months, years, decades). We use time to plan—and thus—we use time to watch and control the present; as well as, benchmark the future and past.

As a project manager, I’m always dealing with time. And as a project manager, I’ve realized that while time is a constant in the sense of measuring the void of space; it is not a human constant. Businesses are nothing more than a group of humans and thus susceptible to all things humans are susceptible to. And in lies the focus of this aside—I think we (from a business sense) have misinterpreted how to use time. Time is not the best way to bill, pay, measure, quote, plan, manage, or lead. My reasoning for time being a poor metric I’ve broken into three parts; timing, scalability, and control. What follows is then my suggestion on how we move forward.