The escalation process worked! As work on the program drifted past the scheduled completion date, Proman sensed the pressure coming from across the organization. Managers wanted their engineers back to work on product development, not on solving broad reaching technical issues. But the impasse was real. Development could not continue (or if it did it was at risk of being made irrelevant) until the interface options of the technology were made complete.
The process Proman helped create consisted of three steps. Study groups of key technical experts had the first responsibility to propose solutions and get agreement from other experts via postings on the intranet. If disagreements stopped this from happening, the issues would go to the management group that had been set up as a core team to oversee the process. These managers would attempt to decide which solutions to go with. If not, the issues would finally escalate to two functional managers for a decision.
Proman watched the dialogue happening over the intranet. A solution was posted by the primary author. All other experts accepted a responsibility to review the postings each day and comment. Many comments simply said, “I agree.” All of a sudden, a remote engineer cried out, “This solution would be impractical for our application because: . A better solution for us would be: .” Subsequent postings responded, “I had not realized this impact, but now that I’m aware of it, I, too, prefer the alternate solution.”
A number of issues did not fare as well. These required going to the core team. For each of the twenty issues on the agenda, discussion was limited to five minutes. A countdown timer provided a visual reminder. One of the top technical experts, known for his propensity to speak slowly and drone on and on, had an almost panic expression on his face as he looked at the timer. But he got his arguments out. Votes were cast, and decisions were made. All except one.
Issue number 105 was especially complex. The next step was for proponents and opponents to prepare their arguments and present them to the functional managers. This heightened focus almost achieved resolution because the best minds engaged in deep dialogue. Finally, the managers made a decision, and everyone celebrated completion of the process!
Proman had mixed feelings at this point. The process went nine weeks beyond the sixteen weeks that he had accumulated into a master schedule. It had taken much cajoling to get each group to submit their schedules, but with coaching and perseverance, he got it together. Many times he had to fight off his impatience with technical experts who did not communicate readily and managers who did not understand or appreciate what was going on.
On the other hand, he was ecstatic that the program completed its objectives and solutions were delivered. He had played a key role in coordinating activities across a convoluted organizational structure. A fun task was getting the group general manager, himself a chief technical strategist and executive sponsor for the technology, to sign a letter to each contributor, thanking them for their participation. Proman provided the first draft, which the manager slightly edited and gleefully signed. Copies were sent to each participant’s manager. The customized coffee mugs and personalized letters the participants received were big hits.
Proman now reflected upon his role. He seemed as if a code had been cracked. How do you get a series of complex technical issues decided across a vast organization by an amazing variety of skilled people in an intensely competitive market? No one person seemed to have that responsibility. Content wise, all credit goes to the technical experts. Process wise, a small team crafted a unique set of steps and operations to accelerate the technical work. While not applied at the time, such a team could be called a project office. Proman’s role was essentially a project office of one, a POO. He was not officially sanctioned as a project office nor was there any thought put into starting one. The program was complex enough that it just made sense to have someone function as a central source to identify schedule, track, and coordinate all tasks and relationships. Proman had the necessary aptitude and interest to do so. He was a perfect fit to step into this role and see it through to completion.
Now if he could just figure out why he had such a strange name: .
1 thought on “The POO Code, Chapter Four”
I have used the POO approach since eight years ago. I strongly believe on that. I always apply my passion, persistence and patience in all the projects I manage. I have leaded some Project Management Offices implementation in Spain and Portugal, and it is crucial for me to believe in the success (passion), to insist in your ideas; you must sell your beliefs all the time (persistance)in your organization, and finally you must wait. Ideas implementation takes time, but it is possible. I always try to remind that not all people minds work at the same speed. Then you must be patient too and wait for a while. The application of my three Ps has worked well for me. My favourite sentence is “TODAY IS A GOOD DAY”.
BUCERO PM Consulting