Case Study: Asking The Right Question

Patricia got a call from her client, Jonathan. “There’s a new vendor schedule coming in. We need it added to the existing schedule immediately.” Her first opportunity to look at the vendor schedule came a week later in a meeting with Jonathan and his boss Francis, with several other government and contractor team leads, including Patricia’s boss.  

Staring at the projector screen, Patricia realized the vendor schedule was huge, maybe half the size of her own eighteen-month project schedule.  The project leaders talked for a while before Jonathan turned back to Patricia. “We need you to incorporate the vendor schedule into the project.” 

Patricia looked bewildered for a moment. “The whole thing?”

“The whole thing,” answered Jonathan. “We need to track their work meticulously.” 

Patricia thought she understood. “I’ll be managing their schedule for them.” 

“No. But they are required to send us an updated schedule weekly. We need you to incorporate their changes every week so that we can stay on top of their work.” 

“Okay,” Patricia replied. “What are the key events in the vendor schedule for us?”

“Everything in the vendor’s schedule is a key event for us,” Johnathan answered. “Their entire project is on the critical path.” 

Patricia ignored yet another misuse of the fabled term – “critical path”. Clearly Jonathan thought this new vendor’s work was important. So why had she never heard of them? “My apologies, let me rephrase. Which events in the vendor schedule require us to do something, or require our input to complete?” 

“This is their work,” Jonathan responded patiently. “They are responsible for everything in their schedule.” 

Patricia scanned the schedule on the projector screen a moment longer. “Okay so we don’t have any shared tasks on their project, and we are not helping them manage their schedule. That means, despite regular reporting, their work is still a black box to us.” 

“I have no objections incorporating this entire project schedule into ours,” she fibbed. “I’m just not sure what we would gain from doing that, since it appears that next year’s delivery is the only part of their schedule which we can care about. For example, does our schedule really need to know when they start their software development?”

“We do need to know when they start software development,” Francis interjected. “Their software development dates dictate when we need to get the requirements documentation to them.” 

“I see,” said Patricia. “I don’t see ‘Receive Customer Requirements’ in the vendor’s schedule. Do we have the requirements handoff described in our schedule?”

The team leads in the room winced. Francis chuckled, “Jonathan, I think she just asked us the right question.”

Questions to Consider

  • Despite its large size and detail, why does Patricia think that the vendor’s work is a black box? (That is, something whose inner workings can’t be seen.) 
  • Both the vendor schedule and Patricia’s schedule appear to be missing at least one major handoff. What should Patricia do next to authenticate her team’s and the vendor’s plans for working together?
  • For Patricia, what are the pros and cons of incorporating the large vendor schedule into her schedule? Does she need to integrate the two schedule files to track the vendor’s progress?
  • What vendor events are most important for Patricia to incorporate into her schedule?
  • Jonathan and Francis’s patience with Patricia’s inquiry paid off. She was able to uncover a blind spot in both schedules. But frank discussions aren’t a luxury for every project team. What are some methods, both procedural and interpersonal, Patricia could employ to identify the requirements risk if leadership had blown off her questions?
© ProactiveScheduleManagement.com