Epilogue: Integration

Our goal in this book is to build an image of a more complete, organic molecule that comprises the project, program, and portfolio management skill set. The concept, whether as a project office of one up to a program or portfolio manager, is to integrate skills from multiple disciplines. In this epilogue, we add to and wrap up our endeavor.

Stories have played a key role in highlighting learnings throughout the book. On the importance of sharing stories, fellow consulting colleague Peter Taylor, in The Lazy Project Manager: How to Be Twice as Productive and Still Leave the Office Early (2009), writes, “Always be open to learning more from project knowledge and history, by talking openly to project team members so that you can learn the lessons that are there to be learned—and share everything by telling others what you now know.”

David Eubanks published How to Be a Project Manager without Getting Killed (2010) to help readers learn the fundamentals of project management. Here is the beginning of his story:

This captures much of the experience of those successful complete project managers who set off into the solo consulting world. David’s story continues:

In tribute to The Da Vinci Code (2003) and with apologies to the novel’s author, Dan Brown, we offer our own novella, The POO Code, to summarize the development of a complete project manager.

The POO Code

Proman A. Jecgert put the phone back in its holder. It was a distressing call. The caller was very frustrated about what was going on in her office. “The place is in a mess,” she said. “People are doing their own thing, and managers aren’t stepping in to guide the development process or make crucial decisions. If we keep going in this direction, it will become impossible to recover in time to get products to market. Can you help?”

Proman was bothered by the caller’s negativity. But something told him there was an opportunity here. He decided to talk with his manager about the call. His manager used to be his colleague, and they’d worked very well together. But now that she was his boss, she’d developed a controlling style that made him rethink his current situation. He no longer ran the team meetings and was relegated to support tasks. Maybe this phone call represented an opportunity to contribute in a new direction.

The discussion he initiated with his boss went well. Yes, the problem in the organization was real, and something needed to be done. Was he interested in helping by taking on this new assignment? You bet!

Proman decided to meet with the manager who had called. In person, he got a much different impression of her. He discovered a very smart person who articulated issues clearly. It was clear she was passionate about making changes. She knew how the organization worked—and she was painfully aware of the collegial environment and that people shied away from suggesting any radically different approaches. If a new idea failed, the person leading the change would be stigmatized. More than anything, she needed someone to help manage the tactical side of leading the change. She would champion the cause as long as there was someone covering her back who could get things done.

In addition to these issues, it was essential for the organization to get agreement on key issues so teams operating virtually could make progress. And, outside the company, the press was wondering if the company could succeed in introducing its new product platform.

Proman knew he had a sponsor who could guide the effort, and he sensed that the project was an excellent match with his process development capabilities. This project presented itself as a high-visibility, high-importance opportunity. Proman realized that this was just what he was looking for—a shift from a current untenable position to one in which he could contribute big time. Wahoo!

Proman looked over the agenda for the first meeting of the management team. He was impressed with how Toni, the manager he’d spoken with—and the champion for resolving the issues on the project—got this cross-organization group to convene. Toni took the initiative to approach each of the key stakeholders and discuss the problems, point out the consequences, identify the benefits to each person’s organization, and ask for the stakeholders’ support. Fortunately, she had much credibility in their eyes, for she had been around the organization for a while and had completed her projects successfully. But her track record alone was not enough to resolve the current problems. The energy and passion that she put into the discussions, combined with the urgency of the problem and clarity of the message, made it abundantly clear that something had to be done now. Her leadership and influential approach sealed the deal.

Lunch was laid out on the counter as people started coming through the door. Proman knew that holding the meeting over lunch helped eliminate the problem of getting everyone together at a given time. Serving food is always an attraction.

The R&D managers for each of the divisions held a loud conversation as they ate. They were an aggressive sort and not likely to listen to long, drawn-out presentations. They often had to work together and fight battles for product authorizations and resources.

“Let’s get started,” Toni shouted over the clamor. “I asked our group general manager to say a few words about the situation we find ourselves in.” This had the effect of getting everyone’s attention. As the general manager spoke, Pro-man furiously made notes about key messages that would be repeated often throughout the next few months. One note said, “We need to have a common methodology and a consistent architecture that allow all parts developed separately and virtually to work together; we have to focus on what’s most important for this organization to establish a foundation for the next ten to fifteen years of product development.” Proman reflected on how beneficial it was that he and Toni had spent time briefing this manager in advance of the meeting.

Next, the chief technical leader summarized the issues involved. Toni then proposed a process to resolve them. She and Proman had spent considerable time brainstorming how to go about getting engineers into study groups and recruiting technical experts across the organization to review and vote on proposals.

The plan included a breakdown of assignments and a preliminary schedule. Nothing of this magnitude and technical complexity had been attempted before. It would take all hands on deck for a limited time just to begin the effort. Proman prepared a flowchart that was simple yet complete. Together, they shared the process with the managers and answered their questions. They also described how they would personally oversee the process, capture real-time status, and report back to the managers. In turn, the managers had to agree on priorities and constraints, ante up engineers to work full time on the issues for the next several months, meet weekly to review progress, and make decisions on questions that were sure to arise.

Almost amazingly, the group of upper managers gave the go-ahead, not reluctantly but with enthusiasm. The plan was solid, and the people were credible.

After everyone had left the room, Toni and Proman looked at each other, seeing relief yet worry in each other’s eyes. “Great start,” said Toni, “but will we be able to deliver what we said?”

“I sure hope so,” said Proman. His mind raced ahead. He needed to write the summary of the meeting, schedule the teams to get started, and work through the details of the plan. He was excited, but then he realized that this would not be easy.

Seated at the meeting table across from Proman, Toni made a face. Things were not going well.

The group general manager had come by Proman’s desk just after lunch to inquire about progress. Proman could proudly report that well over half of the issues had received approval, but a few tough issues were proving especially difficult to resolve.

“The best people are working on them right now,” Proman said, wondering to himself if he truly understood what they were doing. He had a technical background but no depth or previous experience with these types of issues or this technology. What he did know, however, was that the technical experts lacked the systematic process abilities that he possessed.

Proman had started the weekly meeting by reminding key engineers from each of the study groups that resolving the issues they’d discussed was the top priority for the group. The meeting attendees were throwing arguments around the table like crazy, with no apparent progress being made toward resolution. That’s when he jumped in.

“Let’s itemize the possible solutions,” he commanded. After the group posted sixteen possibilities on the board, he said, “Each of you now vote on your preferred solution.”

A wall of protest arose from the ten experts around the table. “We’re not ready to pick a solution.”

“I know. Your vote is not binding. But we do need to get a sense of which direction we need to go,” Proman insisted, trying to move the group away from endless debate and into a negotiated agreement.

The resulting votes were all across the board. “What do we do now?” Pro-man wondered to himself. Then someone suggested, “If I had a second vote, it would go to number 12.”

Another expert said, “Wow, I didn’t think we were allowed a second vote, but if so, I’d go with number 12 as well.”

Amazingly, the whole group focused in on number 12. But nobody had voted for it in the first place. Further discussion revealed that this was the “fantasy” solution that everybody liked but nobody thought was possible. The debate took a different direction, and the engineers came up with a compromise solution.

Proman had a self-righteous look of satisfaction on his face as he left the room. He thought, “I sure as heck did not understand the technical ramifications, but if I hadn’t been there to direct them through a process, they would still be arguing till infinity.”

But later, sitting around the table with the team leaders, Proman realized that more “miracles” were needed. The status reports revealed that many issues were being debated to no end. At each meeting he heard the same story: “We need more time.” Toni’s expressions revealed how frustrated she was with hearing this refrain. Proman studiously kept track of progress and came back each meeting to get updates. When the division manager came by his desk, he told Proman, “We need to escalate this process. New product development is getting bogged down, and this program to resolve the issues is not making fast enough progress.”

Proman protested, “The right people are working the best they can.” He had observed his immediate manager constantly pushing on other teams when progress was slow. The effect was disturbing and demoralizing. The technical people needed discussion with their peers and an environment encouraging creativity, not commands from management. Proman came to believe that gentle prodding, questions, and suggestions would be more appropriate in these situations.

“In this case, I disagree,” said the division manager. “Please put together an escalation process. I may have to force some resolutions. Let’s review it together tomorrow.”

Proman was not happy about this turn of events but set to work drafting a process. The next day, he received positive feedback about his proposal but also a number of modifications. “This could turn out to be very interesting,” he thought.

Proman and Toni introduced the escalation process at the next team meeting. The division manager, who was also the sponsor for this program, was present to demonstrate his support, over the rounds of protest. “We have to move faster, because our very survival in the market is vitally dependent on us introducing this new platform this year,” he said firmly.

Subsequent meetings revealed how insightful the division manager had been. The teams did not lack for possible solutions. Actually, there were multiple possible solutions. However, experts across the organization were passionately putting forth various arguments to support their work to date. The alternative was to scrap that work and do something different. Other experts argued for the purity of the technology, ignoring a pragmatic approach that would be easier for the divisions to implement. No perfect solutions existed. Tradeoffs and business decisions needed to be made.

Proman jumped into negotiations with renewed vigor. He realized that putting limits on discussion time and making decisions by deadlines resulted in engineers moving beyond their positions to come up with acceptable compromises. They seemed to realize that if they did not do it, the alternative was that management would make unilateral decisions that might not be as informed or practical. This would not work in situations where technical creativity was required. However, when business decisions were needed to decide among several options, management was better prepared to make these decisions than the engineers were.

Proman was thankful for the coaching his sponsor provided, especially when the sponsor peered over his cubicle wall and said, “Good work at the meeting today!” The pressure was still on, however, to get closure on the remaining deliverables required by the program.

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 working 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 first responsibility to propose solutions and get agreement from other experts. They did this via postings on the company intranet. If disagreements stopped this from happening, the issues would go to the management control group that had been set up as a core team to oversee the process. These managers would attempt to choose the best solutions. If they could 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 responsibility for reviewing the postings each day and commenting on them. Many comments simply said, “I agree.” All of a sudden, a remote engineer posted, “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 were not as easily resolved. These were escalated 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 panicked 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 resolved the conflict, 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 planned into a master schedule. Political maneuverings emerged, but these were minimized by strong sponsorship and firm leadership. It had taken extensive coaxing 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. It seemed as if a code had been cracked. How were a series of complex technical issues resolved across a vast organization in an intensely competitive market, even if he was working with an amazing variety of skilled people? Content-wise, all credit went to the technical experts. Process-wise, a small team crafted a unique set of steps and operations to accelerate the technical work. While the term was not applied at the time, such a team could be called a project office. Proman’s role was essentially as 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 ….

The applause was thundering as the magician completed his performance. Proman had hired him to help celebrate the completion of what would come to be called Phase One of the program. All project participants across the organization had been invited to the party. The grove in the trees was a perfect setting, and the sun shone brightly.

Proman smiled, thinking about his meeting with the magician beforehand. They’d tailored the presentation to make it fun and memorable. They’d made a joke of how stubborn Issue 105 had been—it appeared several times throughout the magic show. “ISSUE 105” had been written in big print on a roll of toilet paper, which was then unrolled around the functional manager who had to make the final decision on its resolution. The laughter was invigorating.

Proman turned his attention back to the process. Despite the celebratory atmosphere, he could sense much more needed to be done. The challenge, of course, would be keeping the momentum going. The hard work, long hours, and intense communication left everyone feeling drained. But more issues needed to be resolved before the new platform could be introduced into the marketplace.

Later, when the cross-organization council of R&D managers convened, a recap of Phase One was followed by a discussion of the remaining work. “What we need from you,” said Toni, resuming her role as instigator, “is a new set of priorities. We have to continue working on the issues. We learned much over the past several months that will help us operate in a more streamlined fashion. Your continued support is imperative.” Toni knew that the high feelings were temporary and would soon get redirected to local work if people did not stay focused on the broad issues affecting everyone.

A full-day program retrospective review covered lessons learned. Craig captured data about how long it took to resolve each issue. He correlated resolution time with whether each issue was of high, medium, or low complexity. He then categorized the complexity of the remaining issues. The data also revealed that, although the mission of the Phase One program was to deliver resolutions for 100 issues, there were actually 120 issues by the end of the phase—certain associated technical issues had to be clarified in order to get closure on the main issues. Proman had questioned this “creeping elegance” or “scope creep,” but the technical experts proved that these additional tasks were indeed mandatory.

Other topics covered during the review meeting included communication bottlenecks, training study group leaders in project management, the escalation process, and the estimation and scheduling processes, which had been helpful but could be improved now that some history was available.

Proman sensed an opportunity. “I can put together a short training session on project management for leaders of the study groups. That will help us all get calibrated on process steps. With their inputs, I will again create a master schedule, but this time we will add in 20 percent more work. We can use more online technology to post and respond to proposals. I can lead one of the study groups myself.”

When he showed this plan to the sponsor, the sponsor asked, “Why do you show 60 issues? I thought the council authorized work only on the next 50.”

“We will start with 50. But experience shows us that the work will expand by 20 percent,” Proman replied. “We are factoring that natural expansion into the program plan. This will help us avoid surprises and be able to meet a committed schedule.”

“I’m not sure about that, but okay. Are you confident that you will be able to lead a study group?”

Proman’s answer in the affirmative was unflinching. He had some concerns about understanding the technical jargon but knew that his role would be to ensure progress and get results, not to solve the issues himself.

The rollout of Phase Two and the rapid progress over the ensuing weeks went exactly as Proman imagined them. The training, communications plan, reporting, tracking, and discussions were extremely productive. The “known unknowns” indeed surfaced. As in the past, a number of new issues arose that had to be jointly resolved. They were accommodated within the schedule which, this time, was met to the very day.

The code had again been cracked. Proman had learned how a comprehensive schedule could be realized in a high-tech environment with many unknowns. The answer: train people in a project management process, use as much history as you can and extrapolate it into the new environment, have a confident leader, obtain and sustain upper management support for the process and the work, be flexible, and constantly innovate. Sell the plan to all key stakeholders and negotiate with due diligence. Then celebrate successes and provide continuous feedback.

His work environment had not initially functioned this way, but Proman felt pride and satisfaction in knowing that he took the initiative, with the help of some friends, to apply his skills and knowledge to manage the endeavor as a program.

Perhaps he was ordained to do this. Looking at his name, Proman A. Jecgert, he wondered if it might be an anagram ….

Proman was at a crossroads. The large program had just concluded. What was next? He noticed how engaged he’d felt during the process. Each day he threw himself into the proceedings with renewed vigor. He seemed to know instinctively what to do. People looked to him for direction, even people smarter than he was and higher up in the organization. Sure, there were many moments when he felt like he wanted to strangle someone who would not cooperate. But even these moments challenged him to reach inside himself for an appropriate response that would elicit a positive reaction.

A number of previous assignments Proman had worked on had a similar pattern. These assignments were important and urgent for the organization. Each was unique and needed someone to take charge of working with others to deliver results. Unlike many engineering assignments that required deep analysis in a specific area, the assignments Proman gravitated toward were broad, people-and process-related, and complex. There were no obvious answers or one correct way to do them. They were opportunities to invent new practices, or borrow and modify existing ones, to achieve results. The people dynamics were fascinating, although often frustrating. Success seemed to come when technical and behavioral aspects, intellect and emotion, and head and heart were integrated.

Proman was a continual learner (although he was not fond of homework assignments and tests), and one day, when he was reading some professional literature, he learned that there was a name for people like him and what they were doing. In fact, this approach to project work had evolved into a discipline, profession, and body of knowledge.

A major clue had been staring at him all along. Looking at his name, Pro-man A. Jecgert, he started rearranging the letters: p-r-o-j-e-c-t m-a-n-a-g-e-r. There it was! He was a project manager, practicing project management, leading a program, and functioning as a project office of one (POO). Nobody had asked him to start a project office; the situation just required someone to act in that capacity.

As he would come to learn, the term “project office” is not without baggage. For some people, it means overhead and bureaucracy. One functional manager had told him, much after the fact, of course, that he felt the person who headed the program management office had acted as a spy to senior management. Functional managers like him want a lean organization where competencies and action are dispersed across the organization, not in a central—and expensive—unit.

Later in his career, Proman would go on to various assignments in project offices, present at professional conferences, author articles and books, and serve as an internal consultant on project management to teams across the organization and worldwide. He became a proponent of project offices as a concerted means of focusing on improving project management practices.

One day, he received an intriguing question from a person in an organization that appeared immune to establishing project offices. “Can individuals establish project offices of one?” In other words, can an individual or project manager embody all the traits, skills, knowledge, and actions that may exist in a project office?

Proman felt as if his whole body shouted out the answer: YES! A project office of one (POO) is possible in an organizational culture that supports the essence of a project office but not its structure. Project offices of one are change agents—individuals learning to unfreeze, change, and refreeze the people around them, offering tremendous value. The steps along a path from chaos to nirvana can be taken by individual project managers—or others who are doing projects or leading a change effort and just happen to have the aptitude. People who function as project offices of one want the outputs they create, through a set of activities, to be great instead of average, and the outcomes to contribute to and fit with organizational goals instead of going on the shelf. POOs make this happen through their knowledge of leading practices and their experience with project management processes.

A project office of one is a project manager or other individual who, as above, embodies all the traits, skills, knowledge, and actions that may exist in a project office but does so without formal authorization or title. The term may not be established in common usage, but it is a position to which people devoted to excellence in project work can aspire. People like Proman can practice their craft, perhaps silently, in stealth mode, or anonymously—and magically produce astounding results. Doing so captures the attention of other managers, who ask, “How did you do that?” The POO credits the project management process (as applied by a skilled practitioner). Upper managers then ask, “Can you help us apply this process to the rest of the organization?” This opening is the exact response a POO desires. The door is then open to the POO to expand the influence of his or her work, perhaps as the beginning of a viral networking process—using social networks to increase awareness or to achieve other objectives through self-replicating viral processes, analogous to the spread of physical or computer viruses.

There is no greater reward for a true project manager than to take on a larger project, in this case enterprise project management. The possibilities for guiding the organization to higher levels of maturity and achieving optimized results are endless.

The “secret” code to success and advancement in any organization is to make yourself more valuable, align with organizational goals, attract like-minded individuals who want to make a difference, and take the initiative. People who do these things may be able to function as a project office of one. The ability to speak truth to power is invaluable, especially in challenging situations.

Testimonials from graduates of advanced project management programs state that as they apply the concepts and coach their bosses or manage upward, they are perceived as more valuable to the organization. This behavior is in stark contrast to those who say, “That’s not my job.”

A VP at a successful high-tech company said, “Those people who tap their innate skills and capabilities and align and apply them to operational directives are highly valued. They are the glue that holds our virtual human network together.”

These actions are effective when a clear vision exists for the organization, a set of priorities are established, and processes are set in place to implement those priorities. In these settings, project managers become vested in and are held accountable for meeting priorities, not just for practicing their functional skills. These people have become complete project managers.

Today is a good day to be a complete project manager. As multiple skills get added to individual portfolios and personal brands, tomorrow will be even better.

Role Models from the Movies

Two characters in recent movies provide role models for complete project managers—Alice in Wonderland and Wonder Woman. Both the characters and actors who portrayed them exhibit remarkable skills. Figures E-1 and E-2 summarize descriptions found in trailers from these movies. Figure E-3 provides a complete mindmap of topics for The Complete Project Manager.

Figure E-1: Alice in Wonderland as a Role Model

Figure E-2: Wonder Woman as a Role Model

The Blue Butterfly

We end our journey with you the reader by sharing a favorite fable about the infamous blue butterfly.

Figure E-3: TCPM Mindmap

Your fate as a complete project manager is up to you. We have opened doors by sharing thoughts, insights, experiences, and stories. We referenced the ever-expanding molecular structure of organic chemistry as a model for the vast set and infinite combination of skills you may develop. The TCPM Mindmap summarizes the contents of this book. Achieving completeness is an unending journey. The rest of the story is in your hands.