The Delivery

Done!

Finished! Done! Shipment is at customer! We did it!

That is what we want to be, feel and experience. The sensation can be a fantastic elation. The receiver has got what he asked for, based on updated re-aligned expectations and fine tuning. You close down the project folder one last time and realize: This is it! You call your team members one last time to share a short moment of gratitude together and you are ready for the next challenge. This book is written to help you experience delivery more often and more consistently.

However, quite often projects do not finish like this. They go on and on and deliver less and less value and slowly peter out and die. People are pulled away to other activities. Team members change jobs. Other activities get higher priority. You are alone, bearing the headache of a zoombie project. That is a nightmare for you as a project leader, since it can haunt you for years.

Therefore your first duty as a project leader is to actually finish projects. Deliver and close. If there are new needs coming up it is often better to close the old one and start a new project. This is harder than it sounds, since there are many forces that work against you.

There will be people who want to include more and more in your project. There are political fights that change priorities. Resources are scarce, and other projects can be more successful in getting funding. Your boss asks you to do other things “in parallel”…

The Project that Never Ended

A common infliction of large organizations are project-zoombies. Those creatures loom at the bottom of the priority list but exude a deadly breath of bad conscience and low level stress. These projects were started with enthousiasm and energy at some point in the past. Often with the best intentions. However, today they are a block on your feet and lure away energy and gumption.

One interesting never-ending-project I was part of started with a quite specific customer problem of noise in a special kind of electric motor. During the years, various solutions were attempted, sometimes driven by a technical insight, sometimes just to show that we were doing something. The intention was then “to keep the customer happy”, even if we were pretty sure that it would not solve the issue.

One important ingredient in this specific project was that the project team was distributed across four locations in Europe and Asia, with project members belonging to different departments in a multinational corporation. Nobody had this activity as his/her highest priority. A face-to-face meeting with the project team would lead to a frenzy of emails and actions, but in the coming months, the activities would get lower and lower priority and slowly cease. This slack period would be ended by a long and angry mail from the project leader, which would create some bad feelings and some half-hearted actions. We all started to dread the mails and secretly stopped reading after the first page.

One key feature of the project was that it was open-ended. We did not really know what “Finished” looked like. What was included? What was excluded? There was also no explicit budget for the project. The project manager had got some higher management to state that is was of “strategic importance”, so nobody was following up costs and time. In a certain sense, this project was parasiting all other planned activities. In a well-disciplined organization, this would not happen - but in most organizations it does.

Was it a complete waste of time and money? I do not think so. We learned many things and solved lots of minor issues for the customer. However the right question is: Do I think it was a good use of the time and money? To this, the answer is clearly no. We lost a lot of energy and time due to miscommunication and anger and frustration. Being part of a team like this for a few years eats into your soul and ensures a latent low stress level.

Only when everybody knows clearly what “Finished” looks like, focus can be maintained and the project can be closed.

Delivery Package

The delivery is something you live with for months and in your head it is crystal clear what is included. However, for your receiver and other stakeholders who are only partially involved it is often less clear. Therefore you have a didactic task at delivery to explain to the stakeholders what they get and that it meets the agreed specifications.

Therefore it is useful to make a whole package of the delivery:

  • The project product - the final deliverable
  • Closure presentation - explanation that you deliver what you agreed
  • Decision meeting material - to facilitate the hand-over/closure meeting

A face-to-face closure meeting is really good use of everyone’s time. Give a short presentation that explains what you deliver. Hand over the final product. Shake hands.
If you can bring in some of your project team members and other stakeholders to this meeting, you can share the feeling of completeness and achievement to all of them. Even though they are not “needed” in the meeting, it can be rewarding for them to see the receiver officially expressing the value of their work.

There is a psychological mechanism connected to the sense of touch, that when you hold something physically, you are more prone to accept it. (This trick is often used in street-side shops and bazaars, where the salesman will give you something that you hold in your hands while trying to sell it to you.)

Thus, if you can, make your delivery package into a physical format, even if it is a digital delivery. A nice box with a USB-stick is more physical and definite than an email. It gives a stronger sense of closure and finality. It is often worth it to spend some money on the finishing quality of the materials. If you ship a document, you can make a print out on high-quality paper. If you send a DVD, get a nice label printed.

Customer perception of quality is not only the “measureable product quality”. Especially engineers focus so much on the content that they think that the product itself is strong enough to convince the receiver of the delivered quality. However, the packaging is really important for the total perception, and is something that the receiver experiences first-hand [^HsiehDeliveringHappiness].

Official Style as Quality Indicator

Four years hard work was coming to an end. The PhD research had led to two successful publications in top journals and one more was in the pipeline. An open-source introduction to the research field was published and used in a number of labs. We had built a new type of robot and established a laboratory.

From the content point of view, I was quite happy, but I did not know how to package it. One aspect was the physical appearance of the PhD Thesis book. At Delft University, the author has full freedom in designing the cover. Often a photo or an illustration would cover the front. Each book looks different. Everyone used paperback printing at the local printshop.

Except for my supervisor Richard. He chose to print his thesis with black linen hardcover. It feels completely different in the hand. The books looks like a standard reference in the field. It almost tells you immediately that it is a work of quality. Nobody would doubt that he was serious about the value of his contribution.

I took his lead and did something different as well. Since we were short on cash in those days, I had to find another solution, since the hardback printing was out of my reach. The solution was to create a cover design that mimicked the official university visual identity, with the right logotype and the right colors. It looks like a prototypical Delft University Publication, even though it was the only one. In that sense, it lends credibility from this institution and looks professional even before the reader starts looking inside. Not as good as the black linen hardback, but good enough this time.

How can you make your delivery package radiate quality and professionality, so that people are already half-convinced before they get to the content?

What’s in the delivery?

When you start up a new project, the first task is to define the scope and what is included/excluded, to define the delivery. There is often a fuzzy picture with a few words describing the general direction, but this is not enough. The more vague description of the project, the higher the risk for scope creep and added requirements during the run, which will make your job more difficult.

You make sure that the whole team knows what finished looks like and focus on this. Only when you have a clear scoping, you can consistently communicate which output you will create and what the end-effects are.

Get a clear agreement with your stakeholders on the scope. Often you need to modify the scope halfway through the project when you know more, but that is no excuse for having no agreement in the beginning.

Scoping is hard, since there are lot’s of unknowns at the start of a new project, and it is tempting to be vague. It is sometimes also tempting to over-promise, certainly when this is encouraged by the implicit organization culture.

Huge Scoping to get Funding

One implicit problem in some organizations is the decision making process for starting new projects. If the project leader promises a lot, that project can get funded and start up early. Therefore, there is a sub-conscious force that stimulates over-promising with a large scope and huge returns, just to get started. Those who are realistic sometimes don’t even get to start.

At a research department where I worked, Sven, one of the senior team members consistently over-promised at the start-up of projects. This ensured that his pet projects always were well funded. He also had the surprising skill to discover a new, unexpected technical problem in the middle of each project, which made it impossible to deliver the original plan. Most of the stakeholders were impressed with his way of communicating this semi-disaster, and how he nevertheless could deliver some value at the end of the project.

This strategy was successful for over more than a decade, and I think one of the key elements was the volatility of management. During ten years, the department had five managers, so no boss was around long enough to call the bluff. On the other hand, many colleagues were there, seeing Sven perform the game time and time again…

At other places I have worked, people have been demoted or fired if they consistently under-deliver.

Is over-promising rewarded in your organization?

What is your strategy to make it look like you under-promise and over-deliver?

A useful method to come to a detailed scoping is to sit down with the customer or the receiver of the project and make a prioritized list of the requirements. What is the most important item, then second most, etc. By forcing your receiver to explicitly rank the features he needs, you can spend your efforts where the value is the greatest. It is difficult and uncomfortable to “get out of the building”[^BlankEpiphany], but that will save you lots of energy later.

There are situations where project objectives are not clear. Then the results are destined to be disappointing. Your job is to ensure that you know what finished looks like - or refuse to start. I should have done that…

250,000 Dollars Project Delivering Nothing

As a project leader in the beginning of my career I got to run a project to develop a sensor system for a kind of large machine components. As often is the case in R\&D organizations, there was a committee that granted research funding, and someone in the committee had allocated resources for this project. Unfortunately, the same person changed jobs just before the calendar year started and the activity should begin.

I did not know what to do. Money was there, 250,000 USD and the timescale was given. 12 months. The only thing missing was the objective.

In the beginning of the year, I was busy with other things, so I sent a mail once in a while to the new committee member, asking for his opinion and suggestions. No useful response. “I will get back to you later.”, he said.

Coming into May, I started to get nervous. Would I fail miserably in my first job at this site? I tried to set up some meetings with stakeholders to flesh out the scope of the project. I talked to my department manager who said he would look into the issue.

Many ideas on the table, but nobody wanted to make a decision. I got the recommendation to talk to some other people in another organization. I talked to those as well, but no consensus was found. It went on like this until September, when the department I worked in started to run out of money in the other projects. People started to book hours and expenses on my project and I was desperate. We had spent nine months and 60,000 USD, and there was not even a plan. It did not get better, the problems just accelerated towards the end of the year and by Christmas all the money was consumed. A quarter of a million dollars gone.

I had achieved nothing.

Not even a report. Not even a project plan. Of course, the money and extra time had helped the other projects to be more successful, but I had nightmares.

The strange and disturbing thing was that it seemed like nobody noticed. Nobody came to me to ask what we had done. Still today, many years later, nobody has ever asked me what we did for all that money. Not even once.

There are many things to learn from this story, among others how poor decision making processes there are in multinational corporations. But more fundamentally, it shows that accountability was missing on many levels and how I failed to use my management to escalate the problem. I was hiding behind our team-leader who was communicating with management. He had no interest in signalling any problems, so nobody noticed the lack of output.

This incident also highlights that it is very easy to measure input to a project, but hard to measure output. It was visible to management what went into the project; manhours booked, external expenses were accounted for at the accuracy of 1 dollar. The steady progress in spending masked the complete absence of output.

Exercise: Input or Output.

Do you measure mainly input or output in your organization? What is communicated upwards in the hierarchy? What is the maximum spending that would fly “under the radar” and not be detected in your workplace?

(Please note, this is not about fraud or stealing or anything like that. Only about how much money can you spend on something that is utterly useless and nobody notices?)

What can you do to shift focus towards output?

Celebrate

Bring in the cake. Take the team out for a nice dinner. Bring in some senior executive to get exposure for your team members. Let the world know. Enjoy the attention and spread it to the key players around you who have contributed to your success.

The main reasons for celebration are to create positive memories, to reduce stress, to have a moment to savour the success and feel proud of the achievement, to refill the energy depots. This is important for the sustainability of the team. The most prevalent work-related disease is clinical depression in various forms [^CDCDepression]. In a modern work environment, the risk is high to get caught up in negative patterns and celebration is a way to unwind.

As a project leader you can create moments of de-tensioning. Once in a while, when there has been a part-delivery, spend some time together. Enjoy. Laugh together and be grateful for each other’s company and contribution.

This also helps to de-fuse conflicts inside the team and helps us to see each other as humans. Colleagues are not the same as friends, but since we spend so much time together, it helps to get to know each other on a human level. We will get back to celebration in the next Chapter about the Team.

False Progress

We all want projects to be successful. We want to pass the gates of the project to feel that we are moving in the right direction. As a project leader, you have vested some of your ego into the project and you want to feel successful. Sometimes a salary bonus is connected to the progress of the project… Your stakeholders wants the project to move forward.

These are powerful forces that nudge you to fudge. The pressure builds up on you to be a little bit more positive than reality requires.

You come to a gate in the project, which you know that you actually don’t meet the requirements for and still you convince each other to “conditionally pass the gate” and continue the project.

The momentary positive feeling of approval and progress quickly melts away when you look at yourself in the mirror. You know that there are problems lurking beneath the surface. This dishonest pressure to pass the gates creates an illusion of progress that only delays delivery and invites disaster.

The false progress works against your own goals, so it is important to identify when it is coming. Whenever you get comments like: “It would be a pity to re-schedule the gate meeting.” or “It is almost there, and we should move on.” you know what it means.

Take the chance to review the scope with your sponsor and consider if the project should be aborted instead of pushed along. Maybe this project is not what your organization really needs right now…

What’s left - Sustainable Value

Every system you build, every process you establish, every insight you share can continue to create value long after you are gone [^HolmgrenPermaculture]. Therefore, you are often at the intersection between the temporary organization of the project which will dissolve after the final delivery and the line organization which will own the output.

Documentation is one thing that is often handed over to the line. How good should the documentation be? There is a hidden conflict of interests at play where the project manager is encouraged to close quickly with as little cost as possible, but the line organization wants a solid documentation package.

In the heat of moment, the interests of the project can dominate, but as soon as the project is finished and the organization dissolved, nobody will really care about the project. The interests of the line organization are still there. They are the ones who live with your output. They will have a lot of time to form an opinion about the quality of your work.

You can choose how you build your reputation - as a quick scorer or as a solid builder.

Experience Box - Chris Ancona - “Top Three Tips”

Key Project Manager Indicators are to be “On Cost, On Quality, On Time”, and these 3 points are how success and failure are measured.

What these 3 metrics do not consider the potential problems that arise, where those problems will come from, and what to do about the problems when they unavoidably arise. When I was a young project manager, I made the assumption that project failure would come from two places; lack of technical skills by myself or the team or lack of team motivation.

Most of my initial project management considerations focused on managing these two potential problems. I spent time and energy making sure the right people were on the team by asking around and verifying previous project performance of team members. I would make sure I understood my own technical weaknesses and be sure to have a team member who was strong in that area to compensate. Then, I spent considerable time to understand each team member’s motivation and goals so I could keep them in mind through the project and do my best to assure those goals were met as a way to assure continued motivation.

Surprisingly, though these two areas were very important, most of the problems did not come from technical or motivational issues. The areas where problems arose were the inevitable blind spots. Sometimes it was loss of a sponsor, or a person who wanted to block the project but hid that fact until a key moment. Other times, there was jealousy or resource fights from competing project teams. And still other times, top management makes poor strategic decisions or changes directions mid-project and expects the project team to make up for the mistake.

With this backdrop, the top three things I believe make international projects successful are:

  1. Know your Team and make sure they know each other both personally and professionally, what are their capabilities, their goals and aspirations, their strengths and weaknesses, and even their worries and fears. With international teams working in different countries and locations, getting to know one another can be more of a challenge because the “coffee break” opportunities for social time are not readily available. Many project managers like to schedule a period for team members to introduce themselves which usually includes sharing their background and some personal story, and then this never comes up during the project again. For some teams, this is acceptable because the team belief structure around professional delivery of project deliverables, but most international teams require more social time to bring them to a higher level of performance. The stronger relationships, the more the team members look out for one another and the project.
  2. Know the stakeholders and potential blockers in each country. This sounds obvious, but it is not so easy in practice and the local team members may not be fully aware of the politics. For a new project manager, this activity can be challenging and will require continuous exploration throughout the project by paying keen attention to the evolving reactions of project movements and asking good questions to understand the underlying reasons behind these reactions. As a project manager gets more seasoned in a country, and gets to know the management and the political landscape, the job of understanding who is friend and potential foe and how to leverage the friends and counteract the potential foes will become clearer.
  3. Build the team culture around openness and flexibility in solving problems. At its base, innovation is simply about finding different ways to look at a problem and creative rearrangement of the available information of the team to direct towards a resolution of the problem.”

Chris Ancona has run international projects all over North America and Europe as well as in China, India and Korea. He has experience both from a multinational technology company, multiple startups and academia.

Chris is currently teaching at the MBA programme CIMBA in Italy.

Follow his blog at:

[https://www.linkedin.com/pub/christopher-ancona]