'''AntiPattern Name''': ''TheProcessIsTheDeliverable''

'''Type''': ''Organizational''

'''Problem''': You master the process far better than you master the quality of the deliverable (technically and/or functionally).

'''Context''': The customer and/or your line management requires you to prove you fulfilled your project commitments.

'''Forces''':
* You have no mean to assess whether or not the delivery will be of good quality because you don't understand nothing to developer stuff (technically and/or functionally).
* You have a lot of stress coming from your customer and/or manager, for instance a compressed project time line.
* You have to lead a team of people with a lot of them talking an esoteric language.

'''Supposed Solution''': You put in front of all other topics the respect of the process of delivering something to production, making it far more important than the actual quality of the product delivered to production.

'''Resulting Context''':
* You gained time.
* You can protect yourself from the immediate threats, moving the debate on the process compliance ground, with the teams as well as with the customer and/or the manager.
* You have a capability to argue rationally that ''if the product is bad, that means that the process was bad'', which is a way to say ''this is not my fault because I did not design the process''.
* You take the risk that someone who understands a bit the project depict a completely different picture to your customer and/or manager.

'''Why this is so popular''': Because you can be legitimate at your management position without understanding a single word of what the teams are doing. And this is a frequent situation in the business.

'''Related AntiPattern''''''s''': ThePlanIsTheDeliverable

'''Applicable Positive Patterns''': DualProjectManagement (with a technical leader)

'''AntiPatternCategory''': CategoryAntiPattern, ManagementAntiPattern, ProcessAntiPatterns

----
'''Examples in the Literature''':
----
'''Examples in Practice''':

This pattern is a problem of a lot of European companies that seem to oscillate between two behaviors:
* The total lack of quality system on one side which let the door opened to MadDevelopers.
* The difficult implantation of a process that makes people think it will be the guarantee of good software creation (ItLegend - should it be a category?).
In the second case, I saw once a full management tree trying to hold on to the process in order not to have to question the quality of development (that was bad for sure). It was a context of fixed price contract so it was the good example of the real immediate benefit (for the provider) to use this AntiPattern at the expense of his customer.

This AntiPattern can be explained by several factors:
* Lack of IT competences and/or understanding, leading to the behavior ''it's easier to hold on to the process than to get into the project content, both technically and functionally''.
* PleaseYourManager attitude (see ManagerControlsProcess): as he understands IT even less than you do, then you can prove him you (at least) strictly applied the process and so ''the product should be good, or the process is not''.
* TheCustomerIsSoMean can also provoke this attitude where you have to prove doing your job was just applying the agreed process, when in reality it was delivering a software.

The root syndrome of TheProcessIsTheDeliverable is a ConfusionOfObjectives (root ManagementAntiPattern?), which is quite common in ManagementAntiPattern''''''s. The manager applying the pattern is in a difficult position and he tries to protect himself rather than doing the project correctly, especially rather than getting help. -- OlivierRey
----
CategoryManagementAntiPattern