Last Updated: 3 November 2001
Overview<= o:p>
Pre-Sales Versus Post-Sales Specifications <= o:p>
Pre-Sales Specs Gathering<= o:p>
Factors in Limiting the Time Spent<= o:p>
Being Detailed Enough<= o:p>
Post-Sales Specs Gathering<= o:p>
Maintaining Original Promised Priorities and Complexity. <= o:p>
Perspectives in Specs Gathering<= o:p>
Software Development/Architect<= o:p>
Pre-Sales Strategy<= o:p>
Post-Sales Strategy<= o:p>
Project Management<= o:p>
Pre-Sales Strategy<= o:p>
Post-Sales Strategy<= o:p>
Sales/Business Development<= o:p>
Pre-Sales Strategy<= o:p>
Post-Sales Strategy<= o:p>
R&D/Product Development<= o:p>
Pre-Sales Strategy<= o:p>
Post-Sales Strategy<= o:p>
Putting all the Perspectives Together<= o:p>
Specs Rules of Thumb<= o:p>
Specs Must-Haves<= o:p>
Sample Specs <= o:p>
Things Not To Forget<= o:p>
Client Relationship Management<= o:p>
Specs Are Mandatory For the Client<= o:p>
Don’t Blow Up The Specs<= o:p>
The ability to collect good functional requirements and specifications to fulfi= ll those requirements is more than just an exercise in software engineering. I= t is also a sales effort, a project management and an R&D effort. In = most companies, one person is usually collecting requirements/specifications at = any given time, therefore if you only fill one of these roles (software development, project management, sales/business development, R&D/product development) then you need to know the vested interest the other roles have= in order to collect the “ideal” specifications to fulfill the clie= nts requirements as well as being efficient for the_company.
In summary, here is the brief list of “rolesR= 21; that you must think about when collecting requirements. We will later descr= ibe these roles within this SOP and how to think like them.
*&nb= sp; Software Development/Architect
*&nb= sp; Project Management
*&nb= sp; Sales/Business Development
*&nb= sp; R&D/Product Developement
The other main thing to understand is whether you are collecting requirements and specifications in the pre-sales or post-sales process. That is, has the deal already been signed and agreed upon with the client or not. There are many subtleties to how you approach this. When we discuss collecting requirements from the above four viewpoints, we will dis= cuss how they differ in pre-sales and post-sales perspective.
In summary, pre-sales perspective emphasizes business priorities, breadth-first collection of all requirements, and identifying business complexity and infrastructure risk so that we can come up with a minimum man-days and cost to satisfy the client requirements. The post-sales perspective emphasizes detailed (depth-first) gathering of information and maintaining control of the original agreed upon cost and time estimate.
The pre-sales perspective to collecting requirements a= nd specifications has two main issues: first, to limit the amount of free work done, and two to make sure that the proposal accurately reflects the cost t= o the_company should the proposal be signed.
These are conflicting issues. Obviously, the most accu= rate proposal would have full “detailed” specifications drawn out. B= ut this is simply not possible in any consulting business. How do we reconcile this conflict? Well, let’s look at the issues in more detail.
Clients simply are not willing to pay for all the spec= s up front normally until they know what the whole damage to their budget will b= e.
For example, a client will usually have set aside a fi= xed budget (eg 50k S$) for a project. The project may cost S$25k or it could actually cost S$500k. But the bottom line is that they have S$50k. They usu= ally don’t tell you how much they have in their wallet right up front beca= use that’s like telling the wolf where the chicken coop is. “Hey I = have 50k to spend on this”, “well, it just so happens that it costs = 50k to do!” is not the dialogue the client wants to hear at this point.
So they need some way of knowing approximate what the = cost will be. This is where bids come in. Usually we are one of a few vendors bi= dding on a project and so by necessity the client will not wish to spend 2 weeks individually with every vendor doing 3 sets of detailed specs. What the cli= ent wants is to reveal enough about the project so that they can get a ball park figure of what the cost is and whether the vendor is good enough to do it f= or that cost.
A reasonable rule of thumb is that for a project that = lasts around 1-3 months, we should be prepared to spend 2 total days gathering requirements and specs. If the project looks like it will cost quite a bit,= we will warn the client what the approximate cost may be and let them know tha= t if this is within the ballpark that we may wish to get more requirements.
However, normally 2 days is enough to gather basically= what the client wants and usually results in a fairly accurate proposal. Note th= at this 2 days usually occurs iteratively. So .5 days may be spent initially, = then whilst writing the requirements into the proposal or attempting to come up = with a Matrix (See the Matrix Writing SOP) more information may need to be detai= led.
So now we know the reality of the client not being wil= ling to spend money on detailed specs (or time if they are dealing with 3 or more competing vendors!).
How then, do we become detailed enough to gather a mat= rix?
Note: before we continue, please read the Matrix Writi= ng SOP. It is crucial that you understand what a Matrix is. If you do not have this document handy, a matrix is basically a list of man-days associated wi= th various parts of the project (eg specs gathering, writing a particular prog= ram module, etc.)
The basic rule of thumb is that the pre-sales matrix s= hould be in in very large increments such as days or possible a week. A several w= eek line item is probably not enough detail while a 1 day line item probably me= ans too much detail at the pre-sales requirements gathering stage.
The items you should typically identify at this stage = at minimum are:
*&nb= sp; Infrastructure requirements (external ISP, internal hosting? NT vs UNIX? Mainframe?)
*&nb= sp; Any Business Specific Rules? Level of busine= ss complexity?
*&nb= sp; Which major existing the_company apps may be reused?
*&nb= sp; Is this project applicable to our Perl or Ja= va technology?
*&nb= sp; What level of security is necessary?
*&nb= sp; Is there a custom authentication engine to integrate with?
*&nb= sp; Third Party Vendors to integrate with?
The specs gathering process should also try to gather = an understanding of the client’s priorities. This is useful in figuring = out how to map a project to PHASES. Phased projects are extremely important to = the_company and the client.
First, a phased project limits risk exposure of the cl= ient so that too many new features are not introduced to their environment too rapidly. In addition, a phased approach also helps the client show successe= s to their bosses quickly. Second, a phased project means the_company can put le= ss developers into the project for a longer time. This later part limits the r= isk exposure of the_company to having to hire 10 developers all at once to a project only to disband them and have to find some other projects for them 2 months later.
Another advantage of phases is that by splitting a pro= posal up into phases which each have their own cost, the client (if they are price conscious) may choose to only go with one phase for the moment (as they have that option). Thus, if the fi= rst phase has the highest business priority, they may at minimum choose us for splitting out the proposal this way and focusing on just one phase that they need. Later, as the client has more money, they may also keep us in mind for further phases.
The post-sales specs gathering process is different from pre-sales specs gather= ing in that the cost has now been fixed to a given man-day estimate. Although our proposals always state that this estimate may change from the proposal being signed, the reality is that no client will be very happy if = the sticker price changes too drastically.
In other words, unless it is fairly obvious a crucial = piece was left out of the proposal, it is not so professional to double the cost = and time of the project 2 weeks into collecting detailed specs. Therefore, your goal in post-sales specs gathering is to keep in mind that the client has p= aid for X days of project work and to limit the specs to accommodate the man-da= ys the client has paid for.
Note (again), please make sure you read the Matrix SOP= on techniques for adding work to the proposal. Generally a line item on the pre-sales matrix should never change man-days appreciably. Instead, any tim= e or cost added should be new line items that ideally were simply never covered = or requested previously be the client. This is an understandable cost increase= . It is not so professional or understandable by the client to have the cost increase because we misappropriate the time it took to do something we had already collected a requirement for.
As a post-sales specs gatherer, you should be familiar= with the proposal and the amount of paid-for days. Some techniques for keeping within that allotted amount of days:
*&nb= sp; Keep to the business priority outlined in the proposal
*&nb= sp; Keep the level of complexity down to the lev= el of complexity of the proposal
Keeping to the business priorities will force the spec= s to conform just to what the client actually wanted to go live. Keeping the lev= el of complexity down will also keep the proposal in place.
Note that many inexperienced clients will try to incre= ase the complexity of the project as time goes on. This is natural but avoid th= e temptation of being sucked in. Usually every project can have features added to it if = it is examined in more detail, but the client did not ask for these features initially and explicitly chose to hire us on a fixed cost/fixed time contra= ct. The other thing to avoid is allowing the client to change the requirements = back and forth. The specs gathering stage is meant to avoid this by having had t= hem sign off on the proposal and later on the specs.
We do a disservice not only to us (for absorbing cost)= if we just accept new requirements that were not in the proposal but to the client for having a project that may be late. Remember in the Matrix SOP that the client already had a level of expectation of the complexity level of coding some of the components because we provided a pre-sales matrix.
Here’s an extreme example of how the matrix help= s you. If the pre-sales matrix says support documentation takes 2 days to do, then= the client is looking for a 5-10 page document not a 100-page book. Frequently the amount of work to do something can expand at least 10 times beyond the cheapest/fastest solution= of course! This is why the matrix also helps you. The client was walked through the level of complexity that each item on the matrix was going to be develo= ped to.
More often than not, our clients tell us up front that= they want the cheapest/fastest solution we can provide. This is a number one assumption with most clients and it’s important to realize that they agreed to this when the proposal was signed (in most cases). In a few rare cases, the client may have agreed otherwise, and this again is usually reflected in the pre-sales matrix.
Note also that the client who said they wanted it cheapest and fastest may be the boss of the person you are collecting post-sales specs from. The bos= s is who is paying for the project and they wanted the less expensive solution, = but the person who is giving you the specs actually may not realize that their = boss wanted this. So it is also up to us to educate the person whom we are colle= cting specs for what their boss’s expectations were.
It’s a hard job to gather specs and be diplomati= c. For the software developer reading this document, if you didn’t before, by now you should have an understanding (5 pages into the SOP) how writing the specs is so much more than just about software development. J We will touch upon this in more detail through the rest of the document.
Earlier in the overview section we discussed the four different perspectives of the specs gatherer. Most consulting houses usually have a senior software developer or systems analyst collect the specificati= ons for a project. However, the reality is that the best specs require a mix of four disciplines.
No matter what your full-time role is at the_company, you should ALWAYS gather= the specs from all 4 of these perspectives. You must ask yourself whether you did them all enough justice. Again, the list of 4 perspectives is the following:
*&nb= sp; Software Development/Architect
*&nb= sp; Project Management
*&nb= sp; Sales/Business Development
*&nb= sp; R&D/Product Development
As a software developer, your goal is to focus on the = facts or the Truth (as Fox Mulder would say) to its logical apex. This is a reasonable ideal goal but it is not reasonable to assume you can get= to the Truth in a day or a week or even possibly a month. In the meantime, cli= ents want to get their product developed and rolled out the door.
It is even arguable that you can never truly reach the= Truth through specs alone! You can spend as much time as you want gathering specs, but no matter what, there will be things that will only be revealed once the product is released to the client’s customer or user base who will ha= ve their own comments to give.
Wearing your software developer hat, your pre-sales st= rategy of collecting facts is two-fold: breadth-first gathering of basic requireme= nts and a depth-first approach to figuring out the infrastructure and 3rd<= /sup> party vendor relationships.
The detailed functional requirements will take week= s to gather. It’s no use getting around this. However, it is important to = at least get the basics of everything that needs to be accomplished. Taking a breadth-first approach does this. Avoid the temptation to go into detail ab= out an issue unless you truly believe the complexity, left unchecked, could cau= se the project schedule to significantly change.
How much specs should you gather? Well, the answer lie= s in workflow. If you can draw a workflow of how data goes through the system un= der the various conditions the system is exposed to on a whiteboard or via Visi= o, you probably have a good enough understanding of the system for basic scheduling purposes.
However, it is still important to get the details on s= ome items that affect timeline. Infrastructure, documentation requirements, pro= cess requirements (eg are weekly meetings mandatory for the client?), 3rd party vendor relationships are all crucial to identifying early.
To summarize, in pre-sales focus on:
*&nb= sp; Breadth-first Requirements Gathering
*&nb= sp; Enough to get a Visio Workflow Diagram and b= asic Matrix
*&nb= sp; Depth-first for items that affect complexity= (eg infrastructure, client processes, etc.)
As a developer, your post-sales strategy is to collect= all the requirements in a depth-first manner. But keep in mind that you still don’t have unlimited time. It’s already been set out in the proposal and, as mentioned earlier, the Truth is not realized through specs alone.
In addition, although we will mention this under the “Project Management” role that you will assume in specs gatheri= ng, you must also keep in mind that the specs should not make the project more complicated than the proposal cost and time assumed. Therefore you must be intimately familiar with the original proposal while writing specs.
To summarize, in post-sales focus on:
*&nb= sp; Depth-first requirements gathering within allotted time
*&nb= sp; Keep original proposal cost and time in mind=
In wearing your project manager hat, you must consider project control as your number one key.
In pre-sales, your goal as a PM is to make sure that y= ou set up the requirements and matrix in such a way that the project control is maintai