Day of Reckoning

That Funny Feeling

Every Project Manager knows that there comes a time in every project when the day of reckoning arrives. 

This is when you get that funny feeling. Everything is going according to plan. Matters are progressing as anticipated. Everybody is happy and satisfied with their assignments and loves working their fellow team members. Your Sponsor is appreciating your efforts.

Then suddenly your project’s Sponsorship changes. Before you know it, your day becomes night. 

Everything is on its head and out of control. Suddenly, you find yourself in a parallel universe. Only, this time you appear to have a project in serious trouble, resources in conflict, ambiguous scope, and plans that make no sense at all. 

Worse of all, no one seems to remember what was said in meetings, what agreements have been reached with whom, and what objectives have been set. Your friends are no longer your friends. Even the documentation that’s been signed-off suddenly appears ambiguous and incomplete.

What is going on?!

The day of reckoning is upon you. This is when your metal as Project Manager is truly tested. 

Soon you have to work your way through a well known and familiar contagious corporate disease - the disease known as voluntary Collective Amnesia Syndrome (C.A.S). 

“Amnesia is a condition in which memory is disturbed. The causes of amnesia are organic or functional. Organic causes include damage to the brain, through trauma or disease, or use of certain (generally sedative) drugs. Functional causes are psychological factors, such as defense mechanisms. Hysterical post-traumatic amnesia is an example of this. Amnesia may also be spontaneous, in the case of transient global amnesia[1]. This global type of amnesia is more common in middle-aged to elderly people, particularly males (or corporate managers), and usually lasts less than 24 hours.” (Wikipedia) 

In severe corporate cases, attacks can show a stubborn high frequency of occurrence, and may in some cases turn into a permanent condition depending on the state of dysfunction in management of the organization.

C.A.S. affects all companies and business, especially the large national and multinational conglomerates with many management layers. It strikes equally ferocious on vendor and client side of the equation.

When the day of reckoning strikes you call upon PMBOK’s tenth knowledge area. You can also call this the tenth commandment of Project Management. It is a knowledge area that applies to all five process groups: Initiation, Planning, Execution, Monitoring and Control, and Closing. The Knowledge Area is better known as “Cover Your Ass” or “CYA”, for short. 

“The acronym CYA, meaning cover your ass (or arse), as well as being relatively widespread urban slang, is also commonly used by a number of professional bodies, in relation to procedures which are perceived to be purely defensive against legal penalties.” (Wikipedia) 

If you excel in this Knowledge Area, then you have the stamina and integrity to work your way through the issues no matter how harsh the reckoning proves to be. They say: “When the going gets tough the tough gets going.” 

However, if you don’t have this Knowledge Area under your belt as a seasoned and well experienced practitioner, and have not applied it rigorously throughout your project, then it is time to rather use the other definition of “cya” - meaning goodbye. Someone else will then have to pick up the pieces and try to reassemble the puzzle, while you write it off as good experience and another notch on your C.V.. 

In this Blog entry I wish to elaborate a little on the application of above mentioned knowledge area. I will share some practical examples of practices that will help you excel in the application of C.Y.A. for your current or next assignment.

Administration

It is a well known fact that there is a lot of administration associated with the management of a project. Therefore, don’t under estimate your responsibility for the management of these administrative components, and if you delegate administration to a project administrator, then guard this delegation with a hawk's eye. 

Firstly, a project has formal artifacts like the Project Charter, Statement of Work (Scope Statement), Project Plans, Reports, and more that you have to manage and administer. There is a reason why these are called “formal” artifacts. 

Like the work products delivered through the project, these artifacts (which can be documents as well) serve as project deliverables. Equally important is the version control, change management, audit, and customer or stakeholder acceptance for these deliverables. 

I have seen more than one Project Manager fold when the chips are down and these artifacts and scrutinized or used to defend a project/program's position. For example: It is devastating if he or she cannot rely on a clear Statement of Work signed by the Project’s Sponsor – often, these documents are supposedly “accepted” and the signed copy missing. 

The only advice I can give here, is that these artifacts are the basis for any C.Y.A. effort. Don’t neglect it, at any cost. It is the basis for the professional management of the project. Without these, forget successful project delivery.

Don’t be maneuvered into proceeding with a Project unless the above artifacts have been agreed, signed and put under configuration management at the appropriate stages of the project. 

If formal artifacts is the main course of this meal we call a project, then your working materials (like draft copies, previous versions, notes, emails, conversations, meeting minutes, etc.) are the settings for the table. It provides the context for aforementioned formal artifacts. Don't neglect or discard these. The items are equally important because it provides the supporting information, background and circumstances for the formal outputs. 

Often, one may find statements in a report, when reviewed a few months after the event just don’t make any sense. This is when the working materials play an important role to clarify the original intend and context of the statements.

One of the golden rules I’ve learned as project manager, is how effective I plan and execute my project’s communication plan. It includes both the formal communications like status meetings and presentations, but also the informal communications like email, informal feedback, water cooler conversations, etc.. Don’t keep your project a mystery to the stakeholders (unless it is required to ensure its success). Be sure that you have a well crafted plan to communicate to, and solicit from stakeholders all materials that may prove of value to the project team's execution and the project's success.

Get used to hoarding these materials. Catalogue it and index it. You may never need it, and then you just may one day depend on it for the life of your career.

One very effective and inexpensive manner in which you can collect, classify, publish and continue to maintain all the above is through a Project Wiki. Some Wiki's also allows the storage and version control of documents and files. It provides a forum where the project's administration can be stored, where it is accessible and editable, where stakeholders can collaborate, record, interface, and also where all accompanying materials can be published and stored.  

Relationships

It is always amazing how quickly “supposed” friendships dissolve when a project is in trouble. 

While the project is going well, everyone is on good terms with each other during work, and sometimes also on a social level. Friendships come easy. However, when problems set in, then it is every man for him and herself.

Then you find out that the casual conversation prior to project status meetings and the chit-chat at the water cooler is suddenly considered formal feedback and factual formal reporting. The conversation in the car park, where you agreed on a design modification is then suddenly completely forgotten and labeled as figments of your imagination. 

Suddenly, you can find yourself in a very lonely place without your “friends” when the project is in trouble. 

Be careful to rely on “friendships” during projects. Keep your relationships professional. Use friendly follow-ups to confirm outcomes of conversations, and leave work at the office when you share in social events and interactions.

Supposed “friendships” also have a nasty habit of being used to circumvent or avoid accountability. Friends look after friends, don’t they? Be cautious that you are not clouded by friendship when you have to hold project resources accountable for their delivery and the quality of their products. Friendships under these circumstances can prove to be very costly. 

The advice I give here is again to keep matters professional, communications open, and accountabilities clear. 

Perspectives

Everyone has a story. 

I am constantly amazed at how intricate perspectives can be on a project. As Program Manager I am often challenged to navigate through a series of perspectives to not only separate fact from fiction, but also remove clutter from that which is important. Sometimes it appears easier to hoard cats, or get butterflies to fly in formation, than to keep track of every stakeholder's perspective and agendas. I call these their stories.

The more challenging the project becomes, so it becomes harder to keep up with everyone's story. As manager, one of the roles you have to fulfill on the project is to coordinate and facilitate collaboration between participants. You need skills to be sensitive to, and foster good understanding of the other's point of view, and be able to facilitate reciprocal understanding amongst stakeholders. Diplomacy is an important trait that will help you navigate this minefield of helping people communicate with each other effectively.

Unless you have a good sense of humor and a nose for the truth, it becomes hair raising to work through the various, and often conflicting agendas, and perspectives of project resources, customers, and vendors. 

My advise is to get all the “liars” in the same room. One can only tolerate perspectives to a point. Help each participant to develop a sensitivity for the other's point of view. It is much more constructive to align a team’s perspectives and work out a common understanding, than to walk a tightrope amongst stakeholders of trying to keep everyone happy, and be caught in the middle translating perspectives between parties.

Be sensitive to who’s story is more important. There is an old saying that says: “The customer is always right.” 

Make it your business to have a clear understanding of the customer’s perspective. Know what drives the agenda, and what are his or her motivators. I have often worked with a client sponsor who has his eye on a promotion, or who is aiming to settle a long standing feud or score with another manager. The project’s success or its failure may play an important role, and you are instrumental in either outcome. Don’t assume that a success is necessarily a good thing in this context.

Lastly, take note of larger organizational contexts when you decipher perspectives and balance agendas on your project or program. A well known challenge is balancing the objectives of a vendor with that of the client. For example: The vendor seeks to maximize billing of its resources, while the client is looking for increased cost savings. 

If you are the Project Manager caught in the middle of this conflict, then some may think it is as simple as remaining true to your professional principles and integrity for the solution. However, this is where I’ve learned that there is more than one perspective (and integrity) to consider.

Best is to provide management to the engagement that is as transparent as possible to both parties, and ensure that both stakeholder objectives are represented and balanced. It may mean that some quality is compromised to meet the client’s cost objectives, and on the other hand resources may still be effectively utilized through additional value. 

It is important that the stakeholders work this one out amongst themselves (with your facilitation off course), and you as Project Manager not be seen as compromising your professional integrity to favor either one party.  

Remember that the project's problem's are not necessarily your problems. As manager, your main purpose is to: Ensure an appropriate delivery framework (processes, resources, etc.), to manage the exceptions where this framework fails, and to facilitate effective coordination between parties within the framework and those interfacing with the framework. The rest us up to the stakeholders to work out.

Follow the Money

When the day of reckoning arrives, then you have to be sure that you've been answering to the right authority for the engagement. Especially, in matrix organizations it can become very confusing who the person is, to whom you are really responsible for the project.

Yes, I know that the Project Sponsor is the ultimate customer for your project management services. However, this sponsorship can be ambiguous, or shared amongst members of a committee. Some of these members invariable will be more engaged with the project than others, and may have conflicting ideals. However, when you really, really want to know who the Sponsor for your project is, you have to follow the money.

If you need to get a conflict resolved, or a matter settled that is risking your project, and you've run out of options (including consulting the Sponsorship or Steering Committees), then you have to visit the man or woman with the money. Ultimately, the person writing the cheque for the project (not your salary or contracting fee) has the final say.

Be sure that you identify this person early on in the process, and make him or her your best friend from the start. Do this regardless of them delegating authority to a committee of sort. Keep him informed, and ensure that the project (and Committee decisions) are aligned with the ideals of this person. It can become a very lonely place for a Project Manager when a steering committee is dissolved, and you find out for the first time who the real authority is behind the work you and your team are doing. Don't be caught offside by not knowing your true Sponsor and their objectives with your project.

Escalation

Escalation is not a defense.

Don't ever think that you can defend yourself, your actions, or lack of action from your project by calling upon the fact that you've escalated a matter to management, and they've done nothing about it.

Have a look at your project's risk register. If the word escalate appears against a risk or issue, then what it really tells you, is that you still have the problem. The only difference is that you are now running out of time to solve it, while you have a false sense of security that someone else feels the obligation to save you from having to deal with it. You are running out of time while fooling yourself.

Remember that escalated parties may not have the same sense of accountability or urgency for your project's deliverables. They may not share your obligation. That is why you should not trust that an escalation will resolve anything. At best, an escalation is a communication strategy, not a delivery approach.

Escalation rarely resolves anything, and mostly make matters worse. Here is an example:

Let us say that two design engineers cannot agree on a technical matter. To resolve the matter, you escalate the disagreement to the Head of Engineering in your company.

For the first couple of weeks you hear nothing from him. It is only when your status report turns red on progress that you finally get a response. His response is that he assigns another engineer to investigate the problem and to make a recommendation.

By now you are really behind schedule and you have another new engineer injected into the project. To make matters worse, this new member will have to take time (and it costs money) to come up to speed with the initial issue, and your project's environment.

Your initial two disagreeing engineers, both feeling they are absolved from the responsibility for making a decision, is now eagerly watching the new entrant making his recommendation. Your escalation gives them the opportunity to sit back and watch, plus it allows them a further chance to disagree and distance themselves from the outcome.

The new entrant may have something to prove, and comes up with a completely different design proposal. However, there is nothing giving him the obligation to see it through to implementation.

Remember, he is only here to make a recommendation, thanks to your escalation.

Now you have a late project, over budget, with two design proposals, three disagreeing engineers and no one taking responsibility for the outcome. You also have an out of control rumor spread by the Head of Engineering, that your project is in trouble!

It will be much easier instead of escalating a matter, to rather facilitate an outcome between the existing two engineers, even if it is an ugly fight. If nothing else helps, lock them in a room with enough food and water until they emerge with an agreed outcome. This way, you ensure that the accountability and responsibility for the work remains in tact, and you limit destabilizing outside influences on your project. There is nothing that says they cannot consult outside parties during this process.

In this way the integrity of your management framework is saved, and you can rely on your team to deliver the outcome because they remain accountable. Escalations rarely resolves anything.

Conclusion

The best advice for any project manager is to avoid the day of reckoning altogether.

You can do this by seeing the big picture. Understand how your project fits into an organization's strategy, structures and culture. Know the role players outside your project. If you can anticipate an eventuality, then you should be in a much better position to navigate around or through it.

Additionally, follow the above C.Y.A. advise:

• Keeping your admin up to date.
• Foster strong professional relationships with the people that counts.
• Know who is writing the cheque and ensure he is on your side.
• Avoid escalations. Deal with the issues.

Remember, as Project Manager you set the framework (processes, resources, budget, etc.). You have to manage the exceptions where your framework fails. Lastly, you facilitate coordination between your framework and its parts and interfaces. Cover your ass.

Don't hesitate to be in touch with any further suggestions for Project Managers to avoid trouble. Your comments are welcome.

Hendrik van Wyk