When bad things happen to good project managers
Like it or not, systems fail, miscommunications occur and mistakes happen. We are taught as project managers to keep our eye on the triple constraints of scope, schedule, and cost. Yet there are many unpredictable and sometimes uncontrollable factors in planning for and protecting your project from interruptions and delays. No matter how good and diligent a project management team is, there is no way to prevent them all. The trick is to prevent those that you can and prepare for those you cannot.
So what do you do when you are faced with unexpected events that can seriously derail your project? This paper is an accounting of many of those unexpected events occurring and the steps taken or not taken in order to keep your project on track.
Back in 1996, a Fortune 500 company wanted to consolidate several services onto one bundled bill to the customer. This was a strategic initiative and a project that would: entail a complex integration of over 30 disparate IT applications, cross over 10 Vice Presidential organizations, include teams from three separate companies and involve approximately 1,200 people to execute flawlessly. All previous attempts to manage this project had stalled and an IT taskforce had been established to reengineer a true technical solution that was robust, highly scalable and achievable within a year. I was brought into the organization to Program Manage this effort. Let me also say that with the proper planning, an enormous network of relationships, some well made decisions and, of course some amazing good luck, this project was delivered on precisely the day it was expected, March 25,1997.
When Bad Things Happen
Below is an overview of some of the more exciting and unexpected events that threatened the project and how the Program Management Team responded. This is not to indicate that the approach taken will guarantee success on your project, since each project has its own unique qualities. Rather it is to demonstrate that problems occur all the time and by taking control of the situation, good project managers can often influence the outcome.
The events below are discussed in the order of occurrence within the project. This is also to prepare you for the change in the nature of the problems that you will most likely encounter as you proceed through the various phases of the project management life cycle.
What to Do When You Have No Team—or “Who Wants to Do the Impossible?”
As stated above, all previous attempts to drive this project from a functional perspective had failed. Therefore, this approach was to be led by an independent Program Management Team that had yet to be staffed. Initially, an attempt was made to recruit the top project managers from within the various functional teams within the IT organization. Unfortunately, no one wanted to join a team charged with doing the impossible. All made mention that it was too big, too complex, and would take too long to complete. Therefore, the search needed to be expanded to include nonproject, non-IT members who exhibited a strong work ethic, a willingness to learn new areas of the business, a strong belief in their individual accomplishments and finally, no preconceived notion that this project was “impossible.” The key is that, first and foremost, if you believe it can be done, you're well on your way to meeting your target. This idea is more relevant to the success, than the concept of hiring well-proven project managers. Once project managers believe their project can fail, the drive for success is replaced with a long list of excuses, resulting in missed deadlines.
Therefore, sometimes having no team is infinitely better than taking over an already existing team because you can more easily establish a vision of success. This vision will carry the team over roadblocks that could have stopped a less positive team. It provides a challenge to those faced with issues and problems, engaging them in pursuing ways to remove the roadblock or simply finding an alternate route to the same goal. If too many believe that the project is impossible, go in search of team members who do not know about the project, but who possess a strong work ethic.
What to Do When You Encounter Project Managers in Title Only
With the luxury of building the team from scratch, came the arduous task of interviewing and hiring the right people to join the team. As mentioned earlier, few seasoned project managers were interested in taking the job. This left either new project managers or people with the desire to become a project manager. Having little training in project management at the time, I believed that having a fully certified project manager on the team was essential. In the end, only one out of a team of seven was a certified project manager, and she became my logical choice for lead project manager.
Early indications that she did not know Microsoft Project caused some concern during the initial building of the project work breakdown schedule, but there were many around the room that offered to help. It took approximately six weeks to see that deadlines that should have been met were remaining open with little effort to close. As warranted, after some additional checking into the background of this individual, I discovered that her experience at project management was limited to weekly note taking, requiring little follow-through. When finally confronted with the choice to pursue a task to closure or assume the failure herself, she chose to accept failure rather than to drive the issue to ground.
This was my first encounter with those who call themselves a project manager but do not have the drive or the personality to take the necessary actions that the job requires. In this case, she was repurposed into a different role on the team and a new program lead was selected. The point here is to recognize these situations early enough and if needed, take decisive action as quickly as possible in order to protect the project and the team. It also sends an unspoken message to the remaining team members that weak project managers who use poor principles and practices will be addressed and not left to linger.
What to Do When Key People Don't Show Up to Your Meetings
Regardless if your project is the top initiative of your organization or somewhere in the middle of the list, you may start to see attendance issues begin to degrade your project meetings. By tracking attendance via the meeting notes, one can see if this behavior is a onetime occurrence or a pattern. If it is the beginning of a pattern, one needs to stop it early before things get worse.
Once poor attendance begins to impact the project's deliverables, then action should be taken. In our case, if a key person missed a meeting and failed to provide a deliverable, a call into their manager was made in order to request status from the manager. If you are lucky enough to get a response from the manager, there is no harm done and all will know you are serious about receiving timely and accurate information. Usually, this most likely will be the last time you will need to call this manager since, once this occurs the delinquent team member will forever make sure they have their bases covered.
Once again, this technique should be used only when the issues threaten to impact your project's progress. As one can see, sometimes it's in your dealing with the day-to-day pesky issues that helps you to establish the rules of engagement you and the team are operating under. You also need to be prepared to be a role model for your team, so they see how they are expected to deal with the day-to-day roadblocks that we all encounter. And although organizational culture plays considerably into the building and maintenance of team norms (such as constant late arrivals), it is never too late to break the established norms, if they are not working for the team. The goal should be short, effective meetings that result in key decisions being made, milestones being acknowledged or roadblocks identified and action plans put in place.
What to Do When Tasked to Communicate Weekly Status to 10 Vice Presidents
As mentioned earlier, this was an extraordinary project that spanned across 10 Vice Presidential organizations as well as three external companies. The challenges that this presented were enormous, with too many opportunities for failure. It was very early within the project's initiation that I realized that communication was going to be critical to our success. From my assessment, we needed a solution that could:
• Convey accurate and understandable information to the lowest level of management up to the CIO.
• Be created easily on a weekly basis and continue for a year and a half.
• Satisfy both a text-based and a visual-based audience in one package.
• Adequately reflect each functional status, while allowing the Bundle Bill Program Team to declare overall Project Status.
With such a list of requirements, my first and most important task was to use one of my open job requisitions to hire a fearless communications expert. Once again, I went beyond the walls of the IT organization to recruit an individual with experience in public relations, human resources, executive staff support and had a master's degree in English. Her role was to build the communications plan and to help each program manager to create, produce, and wordsmith the weekly and monthly status reports.
This was, by far, one of the most important decisions made and paid for itself time after time in well-communicated and well-understood progress reports that clearly reflected the truthful status of the project and most importantly, offended no one. Because of the behavioral dynamics involved, it was critical to remain objective, using facts whenever possible to support key points and never embarrass anyone. This, on occasion can be very difficult and necessary when trying to convey an issue without blaming any individual or organization. By hiring a communications expert to join the team we were minimizing the risk of failure of the project by miscommunication, which is the number one reason why most projects fail.
While many projects will not face the need for such intensive and frequent communications, it is important not to underestimate how critical and essential good communications will be to your success. Good writing and presentation skills are a learned and trainable skill but are often not a valued skill in the IT world. Good communication skills can be more important than basic project management skills for it involves the same basic principles with additional keen insight into how people listen, learn, and react to the same message. Since 90% of project management is communication, the more attention and emphasis placed on stating the essential and relevant facts, the better chance your project has to succeed.
How to Handle Multiple Stakeholders Who Cannot Agree
Frequently, large programs that cross over multiple functions, result in program manager's being confronted with satisfying many stakeholders, usually with different agendas and priorities. This project was no exception. It only took escalating an issue once to the Vice Presidential Governance Team to realize they could not agree on a solution. Luckily, the issue did not require an immediate decision, so time was not yet a critical factor. However, it was essential to arrive at a solution in a few weeks in order to maintain the original project plan.
It was clear that this collective Governance Team never had to make real-time decisions as a team and as a result, had difficulty negotiating their way to a solution. Therefore, solutions needed to be directed at the lowest level possible, for it was the day-to-day project managers and developers who understood the tradeoffs involved and had much more experience in negotiating their way to an acceptable team solution. By having the project team decide on the issue and brief their own executive management team on the decision, the program avoided getting road blocked at the executive level and the project continued on schedule.
The lesson, then, became to avoid taking any and all issues up to the executive team for decisions. Rather, issues would be socialized with the executive team to solicit suggestions and to occasionally test the sensitivity of the political landscape. However, no decisions were ever again presented to that team. Instead, the solution, with the associated pros and cons, would be presented at a subsequent review, keeping the discussion at the “for your information only” level. This approach worked exceedingly well, throughout the life of the project with the added benefit of pushing the decision making authority to the lowest levels of managers and to those ultimately responsible for the on-time delivery of the project.
How to Handle “Major” Changes In Scope
It is an extremely rare occurrence to take on a project of this length and to never encounter scope creep. However, with this project we were frequently tasked with major changes in direction and size. Initially, the plan was to include and consolidate the billing for all internal consumer services. After several months into the project, came the directive to include an external satellite dish company. A few months after that, came the requirement to add an external cable company. In each case, the Program Management Team was not empowered to say “no” to these late additions, for the business case was too overwhelming. At each juncture, the entire team needed to stop, return to the requirements stage, re-scope the project and revisit the functionality list. In each case, the end date was to hold firm, with absolutely no slippage.
In both cases, the team was able to set parallel project paths in motion, allowing the late additional partners to progress thru the various quality gates on a slightly modified project plan. Furthermore, they were given approval to miss the first phase of Integration Testing, entering testing in a later phase. This solution was a result of the creative problem-solving capabilities of the project team. While this approach complicated an already complex project, it provided minimal disruption to the bigger project and minimized the risk introduced by changing scope midway through he project.
The good news once again, was that the original program continued on its original path, with most of the team members highly committed and able to visualize that the delivery date was within our grasp and quite possible to achieve. This momentum went a long way to having every team member do whatever was necessary to keep the project moving forward. Well, almost everybody.
What to Do When Mutiny Occurs in the Twilight Hours
There ultimately comes a time within your project when the naysayers begin losing ground. More and more people will begin striving toward delivering a successful project, believing that they do not want to be the reason for the project's failure. This is a great turning point and pivotal milestone for the team and the project, for now it will involve much less struggle and much more cooperation. Unfortunately, however, for others who are used to being the center of attention and in the spotlight, this is the time they may try to assume ownership of the project. Apparently, careers were being threatened and success was within our reach, so we became the target for a takeover attempt. This was indeed the situation I found myself in, and fortunately for me, I never saw the effort coming. I simply found out about it the morning after. The “revolutionary team” planning the takeover called a late night emergency meeting of all the stakeholders and sponsors and proceeded to make a bid for taking over control of the project.
Without being in attendance at this meeting it is difficult to relate the specifics. Suffice it to say, that speeches were made on how or why it made good sense to replace the current Program Management Team midway through the project. In the end, the sponsor declared the project would go on, as usual, being led by the independent Program Management Team. There are times within the life cycle of your project when one cannot predict or anticipate a situation and one must trust what has been set in place to help sway the outcome. As the Program Manager of this effort, I was frankly surprised that anyone wanted to take over this project for despite its apparent success so far, it had already proven to be a difficult and intensely time consuming effort to keep this project on schedule week after week.
Despite the failed takeover attempt, there was no ill will between the “revolutionaries” and the “originals” for we needed each other to complete the project and it is always better to take the high road in cases such as this. For the remainder of the project and since success was within our grasp, we carved out a few small independent efforts, such as interface and integration testing, that could be broken out and given to the revolutionaries to lead. The lesson here is that everyone wants to be associated with a successful project. Luckily in this case, the project was so large and so highly visible that there was more than enough work to go around so all could feel an essential part of the success of the project. This truly became a great example of a win-win outcome for all. Additionally, it was one of the only instances where the Program Manager's role was to “do nothing,” for the politics and emotional battles can be extremely disruptive and nonproductive to the entire project. If something is completely out of your control, stay focused on your project and keep it constantly moving forward; hopefully right will prevail.
Responding to Last Minute Requests From the Executive Team
Inevitably, these occurrences happen late on a Friday afternoon and threaten to throw the project team into a state of frenzy. Ours came late on Friday afternoon from the Executive Assistant of one of the Vice Presidents. Apparently, as a result of the monthly status report, the VP had decided that he would like to read all of the detailed technical requirements documents from all 10 functional areas, over breakfast on Saturday morning. His home address was provided and despite our best attempts to dissuade this request, we were told to “just do it.”
After calming the team down, it was clear the request could not be ignored. We were being tested to see if we did indeed have a full set of documented project requirements, as we had reported. Although we did not have them onsite within our offices, they did exist at several offices across the country. The entire program management team became engaged in phoning all key project managers with explicit instructions around this late night FED EX Adventure. If we were being collectively challenged regarding our projects’ artifacts, well, deliver them we would.
On Monday afternoon, after hearing nothing from the executive office, we called to inquire if all was received in a timely fashion. The response was, “Don't do that again.” The lesson here is to make sure you manage your project's deliverables and artifacts for you never know who will want to see them and when. Furthermore, it adds to the teams’ credibility if you can provide the documentation to support your project's status. This experience resulted in at least two benefits: full and long-lasting support from that particular VP and a rallying event that allowed the team to demonstrate a joint, united regardless of functional alliances—finally a team is formed!
What to Do When Your Critical Resources Are Stolen
Oftentimes, there is a sequential order of projects, where work on one project needs to occur prior to work on subsequent projects. This indeed was the case with this project, and there was serious trouble on the first project. Unbeknownst to our Program Team, key developers had been pulled away from our Bundled Bill Project to work round-the-clock on the project in trouble. For months, the project manager of that team had indicated that all work was proceeding as planned and our end date would be met. An impromptu visit to the offices of the development team revealed the worst: no work beyond requirements had been done yet on the Bundled Bill Project.
The first action was to understand the decisions made, understand the dependencies between the two projects and work jointly across the two projects to bring them both back on track. Apparently, both projects required the same highly skilled developers and no additional external consultants were available for hire. Furthermore, our project depended on functionality that was to be introduced by the project in trouble, so we could not separate ourselves from that project.
The solution once again, came from the low-level project managers: simultaneously commit all impacted developers to finish the first project, while using other analysts to re-scope the requirements, thereby significantly reducing the coding effort needed on the Bundled Bill Project. All others on the project were to proceed according to the original schedule with the hope that this team could catch-up to their counterparts with their simplified requirements.
This series of events resulted in several positive changes in the project. First, all now knew that any one who misrepresents the actual status and progress of the project would be called to answer directly to the sponsor. Second, by contacting the Program Manager directly with bad news, the team members would reinforce ownership to the project because immediate action will be taken. This last point is fundamental for if the Program Manager will not do all to help the project you cannot expect any different behavior from others on your team. Since the deadline was critical and fixed, and resources were finite and constrained, the only choice remaining was a change in scope, with full steam ahead. However, always keep an eye out for those other projects running ahead and along side of yours, for they can add an element of risk to your project when you least expect it.
What to Do When Your Users Will Not Engage
In today's corporate world it is difficult to find a project that does not have to withstand some organizational realignment. While the Program Management Team maneuvered their way through four organizational changes, this was not as disruptive as the endless reorganizations within Marketing and Sales (M&S). This was our user population, the ones who determined and dictated requirements and the ones who funded our work. Unfortunately, there is nothing like constant and frequent reorganizations to distract people from the business at hand. After numerous failed attempts to solicit requirements and process workflows from our M&S clients, it soon became time to declare the project once again in jeopardy.
Fortunately for us, however, many of the Bundled Bill Program Team came from Marketing and Sales, so we had several people who understood the project's objectives. Furthermore, many of us had a vast informal network of people we could tap into to define the requirements and work flows without formal direction from the client. When the reorganizations finally stopped, we had compiled the necessary documentation that simply needed validation, rather than creation. This partnership approach and solution was actually provided by our sponsor and CIO.
This is but one example of how good decisions made early in the project, can pay for themselves later on in the project life cycle. By having a team with a diverse set of skills and backgrounds, we were getting quite good at suggesting and executing on unique solutions in order to keep the project on track. We were also quite skilled at quickly reacting to change; we knew this drill by heart.
What to Do When Corporate Policies and Procedures Change
It's December, snow is falling, and the holidays are fast approaching and its time to get capital approval for the hardware needed to support the project. All that is needed is one Vice President's signature and all will continue on track. By this time we were reporting to our third VP, yet all were clear on the importance of keeping this project on schedule. Unfortunately, with many starting their vacations early, the current VP decided to wait until the New Year, when all the stakeholders are back from the holidays. Little did anyone know that effective January 1, 1997 a new capital expenditure policy would be engaged, resulting in required signatures from numerous VPs, the CFO and the President and CEO of the company.
First, despite no formal approval to purchase the hardware, I knew that the manufacturing process was now my critical path and we could not wait until January 1st to begin this work. Therefore, on December 24th, I made a call to the vendor and gave the Sales Rep informal approval to begin the manufacturing of the hardware with an anticipated ship date. This capital expenditure was well over $2 Million, which far surpassed my authority and was the riskiest action in my 22 years of professional experience. My rationale was that surely by the time the equipment was ready to be shipped, I'd have all my signatures.
The month of January and February passed in a blur of filling out capital expenditure forms, creating business cases, chasing down paperwork, writing and rewriting financial justifications, and making copies of signed paperwork, for those times the paperwork was accidentally misplaced. Meanwhile, two events took place, neither one within my control that were critical to making the deadline.
While still missing the necessary signatures, I instructed the vendor not to ship the equipment in order to prevent invoicing. This instruction, luckily, the vendor soundly ignored. The hardware arrived at the correct destination points and once again I give clear instructions, not to unpack the equipment until all signatures were finally obtained. Once again, my directives were ignored and the hardware was unpacked and powered up for the testing process. The point in this is that there comes a time when all your best laid plans and best efforts may not be enough. I had taken as many personal risks and knew that others along the way needed to do the same. By communicating the status and potential risks of not having the hardware in place, I had provided the necessary air coverage and publicity that if we truly needed to stop, all they needed to do was to tell us. Week after week all knew the risk we were carrying by moving forward without the necessary approvals. All signatures were finally received by February 12th, well into Service Readiness Testing.
How to Handle When Others Take Credit—or “Finally, You Have Arrived!”
If all goes well, you will have such forward momentum that many will be engaged in helping the team to finish. When you're successful, everyone wants to be included in the celebration. Additionally, there will be others, who want to link themselves to the project, and claim credit. If your communication vehicle is consistently and widely distributed, there will be no doubt to who can claim credit. Although many may speak the words, few will have the documentation and facts to support the words. That being said, however, when possible, a good Program Manager will ere on the side of inclusion rather than exclusion for it's impossible to know everything and everyone involved in making a large project successful. A project of this magnitude requires thousands of people, all doing the right things at the right time. In this case, because the project was so big and involved so many, it was easy to be gracious and give credit, thanks, and recognition to those who played a role, no matter the size of their contribution. And by being inclusive, you may meet resources that will want to participate on your next project.
How to Handle Resentment From The Others—or “How to Handle Success”
After all the collaboration, the project closeout and the portmortems there may come a time when a negative backlash occurs. It can happen during the hand-off to production, or when true volumes get pushed through to stress test the quality of work or as it was in my case, during future projects. Recall, in the beginning, while I went after some of the best people within the IT organization, none came willingly to this project. And yes, it was a clear case of the underdog team, delivering a project that most thought impossible to deliver. Furthermore, by quickly resolving most issues, having contingency plans and spending long days and nights working behind the scenes, the effort looked easy. And while it looked easy to those on the outside, it was a tremendously challenging effort that not only resulted in achieving key business initiatives but pushed people to perform at their personal best.
For those who were a part of this effort, they had the joy and satisfaction of participating on an extremely well managed Program Management Team. For those not on the team, many felt left out and I site this exclusion as the key source of resentment that followed the Program Management Team in the months to come. In the end, it was far easier for the organization to fall back into their old ways of handling projects; missed deadlines once again became the norm. The Program Office and Program Management Team were dismantled and disbanded and all were redeployed to other teams.
In retrospect, there was little I would have done differently had I to do it all again. It was the most challenging project of a lifetime and together we learned that the tenets of good project management work extremely well when you have a team that believes anything is possible.
There are many events that can occur that your basic project management toolbox will not address. Interestingly enough, it is precisely these events that make the people skills so critical to successful program managers. As stated by Karen Clarke, PMP, and David Winsborough, in “Projects and People: A Marriage Made in Heaven,” the competencies for superior project managers include three basic components:
• The ability in dealing with and relating to people
• The ability to navigate through competing interests
• Unshakeable faith in their ability to achieve a successful outcome.
This is not to downplay the importance of the good use and application of tools to help a project manager plan, monitor and control their project. By all means, use the tools for they can often give you early signals that are indicative that something is not quite right. However, when you finally discover what is happening, act decisively and confidently to minimize the impact to your project.
Remember, bad things happen all the time; it is how we handle it that often makes the difference.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA