Share via

Ist ein Pilot an Bord?

  • Artikel

"Wenn ein Pilot an Bord ist, würde er oder sie bitte seine Anruftaste anrufen?" ist etwas, was kein Passagier jemals hören möchte. Ich habe eine bemerkenswerte Nachricht von einem wahren Vorfall wie diesem, der im Dezember 2013 passiert ist, erneut gelesen. Nachdem der Pilot eines Fluges aus Des Moines, Iowa einen medizinischen Notfall erlitt, stellte der Co-Pilot eine Anfrage für alle Piloten an Bord. Der Kapitt. Mark Gongol, ein B1-Bomberpilot der US Air Force, trat in den Bruch. Das Flugzeug, die Passagiere und die Crew sind alle sicher gelandet.

Es ist eine großartige Geschichte, aber mein Erneutes Lesen wurde kürzlich durch etwas ganz anderes ausgelöst. Ein potenzieller Kunde von uns hat kürzlich angerufen und gefragt, ob er unsere Enterprise-Projekt-Arbeitszeittabellen-Software "pilotieren" könnte. Diese Art von Anrufen bringt mich immer zum Anhalten. Wenn jemand in einem Flugzeug "Pilot" sagt, sind wir uns alle sehr klar, was gemeint ist, aber wenn jemand, der Softwareoptionen auswertet, sagt "Pilot", bin ich mir nicht so sicher.

Der Begriff "Pilot" in der Softwarewelt wird häufig mit anderen anspruchsvollen Auswertungsmethoden wie "Proof of Concept" kombiniert. Sehen wir uns an, was diese Begriffe bedeuten und wie Sie sie am besten in Ihrem eigenen Unternehmensevaluierungsprozess verwenden können.

Proof of Concept

Dies ist ein Begriff, der viele Jahre zurückreicht und in der Elektrotechnik beliebt ist. "Breadboarding" wurde eine Schaltung durchgeführt, um zu sehen, ob die Schaltung möglich war, nicht um mit der Erstellung für die Produktion zu beginnen. Im Proof of Concept verbringen Sie möglicherweise mehr Zeit auf einer Laborbank als beim Erstellen der Produktionsschaltung, aber der einzige Schaden, den Sie anrichten konnten, war die Platine, an der Sie vor Ihnen gearbeitet haben. Es war eine kostengünstige und risikoarme Methode, um zu beweisen, dass ein elektrischer Schaltkreis ein gewünschtes Ergebnis liefern kann.

Softwaretechnisch sollte ein Proof of Concept entworfen werden, um etwas zu beweisen. Wenn potenzielle Kunden anrufen, um zu fragen, ob ich ihnen helfen kann, einen Proof of Concept für Enterprise-Projektmanagement- oder Enterprise-Arbeitszeittabellen-Software zu liefern, habe ich immer die gleiche Antwort: "Welche Konzepte möchten Sie beweisen?"

Dies wird in der Regel mit Stille und einem verwirrten Ausdruck begegnet.

Wenn Sie einen Proof of Concept durchführen und keine Vorstellung davon haben, was Sie beweisen möchten, wie werden Sie dann wissen, ob es sich um einen Erfolg oder ein Misserfolg handelt? Es gibt natürlich keinen Weg.

Warum, fragen Sie, möchte jemand überhaupt einen Proof of Concept machen? Die häufigste Antwort ist, dass der Anforderer wahrscheinlich nicht über das erforderliche Buy-in vom Management verfügt, um die Software zu implementieren, die er recherchiert, und hoffen, dass er sich, wenn es nur vor ihnen läuft, in die Idee verlieben und sich darauf verlieben würde, dass sie bereitgestellt werden sollte. In diesem Fall ist der "Beweis" das Management, und das "Konzept" ist die gesamte Idee der Unternehmenssoftware.

Wenn es so einfach wäre, das Management davon zu überzeugen, dass Enterprise-Projekt- und Arbeitszeittabellensoftware gut für sie geeignet ist, würden wir viel mehr davon bereitstellen.

Das Problem bei dieser Methode besteht darin, dass die Arbeit, die Sie zum Bereitstellen dieses Proof of Concept-instance ausführen werden, sehr unwahrscheinlich ist, dass sie dieselbe Unterstützung wie für die Produktionsbereitstellung eines Unternehmenssystems erhält. Wenn ein organization ein Unternehmenssystem bereitstellt, z. B. eine Arbeitszeittabelle oder ein Projektmanagementsystem, sind viele Dinge erforderlich, damit es erfolgreich ist. Zunächst muss für jeden Aspekt des organization, der an der Bereitstellung beteiligt ist, eingaben von der Verwaltung und dem Personal der Leitung erfolgen. Als Nächstes ist Zeit für die Konfiguration, Unterstützung durch technische Dienste für die Verknüpfung mit anderen Unternehmenssystemen, Managementsponsoring, Zeit für Schulungen und, ja, Geld erforderlich.

Wenn Sie über keines dieser Dinge verfügen, was ist dann das System, das Sie in Ihrem Proof of Concept abschließen können? Es wird ein Schatten dessen sein, was Sie sich bestenfalls wünschen. Im heutigen In-the-Cloud-Zeitalter können Sie wahrscheinlich Zugriff auf ein System erhalten, das vollständig gehostet ist, sodass Sie sich zumindest keine Gedanken über den Kauf von Servern und Software machen können, aber nur ein System installiert zu haben, ist ein Bruchteil der Arbeit, die erforderlich ist, um sogar eine grundlegende Bereitstellung Ihres Proof of Concept-Systems zu machen.

Es ist leicht zu verstehen, warum ein organization zögern wird, viel Geld und Ressourcen für die Implementierung von etwas aufzuwenden, das das Potenzial hat, die gesamte organization zu beeinflussen. Es ist eine Übung mit hohem Risiko. Wir neigen dazu, nur über die Vorteile von Projektmanagementsoftware für Unternehmen zu sprechen, aber es ist leicht vorstellbar, dass dasselbe Projekt, das schief gegangen ist, eine ebenso negative Auswirkung haben kann. Die Risikominderung ist also ein offensichtliches Problem. Aber wenn die eigentliche Herausforderung darin besteht, das Management von den Vorteilen des Systems zu überzeugen, dann gibt es sicherlich bessere Möglichkeiten, dies zu tun. Bei HMS Software haben wir uns auf einige der folgenden Techniken konzentriert:

  1. Sprechen Sie mit einem echten, bereits vorhandenen Client.

    Wir sind hier gesegnet, einige großartige Kunden zu haben, die im Großen und Ganzen sehr zufrieden sind. Wenn ein neuer potenzieller Kunde Bedenken hat, worauf er sich einbezieht, erhalten wir diese organization zusammen mit einem vorhandenen Kunden. In vielen Fällen war der bestehende Kunde großzügig genug, um eine persönliche Besprechung zu veranstalten. In anderen Fällen führen sie Anrufe untereinander aus, an denen wir bewusst nicht teilnehmen. Wir ermutigen den bestehenden Kunden, sowohl gute Nachrichten als auch Herausforderungen zu teilen.

  2. Lassen Sie uns es beweisen.

    Wenn Sie wirklich ein Konzept haben, das zu beweisen ist, dann lassen Sie uns ihnen helfen, es zu beweisen. Es gibt legitime Gründe, warum einige Aspekte einiger Implementierungen zuerst nachgewiesen werden müssen. Möglicherweise verfügt die Bereitstellung über sehr große Datenmengen bestimmter Arten von Daten. Wir wurden beispielsweise einmal gebeten, die Funktionsweise unserer Lösung mit einer besonders großen Projektlast zu zeigen. Wir wurden gebeten, Software zu zeigen, die mit bestimmten Browsern oder mit bestimmten Datenbanken funktioniert, oder verknüpfungen mit bestimmten Versionen bestimmter externer Systeme. Wenn dies die Art von Konzept ist, das die Bewertung blockiert, dann sind die Experten, die diese Herausforderung am besten meistern können.

  3. Damit können Sie ein bisschen trainieren.

    In dem Fall, in dem der potenzielle Kunde unbedingt zeigen muss, dass das System mit seinen von seinen Mitarbeitern verwendeten Daten arbeitet, helfen wir beim Laden der Daten in ein gehostetes System und tun dann ein Minimum, um das System wie vom Kunden gewünscht zu konfigurieren und die beteiligten Personen zu schulen. Wir ziehen es sehr vor, in das Unternehmen gebracht zu werden, um bei der Demonstration selbst zu helfen, aber wenn dies nicht möglich ist, bitten wir, das Skript oder die Demonstration zu überprüfen, das die beteiligten Personen verwenden werden, und bitten sie, bei der Anpassung zu helfen oder Die Leute zu schulen, um es zu liefern.

Wo ist ein Pilot, wenn Sie eines benötigen?

Wie sieht es mit dem Pilotprojekt aus? Das ist besser, oder? Es könnte sein. Wenn Sie aufgefordert wurden, eine Pilotbereitstellung einer Enterprise-Arbeitszeittabelle oder eines Enterprise-Projektmanagementsystems einzurichten, sollten Sie zunächst die Ziele festlegen. Wenn es bei den Zielen um Proof of Concept geht, befinden Sie sich überhaupt nicht in einem Pilotprogramm.

Ein Pilotprojekt ist eine reale Livebereitstellung in der Produktion. Es handelt sich in der Regel um eine Teilmenge der Gesamtbenutzerbasis, die für das zu bewertende System in Betracht gezogen wird, sodass ein Pilotprogramm wahrscheinlich einige Zeit in Anspruch nimmt. Während die Anforderungen der vollständigen Zielbenutzerbasis von Anfang an berücksichtigt werden, konzentriert sich das Pilotprogramm auf eine echte Implementierung für die Pilotbenutzer. Sie werden tatsächlich ihre Projekte verwalten oder tatsächlich ihre Arbeitszeittabellen mit dem neuen System ausfüllen.

Die gleichen Herausforderungen, mit denen eine vollständige Produktionsbereitstellung konfrontiert ist, sind auch bei der Pilotimplementierung konfrontiert, mit Ausnahme des Umfangs oder der Komplexität der Daten. Zu den häufigsten Herausforderungen von Pilotprojekten, die ich gesehen habe, gehören mangelnde Förderung, unzureichendes Budget, Zeit und Ressourcen und, wahrscheinlich am schlimmsten, ein Mangel an artikulierten Zielen, um zu wissen, wie man feststellen kann, ob das Pilotprojekt erfolgreich war oder nicht.

Das heißt nicht, dass ein Pilotprojekt schlecht ist. Die Durchführung eines Pilotprojekts kann sehr sinnvoll sein und dazu dienen, das Risiko zu verringern, dass sich eine unvollständige oder schlecht konfigurierte Bereitstellung auf die gesamte organization auswirkt. Aber ein Pilotprojekt erfolgreich zu machen, erfordert einige Überlegungen.

Vor kurzem haben wir mit der Arbeit an einer umfangreichen Bereitstellung für einen öffentlichen Sektor organization begonnen. Erfreulich an der Übung ist, dass die organization bereits die gesamte Zeit aufgewendet hat, die sie ihre Bewertung abschließen sollten. Sie haben sich für das Unternehmenssystem entschieden. Glücklicherweise ist es unsere. Wir haben im letzten Jahr mit dem Evaluierungsteam zusammengearbeitet, um sicherzustellen, dass die technischen Fragen beantwortet wurden, aber jetzt konzentriert sich der Fokus auf die Auswirkungen auf den täglichen Prozess der Personen in dieser organization.

Sie schlugen vor, dass wir über einen Zeitraum von 6 Monaten mit einer Gruppe arbeiten, die zwar sehr gut ist, aber immer noch nur etwa 10 Prozent der gesamten Gruppe ist. Es gibt ein angemessenes Budget, das Pilotprojekt verfügt über die Unterstützung des Managements auf oberster Ebene und wir haben genügend Zeit, um sicherzustellen, dass wir bei allem, was wir normalerweise bei einer Bereitstellung wie dieser tun würden, unterstützen können. Die Gruppe, die in diese Projektverfolgungs- und Arbeitszeittabellenumgebung versetzt wird, wird auf absehbare Zeit in der Produktion damit arbeiten, also ist es nicht nur ein Test. Dies ähnelt eher der ersten Phase der Bereitstellung und nicht der Übung "Probieren Sie es aus, und wir werden sehen, wie es läuft". Bei all diesen Faktoren erwarten wir ein erfolgreiches Ergebnis in diesem Jahr.

Abschluss

Pilotprojekte und Proof of Concept-Projekte sind eine Tatsache des Lebens in Unternehmenssoftware, aber wenn Sie eines in Ihrer Zukunft haben, können Sie helfen, es zu einem Erfolg zu machen, um alle Beteiligten auf einige wichtige Erfolgsfaktoren hinzuweisen:

  1. Stellen Sie zunächst sicher, dass Ihre Ziele klar formuliert sind.

  2. Stellen Sie als Nächstes sicher, dass das Management versteht, was Sie benötigen, und Sie in Bezug auf Geld, Ressourcen und Zeit unterstützt, um diese Ziele zu erreichen.

  3. Stellen Sie abschließend sicher, dass Sie einen Projektplan erstellen und ihn wie jedes andere Projekt in Ihrem Portfolio verwalten.

Über den Autor

Chris Vandersluis ist Präsident und Gründer von HMS Software aus Montreal, Kanada, einem zertifizierten Partner von Microsoft. Er verfügt über einen Abschluss der Wirtschaftswissenschaften an der McGill University und über 30 Jahre Erfahrung in der Automatisierung von Projektleitsystemen. Er ist langjähriges Mitglied des Project Management Institute (PMI) und hat die Kapitel Montreal, Toronto und Quebec der Microsoft Project Users Group (MPUG) gegründet. Zu den Publikationen, für die Chris geschrieben hat, gehören Fortune, Heavy Construction News, Computing Canada Magazine, PMI's PMNetwork und Project Times. Er unterrichtet Advanced Project Management an der McGill University und spricht häufig in Projektmanagement-Verbandsfunktionen in Nordamerika und auf der ganzen Welt. HMS Software ist Herausgeber des projektorientierten Timekeeping-Systems TimeControl und seit 1995 Microsoft Project Solution Partner.

Chris Vandersluis ist per E-Mail erreichbar unter: chris.vandersluis@hms.ca

Wenn Sie weitere EPM-bezogene Artikel von Chris Vandersluis lesen möchten, lesen Sie seinen EPM-Leitfaden-Blog (https://www.epmguidance.com/?page_id=39).