Tales from The Project Management Jungle(tm):The Gang That Could Schedule Straight:

A semiconductor division, which had struggled to use project management methodology in an effective and productive manner, brought me into one of their design teams. The team had two key projects coming up in the next year to eighteen months that simply had to come in on time. Their customer had products in a highly competitive marketplace waiting to be incorporated into a higher level product and they brought a lot of pressure to bear. It didn’t help that the historical relationship between the overall customer and my new division was poor.
The team’s previous projects had been late and, while the group had created schedules and held project reviews, they seemingly had little positive impact on the projects. The project personnel and management viewed the reviews as time wasters.

The previous team’s schedule was very detailed, well over 500 tasks. It resided in my PM predecessor’s office updated frequently but unable to drive action on the project. My predecessor had spent much of his time haranguing the engineering managers to update the schedule and then actually doing the updating himself, its very detail defeating him. He had very little time for anything else and thus had little impact on the project team. The project itself was woefully late.
I spent a couple of months just getting to know the team while the earlier project finished. Most importantly, the senior design manager, Brian B, and I hit it off. Without the support of Brian and the overall design center VP, I am sure we would not been able to create the success that ensued.
Our customer dictated a due date. I convinced Brian to let the team build a detailed milestone schedule with no predetermined end date, but with an end date as tight as the team could commit to. Brian trusted the project functional managers and knew the requested project scope and tasks very well, so he was able to call them out if they tried to pad tasks. And he and I were effective tag-teaming them in a good cop/bad cop way to drive out pad in the schedule.
Finally, we finished the schedule. But our schedule finish date was a couple of months beyond the demanded date. I convinced Brian that he would never be stronger than this and to hold firm no matter how hard the pounding. “They won’t kill you now, but better to die now than to live through a disaster and then be killed,” I told him. For some reason Brian agreed.
Brian and I were called into meetings with the customer PM, who demanded repeatedly and loudly (but not unkindly) we move the date. We politely refused, stating that in good faith the team could not commit to finishing sooner.
We were then called into a meeting with the number 2 manager in our organization--a VP--to talk some sense into us. I thought I would be fired for driving such weird behavior (he actually subsequently hired me for a higher level job roughly 2 ½ years later).
We told him we weren’t trying to be stubborn, but this was the best we felt the team could do. Then we told him we would gladly reduce the schedule wherever he could identify fat. We spent several hours with this VP and at the end of that time he agreed our date was fine.
We then were called into a meeting with the top manager in our design organization, a man who in the past had articles written about him in the Wall Street Journal. We listened to a lot of talk on how to run development projects successfully, but at the end he didn’t direct us to shorten the schedule either.
Then we were off and running. We had a meeting with the senior functional managers on the project, then a kick-off meeting with all project personnel. We showed the milestone schedule (it never changed) and the project management process we intended to use. We showed clear roles and responsibilities for all levels of the team, including senior management. This started the process of driving accountability.
It also started a process of transparency on the team. We only ever had one set of books, i.e., the schedule we showed them was the schedule we showed the customer and management. There wasn’t one schedule for the team and one for management, which is often the case. Everyone on the team saw the original schedule, in the beginning and as we progressed. So did management.
Brian and I told the team (looking straight in as many eyes as possible) that a big part of our jobs was to remove roadblocks for them. The VP for the design center was there for the kickoff and echoed that statement. Later we did exactly what we promised, taking several issues to senior management and getting what was requested. This, of course, added greatly to the trust of management on the team. The leaders on teams create the culture around them by modeling the correct behaviors. Others began to act with more trust and it spread.
We ultimately successfully managed this development project to the advertised end date with only a 200-line schedule updated weekly by myself, a simple earned value system, and a short list of key project risks. That way, the key project managers were appropriately involved, but did not have to devote an enormous amount of energy to the project management details.
The task managers did have more detailed individual schedules which we did not look at. We did, however, ask them each week in our project team meetings to each show a one slide summary of any impediments to hitting the next handful of key project milestones. This data drove our overall risk list and top-level schedule.
Much discussion ensued in the weekly staff meetings. Engineers (all knowledge workers, really) are very busy, hate to waste time and like to work alone. Getting engineers (knowledge workers) out of their offices/cubicles and discussing things not in their functional area was the goal. This occurred once they understood that the other managers/functional teams could impact them. Peer pressure drove accountability on the project.
We continued to be transparent to the team and management on our progress, risks, and any help we needed.
We continued to hold the team, ourselves and management accountable for needed actions.
We continued to trust and expected to be trusted in all discussions.
And we finished on the exact day committed to. It was disappointing when our part of the overall project then sat on the shelf for almost a year as the overall product customer dealt with his own typical delays, he himself missing his “firm” date by a wide margin.
Were we lucky? I cannot say, but this was done a total of 7 times over roughly the next 3 years with the teams in that organization. Many people, including myself, progressed in their careers as a result. That kind of luck I will personally take any day. 

And Brian told me he is still using these techniques, these many  years later, on projects he currently manages.

All Rights Reserved, 2008, Executive Team Leadership, LLC