|
|
|
|
By Deborah Gill-Hesselgrave , STC San Diego Chapter Member
Editor's Note: This article originally appeared in The San Diego Signature, newsletter of the San Diego Chapter.
I've just completed a major six-month project. It began life in a healthy fashion. The scope was known, the deliverables were well defined, and the timeline was both rational and agreed upon by all parties.
By the time we shipped the final deliverables, the scope had nearly tripled, the deliverables were a lot like Forrest Gump's box of chocolates, and the timeline had mutated from precise to amorphous. And, as for the cost, let's just say that this was a perfect case study in support of fixed-price projects as a boon for customers and a bust for providers.
I attribute many of the problems we faced during the second half of this project to our not investing time to develop a known, measurable, and enforceable project plan. We also lacked a shared understanding of the client's requirements regarding quality and time.
In this article I'm going to share my thoughts about the titans that drive every project: quality, cost, and time.
Quality, Cost, and Time
As technical communicators, we constantly drive ourselves to deliver products that are precise, accurate, and clear. We and our managers demand that we meet our deadlines. And through achieving those two goals—quality and on-time delivery—we succeed in our jobs.
To be successful, we plan, we research, we outline. We draft, we proof, and we proffer review copies to editors and SMEs. We manage and implement change requests, we proof (again), and we package and publish our final deliverables. And at the end of each project we collapse in exhausted but proud and satisfied heaps knowing that we did all we could to satisfy the sometime warring requirements of quality, cost, and time.
When we skip a step or shortcut a process, we know that we will certainly compromise at least one leg of this three-legged stool. On those rare occasions when one of our projects fail, it is usually not the level of quality that causes us to reluctantly take that walk of shame into our manager's office. No. We are usually invited in for "the talk" either because the project missed the delivery date or it ran over budget.
I think that the reason for this is twofold: 1) time and cost are quantifiable metrics; 2) quality is, well, qualitative.
Without an observable, measurable metric, quality is largely a perception. So, unless your project is using an agreed upon set of standards that provides criteria for assessing its quality, quality is pretty much whatever you or your manager say it is.
Two True Statements
Let's assume that the following two statements are true.
Time and cost clearly affect the bottom line of every project. Therefore, these factors tend to be the ones management measures. Quality, on the other hand, is a less obvious contributor to cost. As a result, it is the rare occasion when quality is identified as the key contributor to a project's failing to miss either its time or cost goals.
Additionally, except for senior managers and independents, most folks on the business end of producing technical communication products have virtually no direct influence on what a project's costs need to be in order to make the project profitable, and rank-and-file staffers usually lack access to this information, anyway. Consequently, as practitioners we can only affect cost through our ability to meet the deadline.
Because time is a direct contributor to a project's cost and because time and cost are linked, let's proceed for now as though these two elements are one, and let's simply call this combined entity "time." This leaves us with two titans that we can attempt to tame: quality and time.
The Paradox
Going back to our two assumptions, quality takes time and time is money, we are ultimately faced with a paradox: on the one hand, we are expected to meet cost/deadline requirements in order to satisfy the company's bottom-line demands while at the same time we are tasked with achieving a quality level that is usually undefined and, as a result, is difficult to measure.
A prerequisite to working our way out of this paradox is to establish just what we mean by quality and time.
Quality
What is quality?
Quality tends to be amorphous, changing depending on who is describing it. Most operational definitions I've heard regarding quality include something like "lacks errors." As writers and editors, we can easily apply known rules of grammar, mechanics, presentation, etc. to our work and meet the requirements in those areas. But is that the quality standard our products must meet? Is it the only quality standard?
Gerald Weinberg, a software quality expert, defines quality as something that provides "value to some person." But this definition remains too loosey goosey to be of much use. Because value to any one (or more) person can vary over time (because what I need to know today I may not need to know tomorrow), quality can be better defined as "value to one or more persons over some period of time." For example, in the project I recently completed, quality was defined as that information in the final report that will allow the client's senior executives to achieve their fiscal strategic plan over each of the next three years. And, because we appended an additional year to our analysis and recommendations, we increased the value and relevance—the quality—of the finished product by 33 percent.
To begin applying this definition to your own work, identify who the person or people are who need to derive value from your product. Then determine what the period of time is during which they must be able to derive that value.
For example, the developers' guides I am writing need to support the immediate learning needs and the ongoing reference needs of future developers on the project for the period of time during which they will be updating or revising the current code base. Quality for the developers includes accurate, well- presented information that allows them to learn what they need in order to perform specific tasks over a period of time that probably won't exceed a year.
The guides are also targeting another audience, potential investors. For this class of users, quality means providing them with value for the small window of time that is represented by the period between their reviewing the guides and their analyzing the return-on- investment potential if they choose to invest in the company. Quality for the investors includes the actual existence of such documents (for succession planning and disaster recovery), with no judgment about the accuracy of the contents, for a period of some weeks to as much as a couple of months.
Time
What is time?
So how do we determine whether our project is on time? At the risk of stating the obvious, time is relative.
Time is the period in which one has to hit a market window (e.g., during Q2) or meet a promised delivery date (e.g., May 15).
Market windows tend to narrow as they approach, and actual delivery dates become more fixed and immutable the closer they get. Targeting and hitting a market window early means the company can exploit first-to- market opportunities to establish itself and its products with the early adopters and to begin penetrating the class of customers who follow the early adopters. But, as time progresses, market windows that began as fully open tend to narrow and then close.
Similarly, promised delivery dates become fixed and immutable as time counts down to the date. It is easier to renegotiate a delivery date with a client early in a project than it is when the deadline is only a few weeks or days away. The closer the date, the less the likelihood of extending it without costing the company money—whether in real and immediate revenues or in goodwill or potential future business.
As a result of these truths about market opportunities and customer promises, on- time delivery becomes a discussion in relativity.
With market- driven deadlines, deciding whether it is acceptable to miss the date requires factoring in the risks and benefits of both hitting and missing the market window. With promise- driven dates, renegotiating the deadline early presents far less risk to the customer's confidence in your company and its products than does changing the deadline later in the project—especially if you have to reset the anticipated delivery date more than once.
So, time is relative. Early in a project, time is more flexible and open to change and presents less risk. Later in the project, time is far more fixed, and changes to the target date can both threaten the company/client relationship and significantly reduce the perceived satisfaction the customer will have regarding both the company and the delivered product.
Taming the Titans
Clearly, our goal should be to support our company's efforts to ship quality products on time and at a cost that generates a profit. And, just as clearly, consistently reaching this goal is easier said than done. So how do we increase our likelihood of taming these titans?
Faced with the sometimes conflicting demands of quality and those of the Siamese twins cost and time, we must find ways to calm the clash and force these elements to work for us.
First, we have to avoid choosing between one or the other. Then we need to eliminate the constraints that prevent us from satisfying them all equally well. So we have to do the following.
Get the right information.
Every product has specifications that define its quality and cost. Every project has a plan that defines the deliverables and the targeted dates. Make sure you have access to information that allows you to constantly and consistently measure and track the relevant elements of the specifications and the plan. To ignore or to fall out of touch with any of the resources that specify a product's quality, time, or cost goals is to invite disaster. Do you know what the criteria are for quality? time? cost? Are these definitions collectively known and agreed upon throughout your project's team?
Use the best information.
Don't be passive about the quality of the information you're being provided. You cannot make silk out of a sow's ear; if you don't have the right information, the most current information, or complete information, you need to change that situation. This does not mean passively noting it in the "Obstacles/Issues/Concerns" section of your weekly or monthly report. It means trotting yourself to the person who holds the key to whatever information you need and actively ensure that you get what you need in order to deliver a quality product on time (and, thereby, within budget).
Choose the right processes.
Most of us employ the same or, at least, similar processes to produce our products regardless of whether we are developing user guides, Web sites, employee handbooks, proposals, or whatever. To make sure that your processes fulfill the needs of quality, cost, and time, you need to periodically review these practices and conduct project postmortems. Each postmortem should result in an articulation of how well each step of the process supported the project's quality, cost, and time requirements.
What steps had a direct influence on each of these elements? What happened if you skipped or modified a step? Did you have wiggle room to truncate a step to reduce a negative impact on time, for example, but still fulfill the quality requirement?
And, last but certainly not least, do it right the first time.
This should be a no-brainer, but do you and your department achieve it day in and day out? And do you achieve it for every step of your process, from planning to researching to outlining through publishing? Think about these questions: does your planning phase begin and end on time? Does it produce a plan that supports the project's requirements? Is your researching phase conducted per the schedule, and does it yield the depth and breadth of quality information you require to produce the necessary deliverables on time and at the expected level of quality? Do you know how quality is measured? Do your managers and other project stakeholders?
Many managers and practitioners argue that each phase of the writing process is intended to incrementally improve the quality of the product one phase at a time, that, if there is a slip in one phase, it can be made up in the next phase. Although I don't disagree with this, this contention hints at an attitude that compliance with the quality/cost/time mandate is optional during some phases (like drafting) but not during others (like publishing). With that perspective it's easy for us to develop hard-to- shake patterns of behavior that end up working against the underlying benefits of doing it right the first time, every time.
Peace
For peace to reign among these titans, you must first eliminate the ambiguity of what quality means to you and to all of your project's stakeholders. To do this, you must have a set of specific, observable, measurable criteria that define the characteristics of quality. Then you must continuously assess your work against the project's quality definition throughout the project's lifecycle. If you do all of this, you will have quieted one of the beasts.
Next, take time at the beginning of each project to develop and communicate a defendable and actionable plan, one that supports the quality, time, and cost goals of the product as a whole. And, as with quality, revisit your plans at milestone stages throughout the project to ensure that all is as it should be. Through this iterative process, you will cause the ever- competing factors of time and cost to work with you.
Finally, I encourage you to be that voice in the wilderness that sounds the alert when the first hint of trouble threatens your project's established standards for quality, cost, or time. By being the project's defender against encroachments to its quality, cost, or time requirements, you can more effectively steer your projects away from failure (large or small) and to success.
Here's to making peace with the titans!
Acknowledgements
Thanks to: