Details

Last Updated: 25 June 2013 25 June 2013

Hits: 7802 7802

Details

Last Updated: 21 November 2013 21 November 2013

Hits: 10633 10633

Lasotell Tender and Specification Preparation Services

Tender and Specification Preparation includes:

• Tender documents such as Expression of Interest, Request for Proposal and Request for Tender together with ancillary documents such as Statement of Work and Service Level Specification.
• Software and Hardware Specification documents (including documents to Military Specification standard).

For tender/specification documents to be successful, the people preparing them need to mark, learn and inwardly digest the following principles:

• A requirement sentence states what you want.  A Statement of Work sentence states what you want done.
• Each requirement should be uniquely identified to make response assessment and follow-up discussion much easier.
• Each requirement often needs one or two scope sentences that define the bounds of the requirement.
• Each requirement needs a separate Test Specification sentence stating what you will do to verify the requirement has been delivered (yes, this applies to tender and specification documents).
• The Test Specification provides the sanity check for the requirement — if you cannot test it, the requirement is wrong (one way or another).
• Unless there is a very good reason, neither a tender nor specification document should impose any restriction or constraint on those who have to develop the deliverable solution. (This helps produce the most cost-effective outcome.)

With these principles in mind, preparing the document content is easier. And they help with the task of preparing the document itself – there is less rewriting after each review.

Measurable Benefits of Proper Tender and Specification Preparation

If you can apply these principles correctly, (and it takes a little time and practice to learn to do so consistently), you will write documents that are easy to understand. This means you will receive better solutions and better prices.

The clarity of the document, combined with the unique requirement identifier, results in easier to evaluate response documents and easier to check deliverables. This makes the process more efficient, and quicker because there is less time spent on dealing with ambiguities, which translates into significant cost savings.

Lasotell Tender and Specification Preparation Skills

• Contribute to the requirements identification/definition phase
• Assist or be the original author for draft specifications and other elements
• Manage the writing phase of the document
• "Gotcha" checks (that is, preventing unscoped requirements creeping into the document)
• Consistency checks
• Quality aspects
• Project Management or Project Co-ordination
• Configuration Management
• Research topics and gather data
• General gopher
• Final document publishing.

Details

Last Updated: 21 November 2013 21 November 2013

Hits: 10251 10251

Lasotell Response to Tender Services

When you are preparing a response to a Tender or Expression of Interest, there are five particular pitfalls awaiting the Innocent, the Eager and the Doomed:

1. Price wins the business, not documents.
2. If "value for money" statements cannot be quantified, they have no value that can be expressed in money terms — see pitfall #1.
3. Nobody cares about what you or your company "believes". You either do things or you do not.
4. If your response activity is focused on anything other than addressing the specific, identifiable prospective client's requirements, you are wasting time (and money) and you will generate the wrong price — see pitfall #1.
5. If you cannot prove every claim (people, dates, places) you make about how good you are, you risk failing to deliver the services for the price you are submitting.

If Pitfall #1 is true, why prepare documents at all?  Because if you are not the preferred supplier, but your price is within 10% of the preferred supplier's price, the prospective client will go through your response with a fine tooth comb to find reasons to reject you.  If you have written a good response, you might show the prospective client your company knows more about the client's requirements than the preferred supplier. And on that basis you might knock out the preferred supplier.

If you are not the preferred supplier, why are you responding to this tender? Why do you think you can still win the business?  Whether you are the preferred supplier or not, every word you write needs to address the second question.

How do you Write a Good Response?

There are four steps:

1. Identify all the explicit and implied requirements, at all levels, within the client organisation and in the Request or Expression document.
2. State what service or product you will deliver to address the requirements at a given level.
3. State what will be done (never how) to deliver the service or product.
4. At each level of the response, state the appropriate benefits of the service or product you will deliver.

These four steps mitigate against cutting and pasting from previous responses — because each client has sub-sets of different requirements. Yes, many requirements are the same from one company to the next, especially within the same market, but it is recognising and capitalising on the differences that show client understanding and contribute to a winning response.

What is a "Benefit"?

A benefit is something you can:

• Measure (performance attributes)
• Kick with your foot (tangible outcomes)
• Put in your pocket (cash savings).

If it is not one of these three, then 9,999 times out of 10,000, you have described a feature and most clients could not care less about features.

When you are dying of thirst and someone offers you drink, you really do not want to hear about the 147 features associated with its preparation. You just want the drink because it will allow you to get on with your life.

Measurable Benefits of a Proper Tender Response

The response document will contain few, if any, unsupportable claims in comparison with your previous responses.

The response document will contain many more crisp, identifiable benefits than your previous responses.

The response document will contain more words and pages talking about the client's company instead of your company in comparison with your previous responses.

Lasotell Tender Response Skills

• Contribute to the solution development phase
• Assist or be the original author for draft plans and other response elements
• Manage the writing phase of the response
• "Gotcha" checks (that is, preventing uncosted statements creeping into the response)
• Consistency checks
• Quality aspects
• Project Management or Project Co-ordination
• Configuration Management
• Research topics and gather data
• General gopher
• Final document publishing.

Details

Last Updated: 28 November 2013 28 November 2013

Hits: 11414 11414

Document Project Management

This is the base of professional technical communication.  

There are two parts to every project: project management and product development.  Project management is about what to do and product development is about how to do it.  PRINCE2 is an example of project management methodology and Agile is an example of product development methodology.

If you understand project management, you know it is common sense planning applied consistently to a recognised standard.  The difference between different flavours of project management is usually apparent in their consistency and rigour.   

In the documentation world, Technical Writers can be project managers and they can be document (product) developers.  Sometimes the documentation is the whole project.  At other times the documentation is one of many products coming out of a project.  In 1994 Dr. JoAnn Hackos published a common sense methodology for managing documentation projects.  The methodology is summarised in Figure 1.  

This process is scalable.  You can apply it to a presentation due in a few hours.  To a project involving 50 engineers with five or six technical writers over several months.  To the stream of documentation that is produced in a 1,000 work-year Defence project.  The percentage allocation of the time does not change.  (We will discuss every aspect of that graph in more detail in future articles.)

The project management side of Figure 1 is managing the timetable and the resources for each activity.  The product development side is under the Implementation heading.

(In PRINCE2 terminology, depending on the product, the Information Plan content goes into the Project Brief and Project Approach documents.  The Content Specification's content goes into the Project Initiation Document, Stage Plan and the Work packages.

The Information Plan focuses on your document's audience.  It answers questions such as:

• Who is the real audience?
• What is the real purpose of the job?
• What are the real needs?
• Manuals: what are all the tasks anybody associated with this product will perform?
• Brochure: what are the customer's needs?
• What are the implications on the product?

If you are the customer (the person paying for this documentation work), you approve this Plan before work starts on the Content Specification.

The Content Specification states what the document will contain. (A mere Table of Contents, in isolation, is probably the least useful planning tool.) The Content Specification:

• Specifies what information is needed and why.
• Specifies where it will be located in the document and often, why.
• Specifies the overall structure of the document.
• Provides a draft Table of Contents.
• Specifies the Useability Test(s) to know if the document will work as intended.
• Provides guidance for Reviewers — they can see what you intend to  achieve.

If you are the customer (the person paying for this documentation) you approve this Plan before work starts on the Detailed Design and Writing stages.

A version of the Project Plan is usually delivered with each document. The Project Plan should be accompanied by a Degree of Difficulty calculation to show the impact of the complexity of the job relative to historical metrics for that type of work.

The Delivery phase in Figure 1 includes a Wrap-up Report that honestly appraises progress against the plan. It compares planned hours against actual hours worked. It also includes another Degree of Difficulty calculation to assess the actual impact of the complexity.  It also examines the estimates and especially any significant difference from actuals.

Requirements, preliminary design or solution activities

In parallel with writing the Information Plan and Content Specification, you may need to gather business requirements, create the first draft of a preliminary design or a first draft of a solution to provide the substance for each document. This is common when responding to tenders.

The tools for this type of data gathering include Issue Trees, storyboards and the PRINCE2 Product Breakdown Structure and the Product Flow Diagram (which makes creating the first project plan easy).

This data gathering activity concludes with a Solution Walk-through or Preliminary Design Review with all interested parties.

Benefits of applying the right process and procedures

You will receive the following measurable benefits from applying the proper practices to your documentation projects:

• At least double the average original-page writing productivity of your current documentation projects
• Fewer people needed for documentation tasks
• Fewer work hours per person to deliver higher quality material
• More time for technical people to focus on the solution (for proposals, the cost models)
• Better estimates of the size and scope of documentation tasks
• Less time wasted on re-writing content
• Improved productivity and control when working with distributed documentation teams.

Lasotell project management and product development skills

• Project Startup, Initiating a Project, Controlling a Project Stage, Managing Product Delivery, Managing Stage Boundaries, Closing a Project, Planning, Directing a Project
• Business Case preparation, Organisation, Plans, Project Controls, Risk Management, Quality Management, Configuration Management, Change Control
• Product Based Planning, Quality Reviews, Issue Management
• Scheduling
• Managing resources (and the necessary diplomacy)
• Ensuring cost effective work methods
• Specification writing and editing - any place, any time, any subject
• Prototyping
• Staff Management and motivation
• Maintenance Planning - designing and producing low maintenance documents
• Maintenance watchdog - highlighting potential product maintenance traps
• Style guide(s).