Due Date Before Requirements: A Recipe for Disaster
If you stay in IT long enough, unless you are blessed with exceeding good fortune, you will encounter the situation that a customer wants something built by a deadline but isn't sure what that something is. I lovingly refer to this as "deadline before specs," and the emphasis is on the word "dead."
Back in the days of my captive employment, I faced at least one of these pre-defined fiascos in each shop that I called "home." The mainly contributory elements that each of these companies shared was a project methodology – waterfall – and a marketing-driven mindset. Each placed "blue-sky" ideas about acquiring new business ahead of any sensibility to issues of practicality with respect to implementation.
Let's look at some of the primary ingredients of this recipe:
- belief that new business is the overwhelmingly most important commercial aspect
- belief that business units "know better" about ALL business issues
- belief that anybody, hearing "THE IDEA" would know EXACTLY what it required
- belief that IT resources are completely flexibly configurable
Now, I am among the loudest to tout the notion that customers are THE reason that IT exists. Addressing the concerns of the stakeholders outside of IT is how I pay my bills (and get my thrills). I own a wide and deep experience with several industries and business models. I am not, however, so perfectly versed in the non-IT facets of business that I always automatically "see the vision" of every half-baked project idea that a marketing (or other business) person dreams up. There must be a firm and explicable grasp of the product. There must be a well-described business model. There must be a clearly defined universe of stakeholders. Lacking any of these aspects, the requirements collection process will be profoundly flawed, possibly beyond the capacity to repair.
I don't do waterfall in my private practice. I use a modified Agile approach, just enough project management to keep the design and development train on the rails. Frequent, regular communications among team members, including the client (and any other participating stakeholders), is the byword. The customer must be able to express clearly and concisely answers to the questions:
- What is to be built – the product?
- What is the business model?
- Who are the stakeholders?
The answers to these questions may evolve during development, as new interests and concerns are identified, but at each phase of design and development, I must own a good grasp of what those answers are TODAY. With solid replies to those questions, I can collect requirements and forge estimates of time and cost to deliver the product. Note that it is I who defines the time-lines. The client may opt to reduce the feature payload to reduce the estimated times and costs, but it remains my responsibility and authority to define the revised time-line and cost estimates. This can be the subject of many rounds of refinement. Project planning can be a multiple iterations, successive approximations game. However, the burden for determining the amount of effort and price are my bailiwick. I permit clients, who provide good answers to the three questions, to ask whether the project CAN be delivered by a particular deadline…I can answer that, when armed with good information. I do not any longer accept projects with fuzzy answers to the three questions, when the client has a date pre-specified. My professional reputation demands that I deliver quality software that satisfies the interests of all stakeholders. My duties to my fellow developers require that I not place their reputations at risk or put them into situations that force them to work 80-hour weeks. I will not risk being required to put in hundreds of hours that prove to be unbillable, thereby effectively reducing my earning power. I associate a terribly tiny probability with the outcome that the project will be a success under conditions that I can't develop my specifications from good business requirements but am given a delivery date.
I note that fuzziness of requirements WITHOUT a deadline is a very different case. If a customer needs help developing the answers to "What, How, and For Whom," I can be retained to consult and assist with the determination of those answers. That, however, does not fit within the scope of this post.
It's like the old saw, "how long is a piece of string"? Without clearly stated "What, How, and For Whom," I can't say how long it will take or how much it will cost. I certainly can't offer any reasonable guarantee of a delivery date. 'Tis a harsh reality, but true (unless you're a starving, young developer with no reputation to preserve and willing to risk getting a bad one early out of the gate…not recommended) – deadline before specs should be avoided like plague – it's a ticking bomb.
Do your best to help customers determine missing pieces. Be patient and gentle with the clients, since they may have a good but as yet unspoken grasp of the absent aspects or may be able with encouragement to formulate them. Bottom-line – if the customer can't or won't be convinced to create the necessary parts, they are likely expecting you to do their job for them. When such "projects" (VERY loose usage) come with a proposed deadline for delivery – don't accept them. You won't well serve your customer or yourself to cook up a disaster.