While an occasional IT initiative sails through on time and on budget, most are a bit more challenging. Here's how to balance delivering by your target date vs. delivering a fully-functioning product.
One of the most difficult aspects of a leadership role is determining when to "call" an initiative and ask for a delay vs. trying to pull a few more hours of work out of your team and complete an initiative on time, even if it doesn't meet all its stated goals. In rare cases, this decision is made for you.
If you're building airplanes or life support equipment, you're unlikely to push an obviously flawed product out the door just to meet a date. Similarly, if your product or project is related to an immovable date, like a merger close or a presidential election, you're forced to drop functionality and features in order to get something out the door.
The rest of the time, you're forced to make some difficult decisions. Here are some tips to make them more effectively.
Take the pulse
For most organizations and initiatives, there's a general bias toward meeting the date or delivering something as close to functionally perfect as possible. Look at the history of the organization and other recent projects, and listen for clues. If everyone obsesses about the bug in the last product, then you may be biased toward delivering the "right" project; if everyone is obsessed with beating a competitor to market, delivering to a date may be more important.
Be aware that this culture can change depending on the product or project, the internal delivery team, and the external partners. Stakeholders may even "stack the deck" by bringing in outsiders and consultants to shift an organizational bias, so just because your company has always delivered to a date doesn't mean the latest effort is going to follow a similar path.
Getting this general sense of your organization's bias toward delivery date or near-perfection will guide you as you consider options, should either become a risk. There's also no harm in directly asking stakeholders if the schedule or the functionality is more important. Everyone will initially answer "both" to that question, and you may get some uncomfortable questions after asking, but direct communication can clear up any questions.
Define failure criteria and "executioners"
Most management and delivery methodologies suggest that you define failure criteria at the beginning of a project when you have metrics that have been carefully considered and shared during a calm stage; these criteria can later be used to call the project when things get out of hand. Unfortunately, many leaders give this activity the short shrift, or perhaps are overly optimistic or pessimistic to the point where predefined failure criteria are essentially useless. If you find yourself in this situation, develop three to 12 metrics that can quickly be compared with the project's current state. There may be core transactions or features that simply must work, or there may be market commitments that override all but the most critical functional failure.
As soon as talk of moving dates or stripping functionality occurs, quickly define and clearly communicate checkpoints where an assessment of the state of the product will occur, and who ultimately can make the call to delay. Without these clear yardsticks and a well-known cadre of "executioners," you'll leave the fate of the project open to speculation and second-guessing, activities that certainly won't help you move forward.
Muzzle the naysayers and the perfectionists
There are always people participating in a launch or are involved in an ancillary capacity who constantly question the ability of the delivery team to successfully execute, just as there are people who will settle for nothing short of absolute perfection. Unless your project "executioners" fall into this category, rapidly neutralize these parties. Naysayers can often be safely ignored, or be silenced if they feel their opinion has been heard and documented.
Perfectionists can be more difficult, since they theoretically have the best interests of the effort in mind; they are generally unwilling to abandon features or settle for "good enough" in order to get a product to market. In this case, continually communicate that abandoned features and functionality are being pushed into a future release, or simply ignore the input of the perfectionist if it becomes too burdensome. Allow a perfectionist a stage, and every minor problem will achieve end-of-the-world significance, and half your team will be occupied addressing the perfectionist's concerns and documenting mitigation plans that never quite satisfy them.
With an understanding of the culture of your particular initiative and failure criteria, and a grasp on the key parties responsible for making decisions as well as those to be devoutly ignored, you can streamline the often painful process of determining whether to push an initiative forward that's not quite ready, or spend some additional time perfecting key features.
This process is never cut-and-dried, but perhaps the most important aspect is making a decision and moving forward, subject to regular checkpoints. If you constantly second guess your team and vacillate, you'll end up slipping further behind, with most of your effort going into revisited decision making rather than forward progress.