All of these should be done together with the client, or in close coordination with them.

This is as much design phase as planning phase

• Divide the application into “components”

  • Areas or function groups, eg Database, Reporting, Logger, GUI.
• Typically, this happens during very early design sketches (on a whiteboard)

  • this should give the components involved

• Translate the list of requirements into tasks (little pieces of work) that can be listed, assigned, tracked in your preferred system (eg. OpenProject or JIRA).
• Tasks can be defined in Excel during planning and transferred to system of choice after customer order.

• Each task should be member of one component.

No dates and deadlines here, only amount of work

• Come up with estimations of cost/work for each task (preferably) or component (at the least)
• Estimate pessimistically (more on that)
• Don’t forget

  • Testing: Unit (or other) and Acceptance
  • Documentation
  • Organizational and other non-programming work
• Add enough buffer/contingency to the budget (between 25..100%)

Releases are extremely important as they shall mark invoicable events!

• A release is a version of the application with a defined set of features
• Each release builds on the former one
• A release's (new) features

  • can be fully implemented within that release
  • are fully testable (→ acceptance testing)
• Development time for releases must not be too long

  • preferably one, but no longer than two months
  • minimizes risk of delaying knowledge/info of problems
  • helps with solvency

• Group components to form feature sets (releases) 

• If above doesn’t work with the given components, come up with bundles of work packages (small tasks) that together form feature sets (releases) 

• Again

  • Each release has to be reachable independently of any other releases
  • Release implementation time no longer than two months, rather one

• Work estimation and releases give a rough timeline.
• The timeline has to be adjusted to the actual availability of resources
• Take into account…

  • other projects (this means that we need to consider not only that resources can be already reserved for other projects, but we also need to listen to our gut feeling about possible collisions with other project work down the road)
  • foreseeable delays
  • errors with work estimation
  • different roles (see below)
• Add enough buffer/contingency (at least xx% at the end of each work package)
• If releases are too long (> 1 month), reconsider release/milestone planning
• This HAS TO BE DISCUSSED with the customer!

Role Examples:

• CEO cannot work on projects more than 10%
• Project Lead cannot program more than 66%
• Consultant cannot work on own work packages more than 50%

• What Steve Watts said:

  • https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/Risk-Judgement-and-Mitigation-1/ba-p/3602763
  • https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/Risk-Judgement-and-Mitigation-2/ba-p/3611761

The result of all the points above

• Quote position title contains components from requirements
• Quote position description contains requirements numbers

• First item is always “Organisation” (non-optional)
• Add an optional item for service/improvement work after 6 or 12 months

  • mention that after 12 months, no warranty applies for bugs found

• Releases are billing items/billing dates → this controls solvency!!
• If risks are too high, consult with the customer

  • DO NOT QUOTE if risks are too high!!