I recently attended the 2016 Digital PM Summit in San Antonio, Texas, and would recommend it to any DPM I meet. As attendees pointed out regularly, there isn’t another forum like this, and it was great to be among people who knew almost exactly what your daily work life was like. The topics were all relevant, and I learned something useful from each of them. Similarly, I was impressed by the quality of the speakers: every single one was dynamic, informative, and funny.

But if I had to pick my favorite moment from the conference (besides “I’m not your secretary” from Digital PM Summit founder, Brett Harned, which struck a chord with everyone) it was this line: “Planning is more valuable than plans”, courtesy of Jack Skeels, founder and CEO of AgencyAgile, in his presentation titled “Breaking Down the Iron Triangle”.

I loved this line because it underscored my own experience. Over the years, I’ve found that the more detailed my original first-pass proposal schedule, even though I rarely kept to that schedule, much less shared it with clients or even team members, the better my grasp of and ultimate success with the project.  

Good scheduling requires digging into the nitty-gritty, being explicit about the transitions from one stage to the next, and not dismissing any step with the intention of working it out later. The process of thinking through the specifics of what a given team member might need to start his or her job often alerts me to hidden scope. It’s kind of like archaeology, where an entire underground city is revealed after the discovery of a single pottery shard.

Even if I have to make my best guess about a scope of work or an approval process, and schedule to that, that guess provides a baseline against which the real thing, once revealed, can be immediately judged.

For example, suppose an RFP requirement indicated that “several” data sources need to be combined into a single data feed. The temptation is to avoid deep thinking about this at the proposal level. But if I make my own scoping schedule, working backward from a delivery date, and I get to the week where a developer will actually need to begin building this data feed, I’ll start to think about what we’d want to have ready for him or her.

So, I think, we’ll probably need to get specifications for, administrative access to, and draft a data map of the existing fields to the new fields in our application. In addition to our mapping work, we’ll have to get information from the client, who might, in turn, have to coordinate with some other department. I’ll estimate, then, that this will probably take at least ten business days for the first data source.

Then I might wonder “how many data sources are ‘several’?” If I’m unable to find that out, I’ll guess at six. I’ll add two business days for each additional data source, mostly for mapping and question resolution time. So that’s 10 days for the base lead time, plus another 10 to cover the additional feeds. Ideally, then, I’d want at least 20 days/4 weeks lead time before we start that aspect of development.

This kind of thinking may seem needlessly detailed, and the time may or may not be possible from a business perspective, but at least I know what would be ideal, and can manage around it. Most importantly, it means I’ve thought about it well in advance and won’t panic when a developer asks to be pointed to that information two days before she is scheduled to deliver the component.

So, thank you to the DPM Summit 2016 for making me feel better about all the super-specific and (I’ve been told) occasionally premature questions I’ve asked over my many years as a digital project manager. 

And for the food. The food was really good.