ITMPI FLAT 002
Main Menu
Home / Authors / Blogging Alliance / Practical Advice for Project Managers

Practical Advice for Project Managers

BloggingAllianceButton

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.

Reducing Uncertainty

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

About Dave Gordon

Dave Gordon is a project manager with over twenty years of experience in implementing human capital management and payroll systems, including premises-based ERP solutions, like PeopleSoft and ADP Enterprise, and SaaS solutions, like Workday. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management. You can view his blog at The Practicing IT Project Manager by clicking the button below.

Check Also

How to Respond to Difficult Presentation Questions

Jerry Seinfeld’s joke on how the average person would rather be in the coffin than …

One comment

  1. Love your point about saying “no” as a part of scope management. It’s easy to say yes without considering the consequences, and those asking think little of the consequences when asking for more.

Leave a Reply

Your email address will not be published. Required fields are marked *