Tracey was a tough government client, but she fought for what she thought was right. Six months ago, a nasty external audit resulted in the Department replacing its Program Management Office (PMO) with a new consulting firm, and a “schedule first” project management strategy. Everyone hated the bureaucracy, but Tracey enforced policy with an iron fist. “If it’s not baselined on the schedule, then we didn’t approve you to work on it, and we’re not paying for it!” The increased paperwork did reduce meeting times and arguments, even if few were willing to admit it.
In the spring, Tracey approved a new Customer Registration feature for the August software release. The software development team spent most of their summer building and testing this capability. By late July, the feature was ready, and mostly on time. Then a problem came up.
Anup, the software development company’s project manager, explained his request to the Change Control Board. “In short, Microsoft announced this week that they are ending support for their Silverlight application framework, which Customer Registration relies heavily upon. We don’t need the Customer Registration capability until next spring, so we can rewrite and retest the application now, rather than rolling out something we will have to replace. We believe that sticking with the old system for six more months will be less disruptive to the field offices.”
Tracey was fuming. To her this was another broken promise – more taxpayer dollars wasted. “And we had no warning Microsoft was going to do this?”
“None,” replied Anup. “Our Silverlight developers came to us as soon as they read Microsoft’s announcement.”
“So how many hours of rework do we have to pay for?” Tracey was not mollified. Shouldn’t they have seen this coming?
Mamadou, the project Schedule Manager and designated PMO meeting facilitator, spoke up. “This will add five hundred hours of development, and two hundred hours of stand-alone testing to the next February release. However, we are also pulling back a hundred hours of regression testing from the August release. Training the field offices on using this application will be postponed with no change in effort.”
“Okay fine,” Tracey grumbled. The Change Control Board members voted, and the change was approved. “Now, I want all work that we’ve done on the Customer Registration system moved from Software Release 3.4 to February’s Release 3.5.”
Everyone looked stunned until Anup broke the silence. “Tracey, we can’t do that. We haven’t even finished planning Release 3.5, let alone started working on it.”
Tracey was unyielding. “Then this will be Release 3.5’s first ‘new’ software feature and you’ll be ahead of the game. If Customer Registration isn’t going out as part of the current release, the work doesn’t belong there.”
Anup and Tracey argued. He didn’t want to say it, but Anup knew if Tracey yanked the development work out of Release 3.4, his company would not see payment for five thousand billable hours until next year. He wasn’t sure he could absorb such a hit. Meanwhile, Mamadou pulled up the schedule file and found the Customer Registration kickoff task. He had no recollection when this work was approved, but fortunately he didn’t have to.
After a glance at the schedule, Mamadou turned to his counterpart. “Abbey, can you put the Change Control Board meeting notes from March third on the projector screen? Now, can you go to the second agenda item?”
The screen displayed a baseline change request bearing Tracey’s digital signature. “On March third, we approved the Customer Registration feature for development as part of Release 3.4,” Mamadou said. “The software was developed and tested within the boundaries stipulated in this meeting. We cannot unmake an agreement which we all supported in good faith.”
“But the feature is not going out in this release,” Tracey countered. “All I’m telling you to do is rearrange the outline structure for some of the tasks already on the schedule. You’ve updated the schedule’s outline before. Why is this any different?”
“Moving completed work from Release 3.4 to Release 3.5 would claim that we intentionally started work on Release 3.5 back in March,” Mamadou answered. “We have no paperwork backing up that claim. If releasing a feature in 3.5 that was developed during 3.4 is unacceptable, then our best course of action is to reject the change request and release Customer Registration using Silverlight’s application framework.”
Tracey considered for a moment. “So, nothing is actually delayed. We can release the Customer Registration feature in August if we want to?”
“Yes,” answered Anup. “If you believe that’s what’s best for the Government, then that’s what we’ll do. But we see an opportunity to get ahead of a new issue now and save everyone time in the long run.”
After reconfirming the change request and adjourning, Anup pulled Mamadou aside. “I thought your schedule bureaucracy made you one of the bad guys, but you really saved my hide in there. How did you and Abbey find the original agreement so quickly? Do you have a photographic memory?”
Mamadou smiled. “No, I just take really good notes in the schedule file.”
Questions to Consider
- Does Tracey have a valid rationale for wanting to move the completed work to the February release?
- Tracey thought Mamadou was holding his ground over something trivial. But Mamadou knew that Tracey’s request would create a paradox in the schedule. What was the contradiction Mamadou couldn’t allow?
- What “really good notes” did Mamadou have at his fingertips? How could the meeting have unfolded differently if Mamadou hadn’t been able to pull a quick reference out of his hat?