The fixed-price fiasco once followed a false alarm on the night bell - it's never make good. (Franz Kafka: A Country Doctor) What is screwed up in the fixed price offer can not be repaired more often throughout the project. Accordingly, like developers are reluctant to give a cost estimate (" it takes just as long as it takes "), especially if you still do not know what exactly sooo in the project will ever be made. The customer wants to know just very early, and who wants to blame him: he must organize a budget before the project began. Would you build a house (and massive personal debt) without knowing what it costs? Exactly. first Ideally, one makes a technical calculation based on a concept paper and a technical analysis. This one has both, unfortunately, in the rarest cases. second If it is for the technical requirements of a tight briefing (" we like our website will expand to a shop system ") attacks the principle of " An application at the earliest then be calculated if you can imagine, as a user . So one has to list all pages and all processes and can roughly describe. If those descriptions do not exist, it must be indicated on the basis of a short workshops or Telephone conversation with the customer or alternatively make assumptions based on himself. This then comes as a tender in the offer. is whether the request later in the project to be implemented just not that important, it is important to have a description against which you can define additional expense, if needs change (and that is used in the design phase safety ) to pass. The more inaccurate the description in the offer, the more likely it is that the customer wants is something which is more complex than originally kalkuliert.Im area of the business requirements you can get by a little detail work project risks pretty well under control. This applies to the following item 3 only restricted. third If the technical analysis is not available, one can try to make at least a brief search and a short prototyping an overview of the unclear technology or interfaces to get. For technical risks, there are different technical requirements for no power to mitigate through boundaries in the offer. The customer is what counts no matter what their requirements are solved by technology, so it makes no sense to formulate assumptions on offer, because if they do not apply is not a change requested by the customer but quite simply the wrong assumptions of the service. exception interface to external or customer systems. Here it is quite common to write something like "assumption: the product data is provided by a SOAP web service available by the customer." 4th be happy to forget quality assurance, deployment into the live system, documentation, etc. is also here: delimit delimit delimit,. Since this is not quite trivial example in technical documentation (because you can define the level of detail is difficult) you must make do with crutches, such as: "Development of technical documentation, scope about 20 pages. Even if the page number here seems entirely reasonable free, they still fulfilled the purpose impart at least a rough idea of performance.
costs: two addenda Nachtrag 1: Die Folgekosten in meinem Post von gestern müssen nicht unbedingt Geld bedeuten - es funktioniert auch mit den beiden anderen Elementen des Magischen PM-Dreiecks , nämlich Qualität und Zeit: Zeit bedeutet, dass die Auswirkungen der Kundenanforderung auf die Deadline klargemacht werden müssen. Eine kostengünstige Lösung kann möglicherweise mit höherem Risiko behaftet sein und dadurch die Einhaltung der Deadline gefährden. Qualität bedeutet nicht unbedingt das what the agency or the developer keeps it. Many customers mean "no bugs" and generally meet their expectations. What is happening under the hood them is often less important. Excessive demands often lead to higher error rate, which is not a fault of the agency and the client should also be made transparent. Addendum 2: As with any negotiation situation can also go off the shot back. "This sounds entirely with the costs for expansion of my schwiemeligen old system covered, if not do that in half the time create - other agencies do it, I have two offers to lie on the table. Please make the going out the door. "
costs Everything we do has a consequence. (Johann Peter Eckermann) It is acceptable, especially for software developers without pain, . that is the property of the customer in the project created Web site or application, and not the agency this can lead to conflict if the customer requests something that felt by the developers as the deterioration of product quality, and the first impulse is often to say " we do not, that's bungling? ? Or "For example, customers want instead of a state-of-the-art new development rather an existing und veraltete Anwendung weiterentwickeln lassen, zu der ganze Horden von Entwicklern Spaghetti-Code beigesteuert haben und deren technische Basis durch und durch Old-School ist. Eine Erweiterung ist nun mal in der Regel günstiger als ein kompletter Neubau.
Antwort: Doch, das machen wir im Zweifelsfall, denn es Sache des Kunden ob er die Qualität seiner Website verschlechtern will. Aber es gibt einen Ausweg. Grundregel 1 : Was man mit dem Kunden ausgemacht hat (etwa im Rahmen eines Angebotes/Vertrages) muss man durchführen. Man verpflichtet sich mit dem Vertrag zur Erbringung einer bestimmten Leistung zu einem bestimmten Preis, und da gibt it is also nothing to discuss. reason Rule 2: Everything that was not agreed upon (because it goes to a whole new Aufttrag or because there is a change in an existing project) is always negotiable. It offers you the customer turn to a power, but released a price mentioned. This is the most important lever for the customer to guide the project.
For the argument that technology is a thoroughly old-school, and also have hordes of developers contributed spaghetti code "is not accepted by many customers. She is also more aesthetically motivated as they considered that a customer simply a project mt a limited budget has to perform.
One rather should the customer make clear the consequences of his intention, and even the future. " Of course, my client create, we'll be happy your application based on this schwiemeligen legacy application, the expansion costs [here insert moderate price] however. The code to wait very difficult because it has been extended very often uncontrolled. This will mean in the future that we have the monthly costs of running the application must start higher [less moderate price] and also changes in the order of [ ] here are using percentage percent more expensive. "
Of course, the numbers and as such the claim to be realistic and stand up to scrutiny. If they do not, one should seriously question whether the customer is not with his approach is correct.
What users hate about freedom The confidence is coming, everyone has only until its safety (Schiller's "Wallenstein")
almost as much as customers hate bad job insecurity. Clear: their success is often closely connected with the project's success, since one is naturally like in the picture about the current status of the project or the extent of a problem: "Do 'm sorry, Mrs. K., Import product works, unfortunately, still not our turn. True, if it does not have to run tomorrow, we can not go live in time. What do we do then? Äääähhh, good question. "
are more thankful customers if their security concerns with:
regularly and unsolicited status information to give Although the creation of status reports on the most hated work of highly paid software engineers heard. Customers will love you, so create them without the customer having to ask constantly. as possible is always a Plan B ready . Sobald man gezwungen ist, Probleme zu melden, sollte man irgendeine Antwort aus der Tasche ziehen können für den Fall dass sich das Problem nicht oder nicht pünktlich lösen lässt (außer man kann glaubhaft versichern dass das Problem auf jeden Fall in einer definierten Zeit lösbar ist). Prozesssicherheit vermitteln : Wenn ernste Probleme auftreten ist nichts wichtiger, als dem Kunden zu vermitteln, dass man die Situation noch unter Kontrolle hat. Im Klartext: Keine frei erfundenen Versprechungen, sondern eine Schilderung dessen was man bereits getan hat und was man als nächstes zu tun gedenkt um die Situation zu lösen. Das beinhaltet auch den oben genannten Plan B.
Note 1: Of course, belongs to this field. Security is pretty difficult if you provide a complete Gurkentruppe at launch, it (ie design, concept, programming) simply can not.
Note 2: This is all not only with customers but also with managers and teammates. Also like to be informed again and got cold feet when they need to fear that builds on the principle of hope to run instead of active risk management.
In a project a few years ago I had for my agency to create very short notice an offer for a site. The management of the customer had us against the will des Projektteams ins Boot geholt, und ich wusste, dass der Projektleiter auf Kundenseite alles tun würde um uns draußen zu halten (das Projekt endete übrigens genauso krank wie es begonnen hatte, aber das ist eine andere Geschichte...)
Interessanterweise war der Projektleiter nicht komplett unkooperativ. Er setzte eine verbindliche und recht knappe Timeline zur Abgabe des Angebots, Verzug hätte bedeutet dass das Angebot nicht berücksichtigt würde (denn er selber hatte von seinem Management ebenfalls ein knappes Timing für das Gesamtprojekt bekommen). Im Gegenzug hat er uns mit Material zum Angebot geradezu zugekippt und mehrfach nachgefragt ob er denn auch wirklich alle Unterstützung geleistet hat die we need - what we had to confirm in writing. In fact, we were able to accomplish in the time the information is not at all.
He gave us a maximum of this strategy under pressure without making themselves vulnerable. If it subsequently emerged that he has blocked, possibly a second round of bidding the result would have been. You could learn from this: Even in less-charged situations you could get used to as an IT project manager to let all participants a minimum of degrees of freedom, but share the same dates and limits (which also applies to the education of children, if the relevant Literature Guides believe must pay. My children, however, can not read yet):
Example 1: It depends on the project on the supply of materials or releases of the client. , in any case in advance a time limit to keep but not too tight! If the customer fails to comply with them and pointed out that it was ridiculously short, you have very little leverage. Iron insistence on meaningless Time Lines is a service not very good to see. If the customer does not meet the deadline to respond in any case, otherwise the question is to what for the time limit is there, if allowed to pass without consequences.
Example 2: You have to work on customer service with a second (because of the design and makes the own agency, the technical implementation). It is the same as in Example 1, it should also provide for appropriate dates transfers and bug fixes to the customer in case of trouble the other service providers do not even have to take under his protection. In particular, problems of cooperation (not complied with transfers) are not notified too late to the customer. That falls under "the court keep clean," I come back to it in a later post.
a period not to share signaled customers and other project participants, moreover, that the delivery can be in doubt, one day before the deadline. And rightly so.
Why are there "dogmatic"? Wenn Techniker über Projektmanagement reden oder schreiben geht es in der Regel um Vorgehensmodelle - was heute Agile Development ist, war vor ein paar Jahren der Rational Unified Process (kennt den überhaupt noch jemand?) und in der Computersteinzeit das Wasserfallmodell, das sich nach wie vor großer Beliebtheit erfreut (es ist also sozusagen der Quastenflossler unter den Projekt-Management-Moden...). Zu Phasen, Prozessen, Erhebung von Anforderungen, Architekturen und dergleichen mehr möchte ich mich aber eher weniger auslassen (deshalb habe ich mir erlaubt dieses Blog als undogmatisch zu bezeichnen), das können andere besser.
Tatsächlich gibt es Grundprinzipien und Tricks die unabhängig the process model in IT projects from time to time are important and are very helpful especially for beginners. While I have tried to formulate at least some of them, I noticed how hard it is to summarize grip. Maybe that's the reason for this is that you read them so rarely. Some examples of what it does:
- fixed-price offers without sufficient briefing
- account leadership
- The "Hidden Agenda" of the customer and project colleagues
- project policy. How can you clean the yard? (A real ÄhBäh theme, which is a real tekkie is above such things. But wait until I was writing this ...)
- Proper escalation
- What to do if things get tight?
Kickoff Here we go, my first post in my own first blog. It took a while until I was about to answer the question in mind which one or the other bloggers have already made sure: Do I have something to tell the world anything? Something more interesting than the fact that yesterday I tipped a glass of milk? have in my case, I decided to write about technical project management in general and in relation to online projects in particular, because not only satisfy my need but perhaps even for other utility value. I'm 12 years online projects, including 3 as a developer, 4 and 5 as a technical project manager makes a team leader who still projects. There must be something stuck so what is relevant.
