Details

Last Updated: 09 January 2014 09 January 2014

Hits: 7839 7839

The Right Price

The Right Price comes out of the Identify and Specify procedures.  And sometimes out of the Design procedure if the design leads to Identify and Specify revisions.

Until the project is finished, all predictions are based on estimates.  If you do not have a collection of statistics about your past projects, how can you estimate with any confidence?  The answer is NOT "you can't"!

The first thing you do is search for published statistics for producing content in the field or industry where you are working.  There will be data somewhere on the Internet.

The second thing you do is make use of the societies and forums you have joined.  (Or will join!)  Ask if anyone knows of industry statistics for producing your kind of work.

Between those two, you will find numbers you can use, and references, to show your estimates are not based on wild guesswork.

The third thing you can do is to promise to start collecting data from your own future work:

• How many writers on the project?
• What tasks did each writer perform?
• How good were the estimates compared to the actual numbers?
• What was the degree of difficulty of the work? (You need to use a Degree of Difficulty calculator to answer this question.)
• How many pages were produced in total during the total time of the project?
• What was the average number of hours for each delivered page for the project?

If you cannot estimate properly, you are doomed to work long hours to make your deliveries and not make much money (if you are working for yourself).

The irony is you are quite good at estimating:

• What is the length of your lounge room?
• Do you know the weight of some people just by looking at them?
• Do you know how tall some people are, just by looking at them?
• Do you know how fast a car is travelling, just by looking at it?

Why are you able to make reasonable estimates about these things, but not about producing documentation?  Because you have a lifetime of experience estimating height, weight and speed.

So all you need is either your own historical statistics or at least a reliable source of industry statistics.

The Right Price is the amount our company or our customer will pay.  That means every now and then, no matter how well you can estimate, the price will be more than the amount in someone's budget.

Always remember, you can bring a high price down (but you can rarely put a low price up).  So if you want to bring a price down, despite your estimate, the question is: how much of your own time do you want to risk as extra, unpaid hours if your estimate is more guesswork than science?  

In that situation, you either need to re-examine your Identify and Specify work.  Can you find another way?  What can do differently, or cut out?  Have you over-specified the content for the documentation project?  If have no good reasons to change your estimates, don't be afraid to walk away from that particular job.  

Details

Last Updated: 09 January 2014 09 January 2014

Hits: 10217 10217

Deliver

We lie.  It is really produce and Deliver.

The produce part of the procedure is easy: create > proof >  edit > review > revise.  

Create because our documentation product may not be a written document.  We keep going around this loop as often as the project plan allows.  Deliver follows after that. 

  To deliver we need to know (and should already know):

• To whom?
• What is the handover process"
• What support is needed?
• When is the next version due?

 What is the most important project document "delivery" that is seldom delivered?

A Lessons Learned Report.

If we take the time to ask ourselves a few important questions and keep the answers, we will learn from our history:

• Was our duration estimate right or wrong?  Why?
• Was our degree of difficulty estimate right or wrong?  Why?
• What was our average time/page?
• What went well?  Why?
• What went badly?  Why?
• What method or procedure changes could we make?  Why?

Details

Last Updated: 09 January 2014 09 January 2014

Hits: 8249 8249

The Right Product

The Right (documentation) Product comes out of the Identify, Specify, and Design procedures.

The Right Product is the one that satisfies the customer's needs.

The Right Product is:

• Fit for its purpose
• Used correctly when needed
• Produces the right outcome.

How many ways can you think of for the so-called "right product" to become a lemon?

For example, if someone has to repair something overhead, using both hands, how will they know what to do next?

 Last century Donald Norman (The Design of Everyday Things) said that the sign Do not step here points to a design flaw.  Gause and Weinberg (Are your lights on?) said when you have a solution, test it on a foreigner, a blind person or a child or make yourself foreign, blind or child-like. Jerry Weinberg knows - he was the architect for the Mercury Project's space tracking network and designer of the world's first multiprogrammed operating system.)

Now review your Identify, Specify, and Design outputs.  Do you need to ask more Identify questions?  Add more detail to the specification?  Modify the design?

When you have performed those tests on your documentation solution, you are probably getting close to the Right Product.

And of course you must test the documentation product.  Otherwise, how will you know it works as intended?  And who said testing had to be long and expensive?  Be practical and be realistic.  Read Weinberg's Perfect Software and other illusions about testing.  It is all about reducing risk for the person who makes decisions using what we have written.

Details

Last Updated: 09 January 2014 09 January 2014

Hits: 10598 10598

Design

If this is a "standard" documentation task – meaning you have a template (because the document is the same as last time), you are done!

Almost.

Even re-run documents, unless they are fully automated and data-driven, will have different content.  Sometimes that needs a bit of Design.

The Specify process produces a detailed specification of what is in the documentation product.  But there are no words about how it should be laid out, where to place the graphics and so on.  Often we might say the layout is obvious.  Why?

If you are content with more-of-the-same production, then you are done.  But if you have the opportunity to dare to be different, cease it!

The quickest and simplest way to Design is with a pencil, eraser and lots of paper.  (In film and television, this is called storyboarding).  You may only need three storyboards or you may need thirty.  It all depends on the document and your imagination.  (The only thing you cannot do, without approval, is change the specification.)

Why use words at all?

How many ways can you present a "graphic"?

Carrying a load of nonsense?

We received a request to "write a user guide for our freight handling software".  The conversation went something like this:

"Why?"

"Because we are rewriting the existing application in Visual Basic"

"Who will use it?"

"The existing staff."

"Will all the functions be the same?"

"Yes."

That was all we needed for the Identify procedure.  We came to the conclusion a manual was going to be a waste of our time and their money.  So the Identify procedure proposed a document that would take less than a week to produce and everyone could use instantly.

The client loved the idea.

The specification was about five lines on a page.  The Design was a storyboard of the documentation product on the remainder of the page.

What did we produce?

This email address is being protected from spambots. You need JavaScript enabled to view it. and find out if you are right or get another clue.