Fritzerland

Sharing my excursion through life

Was Projektleiter von Piloten lernen können

By

Was haben ein Flug und ein Projekt gemeinsam? Eine ganze Menge! Etwa 50 Jahre nach Beginn des Projektmanagements scheitern immer noch mehr als 50% der IT-Projekte daran, dass ihnen Zeit, Ressourcen, Mittel usw. ausgehen. Wenn Piloten Flugzeuge fliegen würden, wie wir Projekte durchführen, würde niemand jemals fliegen. Jeden Tag fliegen jedoch Millionen von Menschen wegen ihrer Arbeit oder zum Vergnügen, und Flüge kommen fast 90 Prozent der Zeit pünktlich an. Verzögerungen entstehen hauptsächlich durch das Wetter. Flugreisen sind mit einer tödlichen Unfallrate von 0,022 pro 100.000 geflogenen Stunden die sicherste Form des Fernverkehrs. Wir fliegen seit etwas mehr als 100 Jahren, Projektmanagement gibt es jedoch seit dem Bau der Pyramiden und der Großen Mauer. Gibt es irgendwelche Erkenntnisse, die wir aus dem Fliegen ziehen können? Ich denke ja.

Die Luftfahrt hat mich immer fasziniert. Als Vielflieger und zudem selbst privater Pilot bin fast jede Woche in einem Flugzeug und es gibt keinen Start und keine Landung, die mich langweilt. Wenn die Räder abheben und die Kontrolle verschwindet, ist da jedes Mal eine leichte Panik. Ich bin immer dankbar für die Tage, an denen die einzige wichtige Aufgabe darin besteht, das Flugzeug sicher zu fliegen oder die größte Entscheidung ist, ob ich das Huhn oder das Steak nehme. Diese Tage treten – wie in einem echten Projekt – selten auf. Als Pilot und Projektmanager glaube ich, dass Lehren von tausenden Flugstunden und das Wissen guter Piloten auch auf das Projektmanagement angewendet werden können. Wenn wir aus jahrelangen Leitprojekten etwas gelernt haben, ist es die Erkenntnis, dass gute Führung eine wesentliche Fähigkeit ist, um ein guter Projektmanager zu sein. Unsere Führungsrolle bedeutet, dass wir Teams führen und leiten. Die Vision setzen, das Team motivieren, ihnen dienen, sie coachen und andere inspirieren. Als Projektmanager führen wir sowohl aus strategischer, als auch aus operativer Sicht – wir kommunizieren die Vision und erhalten ein Team- (und Organisations-) Buy-In, wir lösen Konflikte, setzen Ziele und bewerten die Leistung. Und wir stellen sicher, dass die Teammitglieder über die Tools, das Geld, Raum usw., welchen sie für ihre Arbeit brauchen, verfügen.

Kommunizieren

Eine der wesentlichen Fähigkeiten für das Projektmanagement ist die Fähigkeit, gut zu kommunizieren und zu verstehen. Gute Kommunikation ist der Kern jeder Beziehung. Daher wirkt sich die Effektivität der Kommunikation eines Projektmanagers nicht nur auf das Projektteam, sondern auch auf den Kunden und die Stakeholder aus. Noch nie sagte ein Kunde “Ich wünschte, mein Projektmanager würde aufhören, mir so viele Produktaktualisierungen zu geben.”. Je mehr Berührungspunkte Sie mit Ihrem Kunden haben, desto solider wird die Beziehung und desto wahrscheinlicher wird das Projekt ein Erfolg. Durch eine gute Kommunikation werden Sie kontinuierlich neu ausgerichtet. Wenn Sie dies häufig genug tun, stellen Sie sicher, dass Projekt immer den gewünschten Stand hat, und somit dessen Erfolg. Ein Prinzip eines sicheren Fluges ist es, das Flugzeug in jedem Fall weiter zu steuern, also zu fliegen, auch wenn unerwartete Dinge auftreten. Deshalb lernen alle Piloten, Notfälle in der folgenden Reihenfolge anzugehen:

  1. Aviate – fliege das Flugzeug.
  2. Navigate – wissen, wo Sie sind und wohin Sie gehen.
  3. Communicate – andere über Ihre Situation informieren.

Diese Ordnung hat viele Leben gerettet, da sie den Fokus auf die richtigen Dinge legt. Was nützt ein May-Day-Anruf (Kommunikation), wenn Sie das Flugzeug nicht unter Kontrolle haben (Aviate)? Diese Grundsätze können auch auf die Verwaltung von Projekten angewendet werden. Wenn eine Ausnahme auftritt (häufig ein Ereignis, welches wahrscheinlich dazu führt, dass Budget- und / oder Zeittoleranzen überschritten werden), besteht der Standardansatz darin, einen Ausnahmeplan und einen Bericht zu erstellen. Da störende Ereignisse mit teils grossem Einfluss auf Zeit und Budget, grosse Auswirkungen auf alle Beteiligten haben, verlangt das Management in der Regel sofort einen Bericht. Konzentrieren Sie Ihre Energie jedoch nicht sofort auf diesen Ausnahmebericht. Ihr Team braucht jetzt mehr denn je Ihre Anleitung – Sie müssen sicherstellen, dass die Teammitglieder an sinnvollen Aufgaben arbeiten, während Sie Ihren Ausnahmeplan erstellen. Mit anderen Worten: Führen Sie Ihr Projekt weiter! Erst wenn dies sichergestellt ist, sollten Sie mit der Erstellung des Ausnahmeplans beginnen, um die Ereignisse zu beheben. So kann der Aviate-, Navigations- und Kommunikationsansatz auf Ihre Projektausnahmen angewendet werden:

  1. Führen Sie das Projekt weiter – stellen Sie sicher, dass alle Teammitglieder an wichtigen Aufgaben arbeiten (Aviate).
  2. Erstellen Sie einen Ausnahmeplan, der Ihr Projekt aus den Schwierigkeiten bringt (Navigate).
  3. Informieren Sie die Stakeholder über mögliche Maßnahmen (Communicate).

Planen

Die Projektplanung ist eine Kernkompetenz des Projektmanagements, die jedoch überraschenderweise von vielen Managern nicht besonders beachtet wird. Aber was ist ein Projektmanager ohne Plan? Unsere Fähigkeit, Aufgaben in der richtigen Reihenfolge zu organisieren und zur richtigen Zeit das richtige Ergebnis zu erzielen, ist ein wesentlicher Bestandteil unserer Arbeit als Projektmanager, nicht wahr? Es ist absolut wichtig, dass wir als Projektmanager der Planung die ernsthafte Aufmerksamkeit widmen, die sie verdient, gleichzeitig den Fortschritt überwachen, während das Projekt voranschreitet und Optimierungen vornehmen, um sicherzustellen, dass alles auf dem richtigen Weg bleibt. Richtige Planung bedeutet alles von Meta bis Mikro. Es gibt die offensichtliche Planung in großem Maßstab, die wir brauchen, um großartige Besprechungspläne, Arbeitserklärungen, Schätzungen, Zeitpläne, Ressourcenpläne und Kurzberichte zu erstellen, und wie Sie sich Zeit nehmen, um Ihre Statusdokumente auf dem neuesten Stand zu halten. Bei der Planung geht es darum, Wege zu finden, um alles, was Sie brauchen, so effizient wie möglich zu erledigen.

Vor ein paar Wochen habe ich bei tiefen Wolken und geringer Sicht einen Flug nach Instrumenten gedreht. Ich bin perfekt darauf trainiert, in den Wolken und bei schlechtem Wetter zu fliegen, und das Flugzeug verfügt über großartige Instrumente, sodass das Wetter kein wirkliches Problem darstellt. Ich war bereit, bei zu geringer Sicht, mehrere Landeversuche unternehmen zu müssen. Ich plante es und überprüfte ein paar Mal in meinem Kopf, was ich tun musste: Wenn ich die Landebahn nicht sehe, gehe ich bei meinen Instrumenten auf „Pitch Up, maximale Startleistung, Landeklappen, positive Steiggeschwindigkeit hoch, Klappen hoch, Landung abgebrochen, Autopilot an, über Funk melden, dass der korrekte Landeanflug verpasst wurde”. Das ist eine Menge zu beachten, aber wenn man gut trainiert ist, wird es einfach. Üben Sie genug und wiederholen Sie es ein paar Mal in Gedanken, wenn es soweit ist, wird es ein Kinderspiel. Als ich die Landebahn sah, landete ich am geplanten Flughafen, bevor ich mein Minimum an Treibstoff erreichte.  Dennoch war ich auch bereit, den alternativen Flughafen erreichen zu müssen.

Führen

Projektmanager sind immer dann ein leichtes Ziel, wenn Projekte nicht nach Plan verlaufen. Unabhängig von den Umständen fragt sich jeder, ob der Projektmanager das Risiko hätte vorhersehen und verhindern können, bevor es zu einem Problem wurde. Projektsponsoren hassen Überraschungen und ein gutes Risikomanagement ist eine Möglichkeit, Überraschungen zu vermeiden, insbesondere die schlimmen. Risiken sind oft nicht akut, was bedeutet, dass viele Projektmanager Risiken nicht so ernst nehmen, wie sie sollten. Sie können den Überblick über Ihr Projekt behalten, indem Sie das Risiko kontrollieren und es so weit wie möglich aktiv abmildern. Wie schon erwähnt: wenn wir aus jahrelangen Leitprojekten etwas gelernt haben, ist eine gute Führung eine wesentliche Fähigkeit, um ein guter Projektmanager zu sein. Unsere Führungsrolle bedeutet, dass wir Teams führen und leiten. Die Vision setzen, das Team motivieren, ihnen dienen, sie coachen und andere inspirieren.

Gehen Sie nicht davon aus, dass Sie es immer am besten wissen: “Besserwisser” -Piloten können sich und ihre Passagiere umbringen. Stellen Sie sich einen Piloten vor, der mit der Flugsicherung argumentiert oder Wettervorhersagen ignoriert… oder sogar Hinweise ignoriert, dass das Flugzeug nicht optimal funktioniert. Leiter von Unternehmen machen die gleichen Fehler, wenn sie davon ausgehen, dass „ich bereits alles weiß, was es zu wissen gibt, und die Richtlinie mit meinem Wissen in Konflikt steht.“ Das Problem ist natürlich, dass niemand wirklich alles weiß. Es gibt immer mehr zu lernen und es gibt immer Menschen, die mehr wissen als wir. “ Wenn Ihnen jemand einen Rat gibt oder Sie auffordert, eine Regel zu befolgen, nehmen Sie sich zumindest die Zeit, um zu berücksichtigen, dass diese Person möglicherweise etwas weiß, das Sie nicht wissen.

Reagieren Sie nicht zu schnell auf Probleme. Wenn ein Flug schief geht, ist es selbstverständlich, dass Sie gezwungen sind, sofort etwas zu tun, um das zu ändern. Aber eine zu schnelle Reaktion kann mehr schaden als nützen. Nehmen wir zum Beispiel an, der Pilot hat festgestellt, dass sein Flugzeug an Höhe verliert. Eine impulsive Reaktion könnte darin bestehen, das Steuer zurückzuziehen. Das Problem dabei ist, dass das Hochziehen des Flugzeugs (ohne etwas anderes zu tun) die Flugzeuggeschwindigkeit verringert und tatsächlich eine Stall / Spin-Reaktion verursachen kann. Es gibt viele Situationen beim Fliegen und im Geschäft, in denen etwas schief geht und eine schnelle Reaktion erforderlich ist. Aber es sollte immer eine gut durchdachte Reaktion sein. Das Mittel gegen impulsives Verhalten ist die Erkenntnis, dass es Zeit gibt, nachzudenken und dann angemessen zu reagieren. Ein Pilot muss alle seine Instrumente (schnell) überprüfen, um die wahre Ursache zu ermitteln. Es kann sein, dass die Stromversorgung versehentlich unterbrochen wurde oder das Wetter den unerwarteten Abstieg verursacht. Sobald der Pilot die Ursache des Problems ermittelt hat, kann er geeignete Maßnahmen ergreifen, ohne das Risiko einzugehen, dass sich die Situation noch verschlimmert.

Glaube nicht, dass du unverwundbar bist. Es liegt in der Natur des Menschen zu denken, weil bisher nichts schief gelaufen ist, nichts jemals passieren wird. Aber diese Art des Denkens verursacht Flugzeugabstürze. Es sind drei Seiten eines Rechtecks, die ein Pilot fliegen muss, um ordnungsgemäß auf einer Landebahn zu landen. Jede Kurve erfordert den richtigen Einschlag und die richtige Höhe, aber diese können durch Wetter und andere Bedingungen verändert werden. Viele Piloten glauben, dass sie das im Griff haben. Mit der Zeit sind sie nicht mehr so fleißig oder informieren sich nicht mehr weiter über die möglichen Gefahren. Diese Selbstzufriedenheit hat viele Unfälle verursacht, oft mit tragischen Folgen. In der Geschäftswelt kann die gleiche Art des Denkens dazu führen, dass Unternehmen entweder ein Risiko ignorieren oder nur vage Pläne haben, damit umzugehen. Das schafft ein größeres Risiko: das Risiko, dass ein Projekt entgleisen kann, ohne einen festgelegten Plan, um es zu beheben. Stattdessen eine formelle Risikobewertung, die zu einem schriftlichen Plan für den Umgang mit nachteiligen Eventualverbindlichkeiten führt. Obwohl Sie nicht in der Lage sind, jedes Problem zu antizipieren, können Sie sich die beste Chance geben, im Falle eines Problems richtig zu reagieren.

Geh nicht alleine. Einige Piloten – und einige Unternehmer – entwickeln eine Macho-Ich-kann-es-tun-Haltung, die zu Problemen führt, wenn sie versuchen, mehr zu übernehmen, als sie bewältigen können. Zum Beispiel: Stellen Sie sich einen Piloten vor, der in der Nacht vor einem Flug nur drei Stunden geschlafen hat. Für kommerzielle Piloten wäre dies wahrscheinlich ein No-Go-Faktor. Für Privatpiloten sollte dies auch ein No-Go-Faktor sein, außer dass einige Piloten glauben, dass sie den Flug trotz Schlafmangel schaffen können. Die Gefahren dieses Verhaltens in einem Flugzeug liegen auf der Hand, aber es ist auch im Geschäftsleben gefährlich. Wenn Sie mit zu viel Verantwortung, zu vielen Arbeitsstunden oder Aufgaben zu kämpfen haben, für die Sie nicht das Know-how haben, holen Sie sich Hilfe.

What does formation flying have to do with Agile teams?

By

Flying just a few feet off of the wings of the pilot in front and to the right of him, this skilled pilot was determined to keep a tight formation. And he was not alone in his efforts and highly honed flying abilities, as every single pilot in his entire squadron was similarly adept at maintaining this tight formation no matter the direction, the weather, or even the specific order in which these aviators organized. The formation would have looked impressive to anyone observing from the ground, but it wasn’t a formation used to impress observers, it was utilized because it worked. By maintaining this flying organization, each member of this flying contingent was able to benefit from the lift created by the pilot off of his wing, to the tune of a 71% improvement in fuel consumption. The exception to this economy of course was for the sole lead pilot, which did not benefit from having a lead aircraft providing a boost of lift. So to account for this, each member of the flying team would rotate to the lead position at regular intervals so that they could ensure that every member would share the burden for a portion of the total flight time. This highly skilled team of aviators recognized that they could not possibly fly as far or as long without teamwork. But this spirit of teamwork did not end with the decision to maintain an efficient formation. They recognized that in order for each of the pilots to be safe, they would need to take care of each other, even when disaster struck, which it did one brisk autumn morning…

The morning had been uneventful, each of the team’s pilots maintaining a tight formation, and a vigilant eye on the ground, because on this particular morning, they were traversing enemy territory. And even though this was a dangerous mission, this mission was much like most of their other missions, as they often were forced to travel over possibly hostile terrain. But unlike most other mornings, a trailing member of the formation was struck, by what no one could be sure, but struck nonetheless, and within moments, his ability to continue flying was affected severely: he was going down. He didn’t have a choice to eject, but rather piloted his disabled craft safely to the ground so that he could assess the damage. But as experience would show, being on the ground where he was much less maneuverable, he was at a greater risk of attack. In order to keep a member of their team safe during emergencies such as these, two fellow pilots also descended from formation, landing near the downed team member, and provided protection while repairs were made. These guardians would stay by the side of the disabled pilot until he was ready to fly again. To this fleet of pilots, teamwork meant never leaving a fellow pilot behind. After a short while, the downed pilot was able to successfully repair his vessel and all three took back to the air, rejoining their squadron. Alone, the pilot may not have survived the ordeal.

This is a true story, although it is a story that likely first took place thousands of years ago. And it is a story that continues to play out even today. You see, the pilots in the story above were not the pilots you may have been thinking of, these pilots were geese.

Geese offer an incredible example of teamwork and how teamwork enables each member of the team to achieve more, travel greater distances, and weather more intense emergencies than they would survive alone. Geese use this tool of teamwork because although it requires a commitment to something greater than each individual, it repays that commitment with many more benefits not available without this pledge of membership.

So what do geese flying in formation have to do with Agile teams?

Plenty! I would venture to guess that no company in existence would openly say that they do not believe in teamwork.  I would further venture to say that most of these companies would state firmly that their teams are very good at demonstrating teamwork in the projects they undertake.  But the truth of the matter is that most teams rarely demonstrate the type of teamwork that produces results proving the possibility that the whole truly can be greater than the sum of the individual parts.  The word ‘teamwork’ has unfortunately been reduced to nothing more than a term on the balance sheet of requirements for a group of project associated individuals; a definition never verified, never authentically encouraged by the organization, but believed to exist nonetheless.  It is a word that has lost its power.  It is routinely applied to describe a group where the group behavior does not merit its application of meaning.  It is overused, under-realized, and misunderstood because of each of these are true.  And yet only a small percentage of ‘teams’ out there truly endeavor to seek the rewards that come from achieving a level of performance and professional satisfaction that is the byproduct of individuals that sacrifice their distinction, their difference, and their dissimilarities in their pursuit of that which is greater than any one person.  They pursue the quotient that is achieved when individuals become teams.  When individual output transforms into teamwork. Agile requires teamwork in the truest sense of the word.  Agile processes reward and recognize good team behavior in the spirit that good teams can produce great results, and as teams mature, great teams can produce extraordinary outcomes.   Don’t believe me?  Then let me pose a question to you…

Have you ever been a part of a team where everything seemed to click?  Where if you had an issue, someone on your team was there to help almost before you were able to ask?  Have you ever been on a team where the work seemed less like work and more like an expression of your and your team’s passion and energy?  If so, then you are not alone, as most people have actually had the experience of achieving this level of team maturity that results in true teamwork.  If you were not able to relate, then it is up to you to create this atmosphere with your own team, on your own project. But before we can truly become a team, we have to also address the flip side of the coin, and that is the dysfunctions that can easily sink the most well-intentioned ship of individuals who set out to discover the holy land of team performance.  Patrick Lencioni did a very good job of identifying these major areas in his book, The Five Dysfunctions of a Team, so instead of reinventing the wheel (or the team), let’s use Lencioni’s model as our foundation.

Dysfunction One:  The absence of trust among the team members

I think that I can safely say that if you do not have trust, you do not have anything…at least you do not have anything so far as it relates to creating a true team.  What do you have when your team members don’t trust each other or don’t trust you?  You have a group of individuals working in close proximity, but you do not have a team.  You also have a group that is not able to focus their efforts on creating a truly great product, because they must divide their attention on ensuring that they are not going to be stabbed in the back.  Even if the distrust does not rise to the levels where your resources begin to connive against one another, you still have a group that cannot truly communicate, because true, effective, healthy communication is based on a foundation of trust.

Dysfunction Two: The fear of conflict

Great teams fight.  Perhaps the word ‘fight’ is a bit strong, but great teams are not afraid of conflict, because out of conflict can emerge true resolution.  I say true resolution, because resolution can happen without conflict, but it is not authentic because it typically is simply a result of one party giving in to avoid the conflict, rather than remaining passionate about the best outcome.  Conflict is not beneficial simply for conflict’s sake, but when teams fear confrontation and conflict, communication suffers, knowledge sharing suffers, and ultimately the individuals begin to manage their own actions from a place of fear, which never returns great results.

Dysfunction Three: The lack of commitment

We use the word commitment a lot in Agile, but in this context, the word commitment is more aligned with being absolutely committed to the team’s goal rather than our own individual objectives.  When a team of individuals is committed to achieving the goals of the team, no other possibility exists, and when faced with adversity or the risk of missing an objective, the committed teams gets creative to resolve their own issues.  Commitment does not have a back door through which we can escape when times get tough.  When a team embraces their commitments, there is little that they cannot not accomplish.

Dysfunction Four: The avoidance of accountability

The buck stops here.  Not at the desk of the project manager, but at the door of the team’s war room.  The team’s ability to remain accountable to their commitments means that creativity is likely to flow in the face of project difficulty.  I am not accidentally being vague here, I am purposely avoiding being too specific because I have seen many varied examples of how a team’s creativity in their attempts to resolve issues has surprised even them.  Keep all possibilities open, along with your mind, and allow the intelligent people you have assembled for your team to be accountable, even up until the very end.  With accountability comes the possibility of glory, don’t take this away from your team.

Dysfunction Five: The inattention to results.

In order for any team to have the possibility of making improvements, they must be able to honestly assess the effectiveness of their results.  It may be nice to sugar coat our reality, so that we don’t hurt anyone’s feelings, but all we are doing when we practice this soft-handed approach, is sweep under the rug the very information that is most likely to assist us in improving our future efforts.  Results are not good or bad, it is just information.  What teams do with this information will determine the character of the team.  Team’s that choose to ignore the difficult to digest results will continue to produce that same quality of results, but instead of improving their actions, they will simply develop an immunity to the effects the poor results use to inflict.  If it is painful for a team to honestly and authentically examine their results, then this is a sure sign that they need to examine them in detail.  Allow the team to feel the pain, experience any negative reaction that comes from this examination, and most importantly, use the total experience to open up the possibility of valuable conversations that will allow the team to avoid repeating it all again in the future.

Agile is all about Team, not about individuals

Individuals are great, I love having superstars on my team, but when we work together to achieve a common goal, I only recognize good team behavior, not individual efforts.  The people on your team are just like people everywhere; they will behave in ways that reflect how they are rewarded and recognized.  So if your company does not officially reward teams that perform, only individuals (like during annual reviews), start the conversation to address this.  If you don’t, please do not be surprised when all of your cheerleading over the importance of teamwork, team play, and team building are met with cheers, but then never realized. Agile requires many different areas that reflect the need for a true cultural paradigm shift within most companies, teamwork and team building being one of the majors, so get ready, it is now up to you.  Because if you have made it this far in my post, you have heard the bell.  And you cannot un-ring the bell, you know.

Simplify your project plan with a pre-flight checklist

By

A national project management survey released this month reports that most projects are not meeting goals, and team members are often not trained properly. While most projects are eventually completed, only one-third of them come in on time and on budget. If pilots flew aircraft like we run projects, no one would ever fly. Even now, millions of people fly for work or pleasure and flights arrive on time almost 80 percent of the time, delayed mainly by weather. Airline travel is also the safest form of long-distance travel with a fatal accident rate of .022 per 100,000 hours flown. If you flew every day of your life, you have less than a 1 percent chance of being in a fatal accident. We have been flying for just over 100 years, but project management has been around since the building of the pyramids and the Great Wall. As an instrument-rated pilot, project manager, and Agile Coach, I believe some hard-won lessons from thousands of pilots can be applied to project management as well.

Pre Flight Checklist

With a pre-flight checklist, a pilot checks off tasks that are inarguably numerous, complex, and essential to the success of the flight. Project managers can use this same process for project success. I’m probably stating the obvious here, but I’m sure you’ll all agree that there’s usually a heap of documents accompanying any substantial IT project. And no shocker here, the larger and more complex the project is, the more documentation there will be and the more things you’ll need to track, like milestones, deliveries, meetings, development activities, testing cycles, etc. Take an example from my past. I helped a client undertake a substantial, $20-million business intelligence data warehouse rebuild. Behind it all was a 500-page RFP, a 150-page vendor proposal with two 50-page supplements, a 100-page service agreement, and a 50-page project plan (when printed at font size 8). And that’s not even considering the design documents. That means that we had lots of mission-critical tasks, to-dos, and deliverables nested in the equivalent of nearly two reams of paper. The problem is how to distill the essential items needed to simply track and manage large-scale projects through delivery so that we aren’t bogged down by hundreds of pages of documentation on a daily basis. I believe some hard-won lessons from thousands of pilots can be applied to project management as well.

What IT leaders can learn from the aviation industry 

When an airline pilot sits in the flight deck of a commercial airliner, it’s a no-brainer that his pre-flight preparation is serious business. The tasks the pilot performs are inarguably numerous, complex, and essential to the success of the flight. Hopefully, for everyone’s sake, when a pilot preps his plane for takeoff, he’s not thumbing through a 1,000-page flight manual or consulting an operator’s guidebook on running diagnostic sequences or properly positioning the flaps. There’s a time when it’s necessary for the pilot to consult detailed schematics, procedures, and instructions, but it’s not when he’s getting ready for takeoff. It’s not something he should be doing every few minutes of the flight, either. Instead, the pilot relies on a simplified protocol, otherwise known as a “pre-flight checklist,” to make sure he doesn’t overlook anything. The checklist reminds the pilot of the important things that need to be done without having to search through pages of extremely detailed materials. It’s a simple, fast and nearly foolproof method for the pilot to determine at a glance what tasks he’s completed and what tasks he still needs to take care of. You can bet your life that by the time the plane is backing away from the gate, the pilot has everything under control. In fact, that’s exactly what we do. Simply put, the checklist is a high-level, well-organized, and above-all straightforward inventory of what needs to get done for the project, i.e. deliverables, tasks, etc. And it’s put together in such a way that lets you track whether something is complete or outstanding.

What’s the problem with the project plan?

I know what you’re thinking: Isn’t that what the project plan is for? In a word, no. The problem with the project plan is that it’s too detailed to be a daily-use, multipurpose tracking tool. There’s way too much information, and it takes much too long to make any sense of it. Plus, because there’s so much detail in the project plan, it’s easy for some things to get lost. A checklist, on the other hand, lets you see at a glance and report on what’s done and what still needs to be done.

Creating a checklist, putting the essentials in one place

Once the project is underway, the first thing you should do is scan through the essential documents, pull out the items that need to get done, and add them to a spreadsheet. Include the items that need to get done, a box to check when they’re done, and a column for notes. You might also want to include a column to store a document reference for each item, but that’s it. Save the due dates and dependencies for the project plan. It will be sitting there when you need it. The checklist is meant to simplify, so keep it simple. Organize the checklist items into relevant groupings, but don’t go category crazy. Three to five categories should be enough. These groups would include:

  • “Fundamentals” for items related to project setup, contracting, team assembly, due diligence, technical platform setup, etc.
  • “Recurring Events” to track completion of project meetings, delivery of project updates and performance reports, etc.
  • “Development” for items related to design, build tasks, UAT, roll-out, acceptance, and sign-off. How you categorize these tasks depends on preference and the complexity of the project, but keep the goal in mind — simpler is better.

How to use a checklist 

One test of a good checklist is how easy it is to staple with one hand. ­­Because your checklist should be one of those “take-everywhere documents,” you’ll be glad it’s so condensed. And that touches on one of its primary uses — a no-nonsense list of what’s been done and, just as important if not more so, what hasn’t. Your checklist should become an essential part of project meetings and reviews with other members of the IT group, the business, and vendors. The checklist is also a valuable tool to share in governance meetings. Assign one person to be the keeper of the checklist. He or she will responsible for all updates, the addition of new items, and going down the line with the checkmarks. Update it regularly and perform monthly checks of the items against the project plan to determine which items are behind, ahead, or on schedule. As much as it may have sounded like I was “naysaying” the project plan, I wasn’t. It will, of course, be needed, but its value will really be appreciated when it’s used as a reference document and not the end-all of project management. If a simplified checklist can work for a flight crew of two, flying a $250-million dollar piece of equipment weighing over 700,000 pounds and loaded with almost 500 passengers, you can certainly make one that suits your project management needs.

Pilot, Projectmanager, Agile

By

To land a plane you need to line up with the runway, figure out the right rate of descent and airspeed, then monitor and manage those, all the way down to the ground. Your goal is to touch down on the runway, rather than before or after it, while traveling fast enough that the plane doesn’t stall and fall out of the sky, but slow enough that the wheels stay attached when they hit the ground, and you can stop within the amount of runway you have at your disposal. Simple? Well, not so much.

How not to land a plane

If you drop the average person with no experience of flying into the captain’s seat and ask them to land a plane, they will almost certainly get into trouble very quickly. Even if you line them up with the runway and tell them the rate of descent and airspeed they need to maintain, they will probably still lose control of the aircraft. What inevitably goes wrong is that the pilot-to-be assumes that you should use the throttle to control airspeed, and you should use forward and backward movement of the yolk or joystick to control the rate of descent. That’s understandable. A plane is just a three-dimensional car, and in a car, we control the speed with the gas peddle, and direction with the steering wheel. With a plane, things are reversed. If your rate of descent is too fast, increase the throttle. This will flatten out your descent and get you back on track. If you are too high, decreasing the throttle will cause the plane to fall faster. While getting back on the correct rate of descent with the throttle, you control the airspeed by pulling back on the yolk to raise the nose, which slows the plane. If the plane is too slow, pushing the nose down will speed it up.

Landing your first project

Training for new project managers is often either nonexistent or amounts to a one or two day course. Contrast this with the on the ground, theoretical training required by a pilot. For a sense of what a pilot goes through in ground school, take a look here. Landing a plane is actually much simpler than bringing a typical software project in on time. But we impose some of that difficulty on ourselves, by not knowing which levers to pull to control the project. We seem permanently stuck, like amateur pilots using levers that are intuitive, rather than asking whether we might crash less projects by trying something different. How many projects have run into trouble, only for the corrective action to make matters worse? Throwing more bodies at a late project, Calling extra meetings, demanding more status reports, introducing or abandoning tools or practices, cutting corners in QA, Version Control, Deployment. Shipping more features with more bugs, rather than fewer features with less bugs.

Lessons

The pilots teach us a number of lessons that we can apply to projects. Few people have an automatic ability to fly planes, or manage the project. These are skills that need to be learned. Pilots can not afford to learn from their mistakes, so the learning is front-loaded with serious training that is both broad and deep. The intuitive ways of controlling a plane or a project are often the wrong controls and are more likely to make things worse than better. An average person may have some chance of landing a small aircraft and some people have been “talked down”, but they have virtually no chance of manually landing a large commercial airliner. This last point is interesting. Unless properly trained, no none has ever been called on to land a “heavy” jet. With the technological advances, modern aircraft stand a much better chance of landing themselves than of being successfully landed by someone with no flying experience. The interesting thing about non-experienced pilots is they are significantly more likely to be able to land a single-engine light aircraft ten times than land a jet once. In fact, while the first one or two landings of the light aircraft might be a little bumpy, the pilot will likely improve with each effort. This “many small landings” instead of “one big landing” is the essence of Agile project management.