User Tools

Site Tools


Sidebar

Imprint

kb:ppm:plan

20 Plan

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

21 Work Packages

This is as much design phase as planning phase

Components

  • 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

Tasks

  • 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.

22 Work Estimation

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%)

23 Releases

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

24 Timeline and Resource Planning

  • Work estimation and releases gives 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 20% at the end of each work package)
  • If releases are too long (> 2 months), reconsider release planning
  • Create a Gantt chart
  • This HAS TO BE DISCUSSED with the customer!

Role Examples:

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

25 Risks

26 Quote

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!!

Discussion

Darren: it says that milestones are preferably one month but no longer than 2 months. For me even one month could be too long. I realise that later on (5.4.1) you talk about weekly checks for - I assume - internal targets but are these connected together? I have started to use “Releases” instead of milestones and each release has a new requirement implemented. The way I look at it is that each release builds on the previous, so instead of trying to figure out what is “independent” of others, I try and create a dependency chart and use that as my design timeline. For example one project I’m working on requires a very strict directory/file structure, so this had to be implemented before I could start on the actual data storage.

Darren “Take into account other projects”. I find this quite an interesting statement, as how do you decide which project has priority? You said that you have 3 smaller projects that have got behind due to your work on the 2 bigger ones, was this a conscious decision or did it just happen? Do you think that psychologically it would be better to focus on the smaller ones and get them finished, allowing you to then focus on the bigger ones? This obviously depends on customers etc. but what if they were all as important and all had the same deadline, what would you do?

I was rather talking about the planning phase, the time when we’re coming up with a timeline proposal for the customer. 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 etc.
So you mean during project execution, when other things get moved and suddenly everything collides? We rate our customers, in terms of revenue, earnings, payment arrangements and payment moral, technical level (interesting high-level work or boring support), potential (how much work will we get in the future) and “overall feeling“ (yes, a soft fact, on intention!). Projects then get rated in a similar way, plus how urgent is a given project, plus how positively or negatively will pushing back affect our solvency. Coming back to our current status, the two large projects are the most important, and there’s a lot depending on our software (in one case, a rocket production line, in the other a newly built test area where the building alone cost 30 Mio Euros - both make me feel a little uneasy at times). Two of the three smallish projects could be pushed back without much worry, so yes, this was easily and consciously decided.

Richard Work Packages - Similar to an AGILE delivery process. Nice. Always good for measuring progress too, and disseminating elements to third parties.

Richard Work Estimation - Pessimistically? Do you mean conservatively, in order to ensure you still have a buffer in there for when you miss or underestimate something? When you've done something before, in a previous project, feel free to capture the time it took to develop and use that as a best estimate. In my estimates I usually a global contingency for the unforeseen, and explain the reasons to the customer. Especially for R&D type work.

I adopted the word „pessimistic“ after discussing this with Steve Watts, my point being something along the lines of „…realistic, not pessimistic“. Please take a look at https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/A-Pessimistic-Approach-to-Software-Design/ba-p/3673116 and the comments, and let me know if that changes your feeling?

Richard Milestones - Interesting. I agree with milestones as you describe them, although not necessarily as billing opportunities. For the customer, the billing is often related to tangible achievements and for you it's about regular financial income. Although these can coincide nicely, often you have to be a bit flexible. My invoice milestones are often 1. Immediate for hardware cost coverage, 2. Upon delivery of software/hardware solution, 3. Final invoice on successful commissioning and site acceptance testing (often this part takes ages, and sometimes doesn't ever happen due to customer problems, so make it a small component).

Richard Risks - Consider the risks presented by the customer foremost. You can often conceal or mitigate your own risks as they're largely under your control (sickness, holiday, priority balancing). But the customer risks (their hardware prototype fails, they financially struggle, they shelve the project etc.) can be really serious when they affect you - often they won't care about how this affects you, and if you don't cover yourself up front then there's no renegotiation later when the s### hits the fan :-)

Malcolm I do think a more organised approach is absolutely essential and the first thing to realise is that a project is not just coding for 40 hours a week. Perhaps you (we) should start with an assumption that we only code for 20 hours a week and the rest is some form of project management or testing.

Malcolm I sit on the fence about billing. I take Richard's point about monthly billing being good for cashflow, but that can look like you are operating as a contractor. I think a move towards milestone billing makes you look like a more 'grown up' company. I also agree with Richard's 'hardware costs up front' and perhaps I would add 'paid-for feasibility study' up front as well. I think this should aim to be about 10% of the final project costs and covers requirements capture and test and commissioning requirements.

kb/ppm/plan.txt · Last modified: 2020/03/09 11:54 by joerg.hampel