Part 4 of 5 - My team included; Leonardo Da Vinci, Sir Winston Churchill and George Eastman Kodak.

Metaphysical properties of project management are perhaps the least understood, rarely practised or even discussed in any of the project management literature or educational establishments found today. Yet the metaphysical properties that naturally belong to project management are the long forgotten fundamental cornerstones for putting the word “success” back into project delivery. These are the very same metaphysical properties frequently used by the likes of Leonardo Da Vinci, The Wright Brothers, George Eastman Kodak, Winston Churchill – and many others whose successful projects we all still benefit from to this day.

-------------

Before taking on any project I like to know all areas (including potential dependencies). Depending on how much time I have before coming in front of the client, I can spend up to 16 hours a day investigating a project brief. I find that 4 hours sleep is sufficient for me when working a challenging project. I meet daily with the Account Manager (on this GSM Portal project, Lisa) and we brainstorm potential issues. I normally forage through everything from equipment receipts, contracts, to client affiliations. Then I draw up a list of all the required tools I need on the project. I do not get everyting but I make the consequences of non-receipt very clear. I select a series of techniques to be applied based on my initial investigations of the project brief. Mel, my London office secretary, efficient as always, arranges taxi, flights, and hotel. Finally I select my invisible team; in this case George, Winston and Master Da Vinci. Now I am ready :-)
---
My driver took me back to the Sheraton, rather than directly to the office. For a while I looked at my brain map in the makeshift strategic bunker section of my suite - changed my clothes and took a slow walk into the city. As expected, I get no further than two steps from the hotel entrance before my work mobile rings. It was Lisa in London. The Client had suspended the project. She wanted to know more details of the meeting, but thought better than to insist on it. She, more than the others, knew my focus on this project – she said she would wait for me to get back to her. Before arriving in Zagreb, this scenario was not anticipated because the project was marked as a non-starter until our (me and Lisa) presentation which injected life back into it. To my thinking this suspension was a benefit to the project. The real question now was to determine which solution and restart techniques to use, plus what penalties would I need to place on the client to ensure that the project continued uninterrupted?

Sir Winston Churchill gave me the foresight to create the strategic bunker in my club-suite. Here, my investigations in London were laid out ontologically. All potential risks to the project were listed - all risks had owners of responsibility with a chart detailing likelihood of probability to occur. In the bunker I could brain map solutions to these risks, calculate impact and decide what leverage should be applied in this suspension situation. When I went through all the project receipts and contracts, never once did I see a service level agreement (SLA). The client was spending vast amounts of money on equipment, yet failed or overlooked the need to secure the appropriate SLAs (especially for the technical set-up from IBM). Sir Winston was also a master tactician, and I needed to get directly to the person/s on the Client side that had authorised and acquired this equipment – which I managed successfully. Their role would be to bring the Client back around the table – which they did (although not everyone turned up for that meeting, but it did forcibly remove the project from suspension).

George Eastman Kodak has been on all my projects. Here was a genius manager, and organiser – loyal, trusted and with a work ethic that still remains in scarcity today. George’s strong humanity helped me to work with the Croatian, Indian and London teams – then later helped me take control of IBM, Siemens, Motorola and other 3rd parties (orchestrating their deliverables to slot in place and at the right times). Prior to the project resuming I needed to get my own house in order. The only damaging accusation left to deal with was the PTK training one. The team found evidence which supported their attendance. Afterwards, I needed to strengthen the system integration weakness. I discovered more evidence of the Client’s financial wastage when I persuaded them to allow me to visit their production site. Adopting George’s insights, I moved for an additional contract to be signed bringing the entire project under the control of my organisation (but to complete that, I needed the help of Master Da Vinci).

Leonardo Da Vinci brings to the project a fresh, unique and inquisitive nature. All the scenarios created for the projects are generated with him in mind. Observation, extrapolation and documentation are direct contributions. In London we realised that the key to the project was the content management system (CMS), but I could not play this card until the project suspension had come into play. Several 3rd party suppliers (including IBM) tendered for the CMS contract. Da Vinci questioned how each could supply a bespoke CMS solution – allowing for a game plan to be created to win the tender. For example, we deduced that IBM could not create a content management system – given that it had made no attempt to create one in the first year of the project starting (well before I arrived on the project). While we had not anticipated the project suspension, we did consider that the project could fall under IBM control. Our priority, if this happened, was to fight vigorously for CMS design and development.

The project meeting for lifting the suspension lacked the attendance of the accusers from the Tuesday weekly taskforce meeting. The Client with evidence which countered their previous accusations sent a written apology to my London office. The penalty I implemented was for 100% control of the project to safeguard against any further interruption – leveraged by financial wastage evidence. My request kick-started the CMS and systems integration tender. I was prepared by my teams and won the tender after three hour interview sessions beating all the other 3rd party suppliers. Without my visible and invisible teams we could not have hoped for better. There is no doubt that these great heroes used planning, scheduling, and monitoring to achieve their goals. Yet, they used something else as well, something which would keep their goals alive for centuries after they had departed this existence … ingenuity.

---

****

How you deal with uncertainty determines the outcome of the project. By default it is in our job description to deal with uncertainty in projects everyday. Uncertainty management is not something you learn from books. You learn this through continued experience, such as on this GSM Portal project. True, you can learn to anticipate risks (for example) via books, but there is more to projects than risk. You need to know everything about the project and what project assets are, plus how and when they should be brought into play. The impact of this experience is that you learn to manage various outcomes, and last minute surprises. For example, part of uncertainty management involves rigorous preparation techniques. The long hours devoted before the project restart were rewarded by being able to model solutions based on the discovery of holes that were leaking time, haemorrhaging money and bucking the project schedule.

****

Oh and by the way, if you are ever on a big project like this one, never ever take a normal hotel room – take a club suite or bigger :-)

-\/-

Part 3 of 5 - The Lions Pit

Managing uncertainty on critically important projects is akin to that of being thrown into the proverbial Lions pit. You never know if the lions will eat you or if God will come to your rescue. It still happens to this day and it is shocking, surprising, and very painful! Like my biblical namesake, Daniel, who believed he had the trust of King Nebuchadnezzar (whose dream he had successfully interpreted - with God’s help); I too believed I had gained the Client’s trust when I jump-started the GSM Portal project where all others had failed. It would be weeks later where I would come to realise how fragile trust can be – especially when manipulated.

--------

Uncertainty management, considered to be a black art in project management, is the preparation and management of unanticipated occurrences in projects (it should not be confused with Risk Management, risks can be anticipated). Experienced Project Managers employ scenario creating techniques based upon situations they have previously encountered. They create hypothesis, and extrapolate all data on all that can happen and often does happen. Theatre directors do this all the time when they need to “work something up” using strata to build complexity – that is what my friend Sir Trevor says. By analysing (breaking down components, assessing threat and opportunity levels, project managers can build various contingency strata into uncertainty scenarios) we model all complexities (the common source for uncertainty), then store them in the project bible.

You may think this geeky or bit of an overkill, but consider for a moment that you do not know as much about the project as you believe. Consider that your not knowing could lead to project failure or delivery of a poor system - even though it is on time and within budget. Then consider your responsibility to prevent those common occurrences.

-----
Every Tuesday afternoon the GSM Portal project includes a weekly taskforce meeting. I attend regularly, representing my organisation. I have always believed that the more prepared you are, then the better you can deliver. From my hotel club-suite at the Sheraton Zagreb (which by the way I had turned part of it into my very own strategic bunker) I thought I would be prepared for any and every eventuality. I was, but you know, the best laid plans and all that. Something can always go wrong … and it did.

Arriving at the taskforce meeting I normally hold a quick catch-up chit-chat with the IT Director on the Client side. This time our normal verbal exchange is side tracked to technical issues. The Director is concerned about the setup progress of the development environment and (news to me) setup of the staging environment. He appeared edgy, and well, pungent with negativity. Something was not quite right. In the large cavernous conference room, situated around a very large oaken oval table, there are some unusually empty chairs. The Marketing Manager arrives, closely followed by the Head of Marketing. There is some shuffling as two or three other members of the weekly taskforce take their places. We skip on actions from the last minutes of the meeting, as Marketing requested. Something was definitely very very wrong.

The Marketing Manager pounces first, throwing at me a set of sharp tipped questions. They are questions that I do not know the answer to because they are set in the distant past before I arrived on the project. Never-the-less, the client continues to “string me up” and I find myself on a rope dangling head downwards into the Lion’s pit. By the time the Marketing Manager has finished all accusations, joined by the Head of Marketing, my organisation is held to blame for everything that has gone wrong with the client’s project, since day one! The client demands compensation in the form of additional features – not in the project scope. They have hard copy evidence of my organisation’s short-comings and they bring out the Lions to feast.

The meeting goes on longer than normal. IBM’s Technical Director delivers several scathing attacks, rolling off evidence with dates. Without relent he explains that they had paid for my team to attend the TISM PTK training (for example) and that the team had not attended. This meant that my organisation was now responsible for the delays to the project – because the staging environment had not been setup, and therefore this would impact delivery of the production environment. The Client IT Director sealed my fate as he began cutting through the rope. “… No staging environment, then you have developed nothing - at least nothing we can see”.

With no real answers to the stinging accusations, I remembered that, “against overwhelming odds retreat, but leave a warning sign”. I knew well, as did the Client that the staging environment was not the responsibility of my organisation. They wanted one of the teams to carry out systems integration for the entire project – at reduced cost. Very calmly, I reiterated from my notes the accusations levied against my organisation. I fully agreed with the client that I had no real answer to their questions – and I steered clear from giving any unsupportable answers. Yet, I did leave them with something to think about, “I trust that I will not find all you have said, to be not what it appears.” I smiled and thanked them as I normally do for the meeting and departed.
---

What do you think happened next? What would you have done in this situation? How do you think you could deliver the largest and most recognised project in Eastern Europe after that?

-\/-

Part 2 of 5 - Trust

Even inside organisations, trust is a significant and increasingly pervasive issue. I experience this both in the UK and worldwide. Before arriving on this GSM Portal Project, I spent a great deal of time scenario planning for all the eventualities that could and did arise. Both I and the Zagreb Director simultaneously, without contact, sketched one of those scenarios; that if the project were restarted then Croatia would need to work with India. This meant that I would be managing and working with a small Indian team in Zagreb, the Zagreb team, and the remaining Indian team back in India. What I did not realise straight away was that while the teams trusted me; they had some difficulty in trusting each other.

-------------------

Croatia led the GSM Portal development, not only because they held a significant skills advantage, but because they were closest to the client. India took the backup role, assisting development and providing quality assurance. It soon became clear to me that the project was being deliberately sabotaged because establishing trust was being hindered by; the jostle for project control, poor communication and lack of respect for working culture differences – between the two teams and London. Onsite in Zagreb for example, there were management issues with London. Although goals of the project were agreed by all (including the client), these issues were strongly grinding down the project (which later, indirectly, led to the client suspending the project).

Often issues of trust, emanating within projects, can be brought on (or be contributed) by external factors. For example; disparities on technical view points, hostility towards new ideas, lack of management support, low project team esteem and the implementation of processes lacking consultation. The impact for each is illustrated by a project slow down or non-compliance. Without trust there is no real way for a Project Manager (PM) to get stakeholders to have the same view of the project. A good PM must question; how do I go about getting trust? Who do I need to enrol to help me? As an International Project Manager what do I do to demonstrate I can be trusted?

Before arriving in Croatia, I was 70% through development of my project bible wherein, I had already identified several trust issues and created scenarios for as many as I could (completing the solutions to each onsite). For example; with the help of the core Zagreb team, we managed to quell the trust management issues between London and Zagreb - when I beat IBM to win development of the GSM Portal’s content management system. The continued impact of the win, did not dawn on me until the Chairman arrived in Zagreb to meet with me. By that time I was already working on the next scenario, building integrity. The Chairman’s visit helped to boost the trust management steps that had solidified in Croatia and begun take up in India.

Bridging the gap to engender trust between different cultures within projects requires experience, obtained effectively in the field. This is because solutions to trust require direct contact. Otherwise what normally happens (and it did at the beginning of this GSM Portal Project) decisions you make locally (that you expect to be followed by the remote teams) can and often are superseded.

Today, many organisations fail to engender trust on their projects, believing this can be obtained via video / phone / web conferencing. Very few organisations have come to realise that trust speeds up project delivery, thereby saving time and costs. The continued impact of developed and managed trust leads to better client retention … yet International Project Managers still face a hard time justifying travelling costs.

---

As part of this set of metaphysical project management blogs, I felt it very important to place the trust issue here. This is because there is no doubt that it is always in the top group causes for project delay or failure. This is especially evident when working with different cultures, a different set of communication protocols, and a time difference which can prove beneficial or disastrous to organisations.

Trust building skills are a prerequisite tool for all International Project Managers. It is true that trust building is a soft skill in project management, but failure to implement and manage this successfully will lead to your project experiencing delays or even non-delivery. This is one skill you do not want to overlook.

-\/-