Quality Vs Deadline: The Eternal Dilemma

This is a situation that would ring a bell in every technical writer’s mind. You are assigned a project with a really tight deadline. You are told in no unclear terms that meeting the deadline is absolutely critical. After a comprehensive analysis of the scope of the project, you find that you just cannot deliver within the stipulated period without compromising on the quality of the end product.

So your options boil down to two:

You put your foot down and tell the management that it is impossible to meet the deadline.
You resign yourself to the situation and deliver the product hoping to get another shot at improving the quality at a later date.

Which option would you take?

Read on to know what seasoned professionals who have been through it all have to say..!

Tharun enunciates...

Quality versus deadline - probably the most widely debated work issues in any industry. There are no straightforward answers to the issue and I feel both the alternatives suggested here would be of little help.

If you say you cannot meet the deadline, you will run the risk of putting the product release on hold! No organization can accept someone who will obstruct product releases. Delayed releases give the competition an upper hand in the market.
If you decide to deliver a poor quality write-up, then you are committing gross injustice to your user community! Incorrect instructions can also lead to a host of issues that your employer can do well without.

In such situations, if one can provide a logical explanation as to why the schedule is too aggressive, the management will give additional time for the effort. But then how does one do this? You can consider taking the following actions to convince the management:

Establish a documentation process that suits your organization:
- Study the process followed by the engineering team
- Ensure that your model or process matches the engineering process
- Identify various milestones for releasing draft version of documentation
Prepare a documentation plan
- Use this to specify the scope of effort. In case you are unable to account for all the features, you can state the assumptions and limitations in the documentation plan.
- Include rough dates, schedules and milestones.
- Identify risks and dependencies
- Send the documentation plan to all stakeholders for review. This gives all stakeholders an opportunity to appreciate the time and effort for the docs and also raise any objections.
Get buy-in from the management; escalate issues if required.
Employ effective project management methods.
Set expectations early.
Report progress and issues on a routine basis.
Establish some tools such as checklists and guidelines that help reduce documentation errors.

(Tharun Kumar Unni is a senior documentation lead at Facetime, Bangalore and the immediate past president of STC India chapter )

Gururaj articulates...

If I were to choose between missing a deadline and handling in shoddy work, I'd miss the deadline. The technical writing business is full of horror stories about this. The dilemma is eternal; your survival is not.

Quality of work takes absolute priority over everything else. It's stupid to churn out some document without ensuring its quality and completeness. In my opinion, quality is sans boundaries. Of course, if you know that it is eventually going to be an issue when you do it, why not learn how to do it right, right from the outset?

Our profession is diluted by some writers and managers who emphasize schedule adherence over quality. The propensity for adhering to a deadline (ensuring good effort/schedule variance data and metrics) rather than writing a useful document imbues our profession with fanciful expectations. When the managers are technical writers themselves, it is easy to convince them. They know what we are supposed to do; in addition, they know what our documents are supposed to do. This comprehensibility becomes one of their differentiating factors.

If you deliver a bad document on time, you are meeting the deadline, but you are going to die. So, do not let your document die an uncanny death in the end; do not let your readers call you incompetent. Your contribution is of little account without quality. If your document were to be personified as a human, you would be behind bars for cold-blooded murder.

All users by nature desire quality information. Without quality, no one would choose to read your document even though it had everything else. If you are unable to meet a deadline, let them know in advance. Speak with your managers about the problem, and request them to extend the deadline. Not all managers are bad. Do not make assumptions about your manager's ability and orientation. Ask as many questions as possible. Even Einstein asked questions!

(Gururaj B.S. works for Hewlett-Packard, Bangalore. He is the Membership Manager of STC India Chapter and also an administrator of TWIN mailing list.)

If you want to participate in any future debates, please contact the column editor, Avinash Akshay.

STC India | Home | Contact Us