A Tale of Three Projects

This paper will use three projects as the background to communicate lessons I learned during my project experiences, both good and bad. The first two projects are not affiliated with my current employer. A key to successful projects is to learn from past project failures and to put those lessons learned into action. There is a biblical saying, “there's nothing new under the sun”; I agree with that wise man. Another key is awareness, knowledge of what is under the sun, both new and old lessons.

I selected three from my pool of project encounters for this educational journey. You know the saying “no pain, no gain”. This paper documents the gains based from my experiences. You'll likely benefit from my pain, not yours. I learned to endure stressful environments, trust my instincts, what to avoid, and other lessons from toxic corporate political project environments. One project with “leadership gone wild”, another effort contained heart attack levels of stress, and the last one was a “fire-set-ready” culture.

It's common knowledge that learning from our experiences is often the best teacher. But you do not know what you have learned until you face a situation where the lesson learned should be applied; until then, it's just a tool in your project management tool box. This paper aims to provide you with some new tools. Since “hindsight is 20/20”, you'll likely get the benefit of my past experiences and walk away gracefully and wiser.

Introduction

Project management is a science, or maybe better stated, a discipline of planning, and managing resources to bring about the successful completion of specific goals and objectives – and much can happen on the journey to specific goals and objectives. Projects, by their very definition, are unique in nature. As a result, project managers, teams, and organizations need to find advantage before endeavoring in these “unique beasts”. I believe we can learn from previous experiences and (hopefully) transfer that knowledge gleaned during a project's lifecycle on to future projects. A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)—5th Edition (Project Management Institute, 2013) defines lessons learned as the learning gained from the process of performing the project. I think it is how we fare on the journey that develops great leaders. Staying on the journey no matter the result is an investment in integrity and if you learn from that journey, it will produce a high return on investment (ROI). John Maxwell says, “A continual investment in your leadership development will eventually produce results. It is the capacity to develop and improve their skills that distinguishes leaders from their followers.’' (Maxwell, 2007, p. 3)

Oracle (2011) cites the following:

There is an age-old saying that goes something like this: “we can do anything we want, but we cannot do everything we want.” This is the classic conundrum that most, if not all, firms face. Organizations across industries are challenged to deliver an increasing number of projects and programs, while maintaining flat (or decreasing) budgets and resources. In such an environment, only one outcome is possible...project failure.

Are project failures considered normal? Long-held beliefs and studies have indicated that a majority of projects end in failure, perhaps suggesting that project failures are becoming an accepted norm. The oft-referenced, now decade-old, Standish Group Chaos Report cited a 31% project failure rate effectively lowering the bar, and along with it any optimism for a successful project effort.

Since most of us are fully vested in their present journey, I have another way to compound my returns – learn from others. This paper will use three projects as the background to communicate lessons I learned during my career. The first and second projects were experience with former employers. This paper will provide an opportunity for you to glean from my experiences and possibly gain an advantage to effect the results of your current or future project.

If you work long enough, nearly everyone will face challenges during projects and with clients. I believe that reading, understanding, and processing learning experiences can also empower you. The first two projects are not affiliated with my current employer. So like the Good Witch Glinda said to Dorothy, “You've always had the power my dear; you just had to learn it for yourself.” (Wizard of Oz, 1999)

Project 1

I worked at my first Virginia company and was assigned to a very large Management Information System (MIS) implementation project in a mainframe and client server environment. It was an effort to upgrade a state's legacy mechanized claims processing and information retrieval systems by integrating custom packages and enhancements. It was to be a five-year effort with a total contract value greater than $60 million. Our role was to provide project management oversight on the developer's five geographically dispersed software development schedules, and integrate them with the main schedule in Richmond, VA. We created and maintained the integrated master schedule and reported to the developer. The end user was the state of Virginia.

After about two months of being assigned to our two-man project management office, my senior project manager felt comfortable enough to take some vacation. He gave me some sage advice, “If you attend any meetings, don't say anything just take notes.” I was holding down the fort; all was well until I attended the vice president's (VP) weekly meeting. This was the weekly meeting where the functional leads reported to the VP. I attended the meeting with the intention of taking notes to share with my colleague. As the hour came to a close, the VP asked the group for any final remarks and the gentlemen around the table responded in turn. After the last manager spoke, I was surprised when the VP asked if I had anything to add. I looked at my notes, remembered what my senior PM had told me and still said, “I did notice that the data on the two Dallas schedules was not current and seemed to be about two months old.” I had not followed the advice given and received new actions from the VP.

Even though these two external schedules were not on the critical path, their products were still important to the overall success of the project. Just because an item is not on the critical path does not make it unimportant – everything is important and allows the tools and the analysis to convey concise metrics to the stakeholders.

Now that we were keeping ALL the schedules current, it made our integrated schedule a better forecasting tool because we were now incorporating more and timely data to the Integrated Master Schedule (IMS). As time went on our project management office learned to incorporate other forms of data into the schedule.

Some of the other forms of data were notes from the VP's meetings with the end user. Occasionally, the VP would return from a meeting with the end user and would casually mention how he had agreed to a new requirement. His returning from meetings with new requirements evolved from being the exception, to being the norm. It took us awhile to translate his scope creep into schedule delays. It took us even longer to communicate the impact that he, specifically, was having on the success of the project.

Another form of data that we needed to incorporate into the schedule was the addition of the lead IT development manager. We thought his arrival would bring a greater sense of leadership and organization but he introduced a new level of toxicity to our environment. If his engineers shared challenges or failures with him; his face would turn bright red and he would verbally erupt. This response did not encourage staff to communicate honestly with him. So they told him what he wanted to hear and they told us, theproject management office, the truth.

Our bi-weekly status meetings became a “three-way tug-o-war” – it was a battle between theproject management office, the VP, and the IT development manager. The project management office would present the impact of all known data to the schedule and the VP would attempt to defend the new scope while the lead IT manager would say, “This is the first that I have heard there is a problem (delay) with my engineering team.” Our goal was seeing and having the team come together as demonstrated in Exhibit 1. In reality, Exhibit 2 is a better image that shows our divergence.

Exhibit 1: Convergence

Exhibit 2: Divergence

Our project management office was asked to enter into year two of the five-year contract. My company's leadership reviewed all known elements influencing this project and our ability to communicate the impacts to the developer. Corporate leadership responded to the contract extension request by drafting and delivering a formal letter of recommendations. The first two items on the listwere: (1) the removal of the vice president from the site and (2) the removal and replacement of the lead IT development manager. The letter had few other actionable recommendations.

Since our client was not acting (making informed decisions to benefit the project) on our observations or analysis, and did not respond to our formal letter, we perceived that our team was not adding value or making a positive impact on the project. Our leadership decided to dissolve our relationship with the developer. We walked away from a five-year contract. A few years later, I attended my first PMI Symposium in Texas and an engineer from this project told me that the project failed. It ended four months behind schedule and the end user sued the developer and the court directed the developer to reimburse all previous payments to the end user.

So looking back on this effort, here are a few things I believe I would have done differently or sooner:

• I think I would have provided to my client, the developer, articles or references from other similar projects; I would have done more of educating my client. That strategy is supported by the article I referenced (Oracle, 2011). “Passing over your brain is not an easy task, but without your input these pieces of information will remain lost forever. Make a bullet point list of the things you have on your radar and give them a fighting chance of being ‘you’ effectively.” (Symonds, 2014, p. 2)
• I think we could have escalated our concerns sooner and higher up in developer's organization. During the effort, we shared our concerns with the leaders onsite. At the end our concerns were escalated to the upper echelons of the developer's organization but by the time it reached the appropriate decision maker, we were off the project.
• I think I also would have changed the meeting dynamics. That strategy is highlighted in more detail in an article I referenced (Bison, 2014). We mostly reported to the executive team; we may have gotten more positive results meeting one-on-one with the VP or possibly gone directly to the end user. I do not think we could have influenced the developers hiring activity but we could have created a report that showed the impact that his “negative behavior” was having on the project and overall morale of the development team. The impact of negative behavior and strategies to address it are addressed in the article I referenced (Lucero, 2012).

So those are a few things, I would have done a little differently.

Project 2

After almost ten years with the “Project One company”, it was time to move on to another employer. I was with a new company and held a new title, Director of Program Management located in Virginia. I oversaw the daily operations of the company's project managers located in California; had responsibility for hiring, managing and developing project personnel and advised the Chief Operations Officer (COO) and Chief Executive Officer (CEO) on the portfolio of projects. I also led a diverse team of military/industry executives, eight scientists, and engineers in project efforts and managed the research project team in developing timelines, milestones, and critical path. With my project manager hat on, I provided oversight to the company's Army, Navy, and Marine Research, Design, Test & Evaluation contracts; acted as the Senior Project Manager, responsible for a $5.8 million effort for a military client; supported several U.S. military services in exploiting signal processing technology on a counter-Improvised Explosive Devices (IED) project; and facilitated improvements to active and passive sonar technology on another military project. In summary, my job really entailed being responsible for managing and working with several diverse types of human resources. During this assignment I worked with these resources: C-level executives, scientists, lobbyists, direct reports, and clients.

I was hired to help alleviate some the work load that the COO had acquired and to develop project management as a core attribute of the company. Our projects were funded through congressional set asides.

Instead of trying to win contracts to fund the company, we had the challenge to find qualified projects to spend the money on. One of the gentlemen (a lobbyist), in our federal office located in Virginia, asked me to come to his office to explain to him a basic understanding of organizing a project. I entered his office to see three or four congressional golf bags and lots of pictures of himself with senators and other important looking people. I took a seat and started to expound. I concluded my oratory and asked what it was for. He said, “It is better that you don't know.” I left his office with a puzzled expression and a frnny feeling in my gut.

One Monday, I was busy reviewing or creating a report when I heard and felt a “thud.” We were located close to the airport so I thought maybe it was a sonic boom. Minutes after the thud, a fire truck pulled up to the building and from my second floor window, I saw a stretcher and several firemen enter the building. I went to the stairs to see what was happening, and to my surprise they came up the stairs past me and headed towards and into my boss's office. The source of the thud was my boss. He was in the hospital for over a week. The doctor said that his heart attack was stress related. The difficulties did not end there, though.

The company had partnered with a group of scientists to introduce their patented technology into military applications. I had been attending a working group that was reviewing solutions and concepts to deal with reducing the deaths and injuries caused by IEDs in Afghanistan. So after many months, I was very excited to finally bring something of value to the working group. I had to meet three of the scientists at the airport and escort them to meet with and present their technology to the working group. The scientists presented their technology and seemed to have healthy, productive discourse. Based on my observations, it was a good meeting. We left the military facility and went for a meal to discuss the next steps. The scientists spent the bulk of the dinner voicing their dissatisfaction with the meeting. I had wrongly assumed that scientists were like engineers and their triggers/motivations were the same. I was a degreed engineer with a history of working on technical projects, building project plans and schedules with inputs from these technical subject matter experts (SMEs). Before our next meeting, I bought a book and read about their technology, spoke with a few PhD candidates to get their perspective (scientists can be extremely protective of their theories and concepts), and interacted with the scientists in casual non-academic environments.

At some point after a vacation, I was back in my office on the phone with a friend while looking out the window. During the conversation, I noticed that a police car had stopped a black car in the parking lot. I assumed for speeding but when the occupants of both cars got out they shook hands and the officer returned to his car and drove away. The black car parked and then nine other similar looking black cars pulled up and parked in line with the original black car. All the occupants of the black cars were wearing bright vests over their suits and they seemed to be coming towards the front door of our building. It reminded me of a scene from a movie. I jokingly told my friend, “In case something happens, I will need a witness so I won't hang-up the phone and when you hear anything out of ordinary…” We laughed. A few minutes later there was a knock at the door. I said, “Come in.” The door opened and two strange men, who were wearing vests, filled my door way. I was asked to come to the conference room. As I left my desk, I had a thought that this could be a surprise party for my boss based on prior experiences. So as I walked to the conference, I expected to see cake, gifts, and hear festive music. I entered the conference room to see scared people sitting around the large conference table. We were experiencing a federal investigation. This was confirmed during our individual interrogations, our early release to go home, the stacking of our discarded papers and the copying of our laptop/desktop hard drives. I discussed the incident with my father; he advised me to change companies immediately. My CEO and COO assured me that we, the company, were not associated with wrong doing.

It took a few months after the raid for business to return to normal. I had returned from one of my monthly trips to the corporate headquarters in California and I was driving my father to a medical appointment. As we pulled into the parking lot, he asked, “Are you still with that company?” I replied, “Yes.” He responded with a shaking head and a contorted face. Four weeks later, I was with a new company. Seven months later, I was signing in for a meeting and on the TV monitor in the lobby, I saw my previous CEO being ushered away to serve the sentence for federal charges.

In hindsight, I should not have left my previous employer to come to this environment. My actions are supported in the cited article (Maxwell, 2007). I know some people actually journal or document unusual events or conversations and during some downtime turn to their journal and reflect on the documented event. I now journal and capture my gut reactions to conversations and unique circumstances. I'm sure the memory of most project managers is very keen but documenting the results of effective and ineffective strategies throughout the project lifecycle will be a personal benefit and great benefit to the project close-out activities. Waiting to the end of an effort to do group brainstorming to identify past problems and successes, is no guarantee that the group will recall the innovative strategy that put the team back on schedule. I believe it is better to journal than to rely on people's memories. You may wish to adopt this discipline in your current or future project.

I believe if I had captured all the red flags that I would have seen a pattern and either left earlier or would have confronted earlier. Similar steps were done in the cited article (Whitten, 2009). I also value and act faster on my mentor's advice. So if you don't have at least one trusted advisor in your life, I strongly recommend that you begin the process of finding one. Until you find one or more mentors, please use online professional communities to share your situation and get the group's feedback. There is similar advice in the referenced article (Maker, 2013). You can even go to PMI's annual congresses, network with your conference peers and glean from their insights.

Project 3

Of course, you can learn from projects executed in any location, not just Virginia as noticed in the above two projects. This next project was based out of Washington, DC. The company was contracted to provide project management and project scheduling to a governmental agency to support multiple management initiatives with the goal to generate revenue or reduce operational expenses. The main focus was to design, develop, and manage some very, large, integrated schedules.

One the first things I did when joining the effort was to review the original schedules. It seemed that the schedules were built from operations and methodology documents and were lacking milestones, dependencies, and visible goals. Our team facilitated a meeting to lead our government client through the planning process before we built a repeatable, executable project schedule. The meeting was not fruitful until we cracked the communication barrier – pictures do work! We illustrated the key activities and major milestones. With these pictures in the place, we were able to confirm our understanding of their priorities and their definition of success.

We were going to need to build schedules using the client's scheduling tool to execute the consolidation of over four hundred processing facilities. It took myself and two government SMEs a week to build the schedule template. The template was great. It was the basis for the production of the schedules that were distributed to some of the processing facilities across the nation. It was decided that this would be a phased-rollout. It was a good decision, but this “fire-set-ready” culture prematurely distributed the schedules. When the initial phase of facilities began to execute according to the schedule, there was some confusion on the durations and the task descriptions. Before we distributed the schedules for the next stage, we had an offsite meeting where a sample of facility managers and all of the area coordinators clarified the task descriptions and adjusted the task durations. These updates and consensus produced a better template which led to smoother execution of the rest of the facility consolidations. The tweak resulted in less confusion and more importantly little to no service delays.

Phase 1 was a success. We had some bumps in the road but we overcame and adapted. Our project management office supported the successful implementation of 190 consolidations which resulted in a $748 million in cost savings through year-end and $2.5 billion through FY17. I realize now that another key to this project's success was that the hiring manager had created a team with a mixture of experienced schedulers and proven processes.

We will be starting Phase 2 later this year. The team composition has changed but we have included several lesson learned reviews prior to the startup of this next phase.

Summary

Projects are unique and challenging. Leaders are unique and need challenges to overcome. It takes a team to deliver a project. Therefore, leaders and teams should seek to learn and continue to learn. They should learn from the experiences of others and from previous events. If the team will make time before, during, and after the project to evaluate past accomplishments and past disasters, their multiple perspectives of the project experience will prove invaluable and will most likely prepare them for their next “bump in the road”.

One of the ways that you can instill the discipline of lifelong learning is to agree that learning is a best practice. This learning and successful execution supported by lessons learned can lead to making better project managers and better project teams. I believe project managers are not “old dogs”. We must learn new tricks. If not for the sake of a lifelong learner attitude then, we must learn for the sake of our careers, our project teams, our organizations, our clients and our future projects.

A key to successful projects is to learn from a past project's successes and failures and then apply those lessons. Pastor Charles Swindoll once stated in a radio message that, “Attitude is more important than the past, than education, than money, than circumstances, than what people do or say. It is more important than appearance, giftedness, or skill.” I believe from lessons learned, you can forge an attitude or a mindset that will sustain you through many a project. “To consistently build the best products, provide the best services, and create the best teams, you must think and behave with the mindset that you're the best at what you do.” (Whitten, 2012, p. 1) The way an individual and the team approach a project is important. This might be one of the other differences between leaders and managers. You may not be able to influence the team but each individual has control of their mindset. I believe that a combination of a professional attitude and an optimistic expectation can help you better prepare yourself for the little surprises, the unknowns that can occur during the life of a project engagement. A good mind is a great ally in avoiding problems and/or reducing the impact if any problem occurs during your project.

The following are a few brief statements (some actions) that I have gathered along the way that have helped me to build my “be-the-best” mindset:

• Focus on what matters; your personal goals do matter
• Do not fear conflict; prepare for conflict
• “The righteous falls seven times but gets up again…” (Proverbs 24:16, New American Standard)
• “Play like a CHAMPION Today” – (University of Oklahoma Sooner Locker room)
• Identify the things that are guaranteed in life
• Take the time to build a life (long term life/career) plan
• Celebrate any and all successes; start any new project with a gift to yourself

Insights gleaned from these three projects combined with the wisdom from the above statements will help make you wiser and remind you that you are empowered to handle anything that comes your way.