Is your project on schedule? How do you know?
Asking what is needed, and drilling down to a granular level of detail, can help protect you from surprises. But make sure you talk to every person, and every team, who will be affected.
Remember these two (somewhat contradictory) facts:
The only way to know if your project is on time is to dig deep into the details and discover the unknowns before they ambush you.
But even then, you are subject to the whims of completely random events so must engage in a certain amount of “disaster planning.”
What does it mean to dig into the details? I’ll talk about how I myself learned what this meant.
I've previously written about Sonia Bramwell, the best project manager I've worked with over the last 20 years. We first worked at Sherman's Travel in 2011, and it was there that I first saw her technique: to push for details, and then push for even more details, and then push for even more details.
Top leadership had made two big decisions in the May of 2011:
For 10 years Shermans Travel had leased 24 web servers in a local data center, but the decision was made that we would not renew the contract in April of 2012. We would move to AWS instead.
The existing PHP code was a complete disaster and could not be rescued, therefore we would re-write all our code as a Ruby On Rails app, plus 6 small Sinatra apps to handle certain specialty use cases, such as sending out the travel newsletter, and the interactive videos, which were the main source of revenue for the company.
All of the software engineers, including myself, got together to form a rough estimate, and we decided we could get the main app done in 4 months, with the side apps taking another month. So we would finish most of the work in October, with some follow-up work going into November. (The editorial staff was using WordPress to publish travel articles, and they would continue to use WordPress.)
But Sonia did not trust the informal method we had to use to create our estimate. By August she was having conversations with the engineers that went like this:
Sonia: Hey, where are you on the widget that generates the top 10 most popular articles?
Joel: We already did that. We've already done several "Top 10" lists.
Sonia: For the front page?
Joel: For the front page? What? I thought this was for the "Explore" page?
Sonia: No, we also do something similar for a sidebar on the frontpage.
Joel: Oh, no problem. Are you kidding? That will take me like 10 minutes. Like I could do this whole thing in 10 minutes.
Sonia: Wait, go back, what were you talking about? I'm just realizing what you said and it makes no sense. I thought the "Explore" page only showed our destinations?
Joel: That's right. What are you talking about?
Sonia: On the frontpage, we want to show a list of the Top Ten most popular articles that have ever been written by the editorial team.
Joel: Oh! The editorial team! I get it. I thought maybe you were talking about the “Explore” suggestions that the marketing team does. But okay, sure, right, no problem. That's really easy.
Sonia: Slow down and be serious. I need an honest answer.
Joel: I just need to write one database query. I can do it in my sleep.
Sonia: Great, so when I can I test it?
Joel: Tomorrow.
Sonia: Okay, are you sure? Can I count on this?
Joel: Sure. But why? Is this a priority?
Sonia: I have a meeting tomorrow with Andrew, who is head of editorial. I'd like to be able to show him the progress we are making on the functionality that will package up and promote the articles that his team is writing.
Joel: Oh, okay. Well, sure, you can count on this. I'll get it done today.
Sonia: Let's think this through, in detail. You said you need to write a database query, what else?
Joel: Uh, well, I need to figure out where on the page we want this to appear. And so what CSS styles might effect it.
Sonia: Okay, specifically, what might slow you down?
Joel: Uh, well, it depends, right? Maybe everything will go smoothly. Or maybe not. Maybe there will be a weird, unexpected class of CSS styles, so the list of articles won't render correctly.
Sonia: That's what I thought. But these are the kinds of things we need to include when we create an estimate.
Joel: Sure.
Sonia: So let's take this one step at a time. You need to write a database query. Do you have access to the database?
Joel: Obviously. It's the same database that we put everything... uh, wait, no, god damn it, no, no, no.
Sonia: What?
Joel: I just realized, Andrew and his team write the articles using WordPress?
Sonia: That is correct.
Joel: Damn.
Sonia: Is that a problem.
Joel: Yes, in two ways. First of all, this part of our Ruby On Rails website is not set up with the permissions needed to reach the WordPress database. So that needs to be added in. And then the data in the WordPress database is in a weird format. And sometimes they embed HTML in the text in the database. So all of that needs to be cleaned up.
Sonia: Okay, these details are good. This is the kind of thing we should think about when we create an estimate. Do you personally have access to the username and password that we use for the WordPress database? Or should I get those for you?
Joel: Uh, it should not normally be a problem. I would just look in the configuration file for WordPress.
Sonia: Do you know where that is?
Joel: Uh, good question. Like, what server is that on? I could just use ‘ping’ to find the IP address and... uh...
Sonia: Problems?
Joel: Wait, where is the WordPress site? Did we move this to AWS?
Sonia: Yup! Tell you what, I'm going to go and talk Urdo about this. I'll gather up what you need and I'll come back to you.
Joel: Okay, thanks.
Then Sonia went and talked with Urdo, our devops guy, and she worked through all of her questions in an exhaustive way with Urdo:
Sonia: The subdomain for the WordPress blog is pointing to a server that we have in AWS?
Urdo: That's right.
Sonia: We moved the WordPress blog to AWS last week?
Urdo: That's right.
Sonia: And the database behind the WordPress blog is in AWS?
Urdo: Yes, in RDS, specifically.
Sonia: And you're giving me the username and password for that database?
Urdo: Yes, that will allow our Ruby On Rails app to connect to the WordPress database.
Sonia: What else do I need to know? What else might block us?
Urdo: Well, right now, we don't allow outside connections to reach our database.
Sonia: What do you mean when you say "outside connections?"
Urdo: I mean the servers at our old data center.
Sonia: And can we work around that? I assume you can white list them?
Urdo: Yes, no problem, I can do that.
Sonia: When can you do that?
Urdo: Late today or early tomorrow.
Sonia: Are you certain? Can I tell Joel that he can work on his part of this, early tomorrow morning, and he'll have an easy time connecting?
Urdo: Yes, no problem. I'll do this either last thing today or first thing tomorrow.
So then Sonia met with Joel again.
Sonia: I'm sending you the username and password that you need. And Urdo is going to white list the servers we have at our old data center, so they will be able to reach our WordPress database in AWS. All of this will be setup by early tomorrow.
Joel: Great, no problem. I'll work on this tomorrow and I'll let you know how it goes.
Sonia: Is there anything else you need? Besides the connection to the database?
Joel: Yes, I just discovered another problem.
Sonia: About the database?
Joel: No, about our design artifacts. We have some images that we use as ornaments in this design. I was trying to get a head-start on the design work, but that also has issues.
Sonia: Do you have access to the images?
Joel: Locally I do, but I can’t get the new design to update when I push the work to our staging server.
Sonia: You mean our test server?
Joel: No, no, let’s be clear here. I can see the design just fine when I push it to our test server. The problem is when I push it to our staging server.
Sonia: Why would it work on the test server but not on the staging server?
Joel: Because on the test server it shows us the images that it has locally. But when we go to our staging server, we use Akamai, which is our CDN.
Sonia: How do we fix this?
Joel: I need to clear our Akamai cache, but I was never given the username and password for that.
Sonia: Do you know who has the username and password for the Akamai account?
Joel: I don’t. I was hoping you would know.
Sonia: I think I know. I think this came up a few months ago.
As it turned out, it was the design team that controlled the Akamai account. Sonia asked a few people and tracked down what she needed, and then got the username and password, which she stored so she would know it the next time the issue came up. She also gave the username and password to Joel so he could get his work done.
(A week later Sonia called a meeting of the CEO, the CTO, and the head of the design team, and she made the argument that ultimate control of the Akamai account belonged with the tech team, not the design team. She won the argument and thereafter it was the tech team that controlled the CDN.)
The two issues that Joel had feared both proved substantial: there was HTML embedded in the text in the database, including formatting style HTML that had to be stripped, and then he further had to recreate the visual design, which had already been achieved for other "Top Ten" lists, but he was implementing it on the front page, where there were competing CSS styles; he could not simply re-use the CSS styles developed for the “Explore” page.
The project, which Joel initially said would take 10 minutes, in fact took two days.
And so Sonia became skeptical of our estimates. And she started working out every request in the same level of detail as she had done with Joel:
do you have the usernames and passwords for the database?
do you know which database is being used?
do you have access to the server?
do you know which server is being used?
are you sure you know which page we are talking about?
are you sure you know what type of content we are talking about?
is more than one server involved? If yes, are they white listed with each other? Are these servers allowed to talk to each other?
are the designs confusing? What might make their implementation difficult?
are the design elements, such as images, uploaded to a server or CDN that you can use?
if you need to clear the cache on the CDN, do you have the username and password to the CDN?
But these concerns only involved the designs, the tech team, and our devops guy. There were other concerns that Sonia was beginning to include, although it was some weeks before I realized how wide her perspective had become. As I was down in the trenches writing code, I was not seeing the whole picture.
Sonia’s commitment to detail was contagious and I, too, began thinking through the problems that might come up with each request. Instead of thinking our main app could be done in October, I realized it would be done in November, and the smaller "special purpose" apps would get done in December.
But even then I was being over-optimistic. By late September, I realized the main app would not be done until December.
And yet again, I was ambushed by reality.
During the first week of October the CTO asked for Sonia and I to stop by the office and give him an update.
I have a vivid memory of that meeting.
CTO: I have been going over these tickets. On the one hand, I am pleased to see us make so much progress. On the other hand, I see some of these old tickets, they've been in the backlog since June, and someone went through and increased the estimates on them?
Sonia: I felt our initial estimates were overly optimistic. I went back over these tickets with various engineers, and we figured out the details involved in each of these tickets, and that lead to longer estimates.
CTO: So now we won't get done until December?
Sonia: The site will be ready to launch in February.
I thought she was joking, so I laughed, but then I looked at her, and I saw she was completely serious.
CTO: What did you say? What are you talking about?
Lawrence: Yeah, Sonia, what are you talking about? If you take every ticket, and you add up all of the hours involved, even with the new, extended estimates, we can still get done in December.
Sonia: No, you're not seeing the whole picture. You're only looking at the tickets that exist for the engineering team. I've created a separate list of tasks that have to be done on the marketing side and on the sales side and on the editorial side.
Lawrence: Okay, but the engineers can reasonably claim that we will be done with our work by December?
Sonia: No, we have several engineers who are taking vacation time in December. So we won't have our normal velocity. Our productivity is about to dip because we have a six week stretch, from late November to early January, when at least one of our most senior engineers is on vacation each week. So at best we would get done in early January.
Lawrence: Okay, but why can't we at least launch in January?
Sonia: So after we have the site basically working, the staff needs to be trained how to use our new Ruby On Rails system. The sales team, when they do a demo for the airlines or the big cruise lines, they've been doing the same demo for the last 10 years, and now suddenly they have to learn how to do a completely new demo, for a completely new system.
Lawrence: And we need to wait for the sales team to catch up, before we can launch?
Sonia: That's how we make all of our money, right? The sales team convinces the airlines and the cruise lines to give us money because of the unique interactive experience we can offer to our users, and the way we supplement that experience with factually-rich editorial content.
Lawrence: And the sales team can’t start training until January?
Sonia: Well, right now we've got nothing to show them. We don't have enough of the new system working that we can meaningfully train them on anything. We can only start to train them in January, and they can only start to sell the new system to the airlines and cruise lines in late January, and then contracts have to be signed. So we won't be able to launch the new system until February.
It was a devastating moment. The CTO and I knew that Sonia had researched this carefully, and she was more in touch with other teams than either of us. She was the only one coordinating between the tech team and the marketing team and the sales team and the editorial team, so she was the only one who understood the entire truth of the moment.
But somehow our estimate had slipped from October of 2011 to February of 2012. And that was a serious slip.
And of course, events proved that Sonia was entirely correct. The new site went live to the public on February 22nd of 2012.
I learned a few things from this.
For an estimate to be meaningful, you need to work through it in detail and try to figure out exactly what a particular request (which is probably represented as a particular ticket in a system such as Trello or Jira) actually means. But then realize that even after you've done all this, you still don't know the whole truth. There will always be some unknown unknowns waiting to ambush you.
Is your project on schedule? The truth is you can never be 100% certain of this, therefore you must have contingency plans. Perhaps your lead engineer will suddenly quit, or become sick, or some new engineer, in whom you had high hopes, will flake out or do poor quality work. Or perhaps the marketing team stalls your whole effort, with their intransigence and their irrational loyalty to some old tool that you've asked them to give up. It's also common for your sales team to sabotage your efforts if changes in one part of the system also requires some changes in the CRM system that the sales team relies upon.
Bad things happen to good people. A hard truth, but we all have to face it. Likewise, even a brilliant team with a great product is sometimes ground down by brutal circumstances. Therefore, beware of the psychological "denial" that can warp your thinking when there are no good possibilities for contingency plans — when a project is "life or death" for a company then the pressure will be strong to come up with rosy projections and believe them.
Also, keep in mind, the whole industry changes over time. Ever evolving, fluid roles mean that parts of this example, from 2011, would be handled differently in 2025. At that time Sonia had the title of “project manager” and so she stepped forward and became the person who “was the only one coordinating between the tech team and the marketing team and the sales team and the editorial team.” Nowadays this role might be handled by someone who has the title of “Product Manager.” It’s also a role that, in large organizations, is often given to people with the title “Chief Of Staff,” although it goes against “best practice” to give project management responsibilities to a Chief Of Staff (a point that Crystelle Desnoyer makes brilliantly in this podcast interview). And in very small, early-stage startups, it has to be the CEO or COO who plays this role, and keeps in touch with the needs of every team.
Some people make the argument that it takes too much time and effort to generate correct estimates. They argue it is better to accept the risk of estimates being wrong, rather than waste time. And they may be correct for certain companies at certain moments in their evolution — this is always a judgement call and the leadership will have to decide what the priority is. But keep in mind, much of the work of estimating a ticket is also the work of actually doing the ticket; for instance, finding the username and passwords that are needed for some ticket is work that has to be done at some point, so why not at least list what usernames and passwords are needed, when you’re trying to estimate how much time will be needed for the ticket?
At the risk of sounding darkly negative, I would remind everyone that we never really know the future. All we can do is, through our actions and our intelligence, insulate ourselves as much as possible from the downside risks of a project running late (or failing completely). And the two most important things we can do, to insulate ourselves from risk, are:
dig deep into the details and try to discover the unknowns before they ambush you
assume you will miss your deadline and therefore have contingency plans