I’ve been managing projects for about 30 years or so, far longer than I’ve been writing about it. Along the way, I’ve collected a few useful thoughts that never made it into an article or blog post or book. At first, I was just jotting notes on paper. Then I took to creating short text files, saved to a folder. The last few years, I’ve been using OneNote to capture those fleeting thoughts. Here are a few of them.
Managing Estimate Risk
One of the reasons estimates rarely correlate to execution is the phenomenon of dependency. Few people who “do” for a living are comfortable incorporating dependencies on the “doing” of others into their estimates. Whenever you hear software developers object to preparing estimates, you will almost certainly hear something about evolving or emerging requirements. As a portfolio manager, I always struggled with the amount of time it took for the attorneys to finish approving contracts. If these dependencies are indeed risks to schedule, then they should be treated as such. This is especially true if the project has a “finish by” date, and you need to avoid letting someone who is a marginal player consume too much of your timeline.
Bottom line: When you deliver an estimate, make your assumptions, dependencies, and other sources of risk visible to the people who asked for it.
The pace of business has increased dramatically in the last couple of decades. In many organizations, the trend is for the workforce to evolve and become more virtualized, work in progress to be continually re-prioritized, and the market to shift quickly in directions that can’t always be anticipated. We should anticipate that teams will be continually reformed, roles will change, goals will change, and so on. To bowdlerize the Dread Pirate Roberts, “Get used to uncertainty.”
The goal of estimating should be to reduce uncertainty to a level where decisions and commitments can be made. Not commitments to a precise cost or schedule, but simply to proceed, in pursuit of specific benefits. And that decision to proceed must always be contingent on evidence of progress commensurate with expectations. We should not manage on a ballistic trajectory, where nothing can change between pulling the trigger and impact on the target. Like modern guided missiles, continuous corrections must be made in order to optimize the effects of scarce resources—human, financial, and calendar.
Bottom line: Estimates without assumptions, a definition of done, or a specific way to measure progress contribute little to the goals of reducing uncertainty or achieving benefits.
Scope Management Means Saying No
I had a stakeholder on a recent project who insisted that he needed a change in scope, or the project would have no value to him. Naturally, I asked why it wasn’t part of the original scope. He insisted that it should have been, but it was “overlooked.” I said I would follow up and get back to him, but he insisted on a commitment from me. I reminded him that scope changes require approval from the steering committee. He got hostile; I stared him down, and he stormed off. When I reported his request to the sponsor, she said that the matter had been addressed before the project was funded, and it was removed in order to reduce cost and schedule.
Bottom line: Start with “No,” and you won’t have to walk back a bad “Yes.”
Opportunity versus Perfection
You don’t stop updating software because it’s perfect, but because there are better uses for your time—better opportunities. Perfection is overrated; opportunity is not. Every day you don’t have your product in the marketplace is another lost opportunity.
Bottom line: You don’t have to succeed every time, but if you miss enough opportunities, they start to avoid you.
For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager
Are you involved in a data conversion project? Then check out Dave’s indispensable book: The Data Conversion Cycle