Many companies employ "stage gates" in their development process, whereby a project is reviewed by management after major phases and a "go/no-go" decision is made. The project is reviewed in terms of whether it's tracking to its objectives, the soundness of the business case, and other criteria, depending on the phase. The go/no go decision results either in sign off and permission to proceed, or in cancellation. Used properly, stage gates can prevent unnecessary, off-track projects from going forward and costing the company money it can't recover. However, if there are no parameters around the sign off process it can also allow authorizers to engage in some dysfunctional behavior.
For a project team that is heavily invested in the completion of the project, the go/no go review meetings can be a source of stress. Great efforts are made to present the project in a good light during sign off meetings. Who, after all, wants to get to the end of an employee review cycle with nothing but cancelled projects to their credit? Knowing this, authorizers can leverage their position as stage gate attendants to add requirements to the project, insist on additional functionality, and even--my personal favorite--indulge their latent design skills.
"OK. This project is approved to go forward, IF..." where the Big If is some personally preferred enhancement or design change. The project team can argue against the new requirement, saying that it's out of scope or that it adds unnecessary complexity, but a hostage-taking authorizer usally isn't going to be moved by appeals to logic. The project team grumbles, agrees to make the changes, gets the hostage (the application design) released, and the project moves on.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment